Los clústeres de Anthos alojados en VMware (GKE On-Prem) usan certificados y claves privadas para autenticar y encriptar las conexiones entre los componentes del sistema de los clústeres de usuario. El clúster de administrador crea un conjunto nuevo de autoridades certificadoras (CA) para cada clúster de usuario y usa estos certificados de CA a fin de emitir certificados de hoja adicionales para los componentes del sistema. El clúster de administrador administra la distribución de los certificados de CA públicos y los pares de claves de certificados de hoja a los componentes del sistema para establecer una 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 reiniciarán 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, puedes usar una CA de la organización para firmar el certificado que configura 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 función de rotación de CA del clúster de usuario es compatible con los clústeres de Anthos alojados en VMware versión 1.8 y posteriores.
- La función de rotación de CA del clúster de usuario se limita de manera específica a las CA de etcd, del clúster y del proxy principal que se mencionan en la descripción general. No rota la CA de tu organización. Además, la función de rotación de la CA del clúster de usuario se limita a los certificados emitidos de forma automática por los clústeres de Anthos alojados en VMware. No actualiza los certificados que emite un administrador de forma manual, incluso si las CA del sistema firman esos certificados.
- Una rotación de CA debe reiniciar el servidor de la API, otros procesos del plano de control y cada nodo en el 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 operativo durante una rotación de CA, debes esperar que las cargas de trabajo se reinicien y se reprogramen. También debes esperar períodos breves de tiempo de inactividad del plano de control cuando no usas una configuración de alta disponibilidad.
- Los archivos kubeconfig del clúster de usuario y los archivos de configuración de autenticación para conectarse a los clústeres de usuario deben actualizarse y redistribuirse de forma manual después de una rotación de CA. Esto se debe a que una rotación de CA revoca la CA anterior necesariamente, por lo que estas credenciales ya no se autenticarán.
- Una vez iniciada, no se puede pausar ni revertir una rotación de CA.
- Una rotación de CA puede tomar un tiempo considerable en completarse, según el tamaño del clúster de usuario.
Cómo realizar una rotación de CA
Puedes iniciar una rotación de CA y ver el estado actual de la rotación mediante la ejecución de los siguientes comandos gkectl.
Rota certificados de CA
Para activar una rotación de CA, ejecuta el siguiente comando.
gkectl update credentials certificate-authorities rotate \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Aquí:
- USER_CONFIG_FILE es la ruta de acceso al archivo de configuración del clúster de usuario para el que se rotan las CA.
- ADMIN_KUBECONFIG_FILE es la ruta de acceso al archivo kubeconfig para conectarse al clúster de administrador que administra el clúster de usuario.
Si la rotación de CA se inicia de forma correcta, 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 la rotación de CA 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
Visualiza el estado de rotación de la CA
Para ver el estado de una rotación de CA, ejecuta el siguiente comando. Este comando informa la CAVersion, un número entero que el sistema aumenta de forma automática para diferenciar las CA usadas antes y después de cada rotación de CA, un estado (True o False) que indica si se completó la rotación de CA y un mensaje que describe qué CAVersion está usando cada componente del sistema en este momento.
gkectl update credentials certificate-authorities status \ --config USER_CONFIG_FILE \ --kubeconfig ADMIN_KUBECONFIG_FILE
Si la rotación de CA ya se completó, 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 CA 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 credenciales de los clústeres de usuarios
Una vez que se completa una rotación de CA, se debe descargar un archivo kubeconfig de clúster de usuario nuevo del clúster de administrador a fin de reemplazar el kubeconfig anterior que se usaba antes para conectarse a los clústeres de usuario. Esto se debe a que la rotación de CA revoca la CA anterior en la que se basaba el archivo kubeconfig anterior. Ejecuta el siguiente comando después de que se complete la rotación de CA para descargar el nuevo archivo kubeconfig:
kubectl --kubeconfig ADMIN_KUBECONFIG_FILE get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Si se emitieron archivos kubeconfig adicionales a otros usuarios del clúster de forma manual, también deben actualizarse.
Actualiza archivos de configuración de autenticación
Una vez completada la rotación de CA, los archivos de configuración de autenticación deben actualizarse y redistribuirse. Sigue las instrucciones vinculadas para actualizar y redistribuir estos archivos después de la rotación de CA:
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. Para obtener instrucciones sobre cómo ejecutar el diagnóstico de gkectl en un clúster de usuario, consulta Diagnostica problemas de clústeres.
Si tienes problemas con una rotación de CA, comunícate con la Atención al cliente de Google y proporciona el resultado de gkectl diagnose.