Rota las autoridades certificadoras del clúster de usuario

Google Distributed Cloud usa certificados y claves privadas para autenticar y encriptar conexiones entre los componentes del sistema en los clústeres de usuario. El clúster de administrador crea un nuevo conjunto de autoridades certificadoras (CA) para cada clúster de usuario y usa certificados de la AC a fin de emitir certificados de entidad final adicionales para los componentes del sistema. El clúster de administrador gestiona la distribución de los certificados de la AC públicos y los pares de claves del certificado de hoja para los componentes del sistema para establecer su comunicación segura.

La función de rotación de CA del clúster de usuario te permite activar una rotación de los certificados del sistema principal en un clúster de usuario. Durante una rotación, el clúster de administrador reemplaza las CA del sistema principal para el clúster de usuario por las CA recién generadas y distribuye los nuevos certificados de CA públicos y los pares de claves de certificado de hoja a los componentes del sistema del clúster de usuario. La rotación ocurre de manera incremental, de modo que los componentes del sistema puedan seguir comunicarse durante la rotación. Sin embargo, ten en cuenta que las cargas de trabajo y los nodos se reinician durante la rotación.

Existen tres CA del sistema que administra el clúster de administrador para cada clúster de usuario:

  • La CA de etcd protege la comunicación del servidor de la API a las réplicas de etcd y también el tráfico entre réplicas de etcd. Esta CA está autofirmada.
  • La CA del clúster protege la comunicación entre el servidor de la API y todos los clientes internos de la API de Kubernetes (kubelets, controladores, programadores). Esta CA está autofirmada.
  • La CA de proxy principal protege la comunicación con las API agregadas. Esta CA está autofirmada.

Además, es posible que uses una CA de la organización para firmar el certificado configurado por la opción authentication.sni. Esta CA y el certificado SNI se usan para entregar la API de Kubernetes a los clientes fuera del clúster. Administra esta CA y genera el certificado SNI de forma manual. Ni esta CA ni el certificado SNI se ven afectados por la función de rotación de CA del clúster de usuario.

Limitaciones

  • La rotación del certificado de CA se limita a las AC de etcd, del clúster y del proxy frontal que se mencionaron antes.

  • La rotación de certificados de CA se limita a los certificados que emite Google Distributed Cloud de forma automática. No actualiza los certificados emitidos por un administrador de forma manual, incluso si esos certificados están firmados por las AC del sistema.

  • Una rotación de AC reinicia el servidor de la API, otros procesos del plano de control y cada nodo del clúster varias veces. Cada etapa de una rotación de CA avanza de manera similar a una actualización de clúster. Si bien el clúster de usuario permanece en funcionamiento durante una rotación de la AC, debes esperar que las cargas de trabajo se reinicien y reprogramen. También es posible que se produzcan períodos breves de tiempo de inactividad del plano de control si el clúster de usuario no tiene un plano de control de alta disponibilidad.

  • Debes actualizar el archivo kubeconfig del clúster de usuario y los archivos de configuración de autenticación después de una rotación de CA. Esto se debe a que se revocó el certificado del clúster anterior y las credenciales en el archivo kubeconfig ya no funcionan.

  • Una vez que se inicia una rotación de AC, no se puede pausar ni revertir.

  • Una rotación de AC puede tardar bastante en completarse, según el tamaño del clúster de usuario.

Realiza una rotación de AC

  1. Inicia la rotación:

    gkectl update credentials certificate-authorities rotate \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Reemplaza lo siguiente:

    • USER_CLUSTER_CONFIGE: Es la ruta de acceso del archivo de configuración del clúster de usuario.

    • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

    Si la rotación de AC se inicia correctamente, verás un mensaje similar al siguiente:

    successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation

    Si una rotación de AC ya está en curso, verás un mensaje de error similar al siguiente:

    Exit with error:
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads

  2. Consulta el estado de la rotación:

    gkectl update credentials certificate-authorities status \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    El comando anterior informa el CAVersion, que es un número entero que el sistema aumenta automáticamente para diferenciar las AC usadas antes y después de una rotación. El comando también informa un estado (True o False) que indica si se completó la rotación de la AC, así como un mensaje que describe qué CAVersion usa actualmente cada componente del sistema.

    Si ya se completó la rotación de la AC, verás un mensaje similar al siguiente:

    State of CARotation with CAVersion 2 is -
status: True,
reason: CARotationCompleted,
message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.

    Si la rotación de la AC aún está en curso, verás un mensaje similar al siguiente:

    State of CARotation with CAVersion 2 is -
status: False,
reason: CARotationProgressed,
message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.

Actualiza las credenciales del clúster de usuario

Una vez que se completa la rotación de la CA, debes obtener un archivo kubeconfig del clúster de usuario nuevo del clúster de administrador. Esto se debe a que la rotación de la AC revoca la AC en la que se basaba el archivo kubeconfig anterior.

Obtén un archivo kubeconfig nuevo:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
    -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
    | base64 --decode > USER_CLUSTER_NAME-kubeconfig

Distribuye el nuevo archivo kubeconfig a todos los que usen un archivo kubeconfig para interactuar con el clúster.

Actualiza los archivos de configuración de autenticación

Una vez que se completa la rotación de la AC, los archivos de configuración de autenticación se deben actualizar y redistribuir. Sigue las instrucciones vinculadas para actualizar y redistribuir estos archivos después de la rotación de CA:

Rotación de certificados del plano de control

Sin rotación, las AC del clúster de usuario y los certificados del plano de control vencen cinco años a partir de la fecha en que se creó el clúster. Los certificados del plano de control del clúster de usuario se rotan de forma automática dentro de las diez horas posteriores a cada actualización del clúster de usuario, pero las AC no se rotan de forma automática. Esto significa que se debe realizar una rotación de AC al menos una vez cada cinco años, además de las actualizaciones regulares de versión.

Para evitar que un clúster de usuario deje de estar disponible, los certificados del plano de control se rotan dentro de las diez horas posteriores a la actualización del clúster de usuario. Cuando esto sucede, aparece un mensaje en el estado de rotación de la CA del clúster de usuario.

Para ver la última versión a la que se actualizó un clúster de usuario cuando se rotaron los certificados del plano de control, haz lo siguiente:

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

La información aparece al final del campo message dentro de las diez horas posteriores a una actualización. Por ejemplo:

Last Leaf Certificates Rotation Version: 1.16.0-gke.0.

Soluciona problemas de rotación de CA

El comando gkectl diagnose admite la verificación del estado esperado de una rotación de CA completa en un clúster de usuario. Si deseas obtener instrucciones para ejecutar gkectl diagnose en un clúster de usuario, consulta Diagnostica problemas de clústeres. Si tienes problemas con una rotación de AC, comunícate con el equipo de Atención al cliente de Google y proporciona el resultado de gkectl diagnose.