Google Distributed Cloud usa certificados y claves privadas para autenticar y cifrar las conexiones entre los componentes del sistema en los clústeres de usuarios. El clúster de administrador crea un nuevo conjunto de autoridades de certificación (ACs) para cada clúster de usuario y usa certificados de AC para emitir certificados de hoja adicionales para los componentes del sistema. El clúster de administrador gestiona la distribución de los certificados de AC pública y los pares de claves de certificados de hoja a los componentes del sistema para establecer su comunicación segura.
La función de rotación de la CA de clúster de usuarios te permite activar la rotación de los certificados del sistema principal de un clúster de usuarios. Durante una rotación, el clúster de administrador sustituye las ACs del sistema principal del clúster de usuario por ACs recién generadas y distribuye los nuevos certificados de AC públicos y los pares de claves de certificado de hoja a los componentes del sistema del clúster de usuario. La rotación se produce de forma incremental para que los componentes del sistema puedan seguir comunicándose durante la rotación. Sin embargo, ten en cuenta que las cargas de trabajo y los nodos se reinician durante la rotación.
Hay tres ACs del sistema gestionadas por el clúster de administrador para cada clúster de usuario:
- La CA de etcd protege la comunicación del servidor de la API con las réplicas de etcd y también el tráfico entre las réplicas de etcd. Esta CA tiene una firma automática.
- La AC 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 y programadores). Esta CA tiene una firma automática.
- La CA del proxy frontal protege la comunicación con las APIs agregadas. Esta CA tiene una firma automática.
También es posible que estés usando una AC de organización para firmar el certificado configurado con la opción authentication.sni.
Esta AC y el certificado SNI se usan para ofrecer la API de Kubernetes a los clientes que están fuera del clúster. Gestionas esta AC y generas manualmente el certificado SNI. Ni esta CA ni el certificado SNI se ven afectados por la función de rotación de la CA del clúster de usuarios.
Limitaciones
Ten en cuenta la siguiente limitación de los clústeres avanzados:
- Versión 1.31: no se admite la rotación de la CA en clústeres avanzados.
- Versión 1.32 y posteriores: la rotación de la AC se admite en clústeres avanzados, pero hay algunas diferencias menores que se indican en este documento cuando procede.
La rotación de certificados de AC se limita a las AC de etcd, clúster y proxy frontal mencionadas anteriormente.
La rotación de certificados de AC se limita a los certificados emitidos automáticamente por Google Distributed Cloud. No actualiza los certificados emitidos manualmente por un administrador, aunque estén firmados por las CAs del sistema.
Una rotación de la CA reinicia el servidor de la API, otros procesos del plano de control y cada nodo del clúster varias veces. Cada fase de una rotación de CA se desarrolla de forma similar a una actualización de clúster. Aunque el clúster de usuarios sigue funcionando durante la rotación de la AC, es posible que las cargas de trabajo se reinicien y se vuelvan a programar. También debes esperar breves periodos de inactividad del plano de control si tu clúster de usuario no tiene un plano de control de alta disponibilidad.
Debes actualizar el archivo kubeconfig del clúster de usuarios y los archivos de configuración de autenticación después de una rotación de la CA. Esto se debe a que se revoca el certificado del clúster antiguo y las credenciales del archivo kubeconfig ya no funcionan.
Una vez que se inicia una rotación de la CA, no se puede pausar ni revertir.
Una rotación de la AC puede tardar bastante tiempo en completarse, en función del tamaño del clúster de usuarios.
Realizar una rotación de AC
Inicia la rotación:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGHaz los cambios siguientes:
USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios
ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
El comportamiento del comando varía en función de si el clúster avanzado está habilitado:
No habilitada
Si el clúster avanzado no está habilitado en el clúster, el comando es asíncrono
inicia la rotación de la CA y, a continuación, se cierra. No es necesario que monitorices la salida del comando durante toda la rotación de la CA. En su lugar, puedes comprobar periódicamente el progreso ejecutando el comando gkectl update credentials certificate-authorities status.
Si la rotación de la CA 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 ya se está llevando a cabo una rotación de la CA, 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
Para ver el estado de la rotación, sigue estos pasos:
gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
El comando anterior muestra el CAVersion, que es un número entero que el sistema incrementa automáticamente para diferenciar las autoridades de certificación usadas antes y después de una rotación. El comando también indica un estado (True o False) que indica si la rotación de la CA se ha completado y un mensaje que describe qué CAVersion está usando cada componente del sistema.
Si la rotación de la CA ya se ha completado, verás un mensaje similar a este:
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 CA aún está en curso, verás un mensaje similar a este:
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.
Actualizar las credenciales del clúster de usuarios
En los clústeres que no tienen habilitada la opción de clúster avanzado, debes obtener un nuevo archivo kubeconfig del clúster de usuarios 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 antiguo.
Obtén un nuevo archivo kubeconfig:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
-n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
| base64 --decode > USER_CLUSTER_NAME-kubeconfig
Habilitado
Si el clúster avanzado está habilitado, el comando gkectl update credentials
certificate-authorities rotate es síncrono. El comando genera mensajes de estado en la estación de trabajo del administrador a medida que avanza la rotación de la CA.
Una vez que se haya rotado correctamente la CA, el comando se cerrará y se generará automáticamente un nuevo archivo kubeconfig. La salida del comando proporciona el nombre del nuevo archivo kubeconfig y es similar a la siguiente:
Beginning CA rotation with generated CA ... Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has been updated.
El nuevo archivo kubeconfig se encuentra en el mismo directorio que el archivo kubeconfig del clúster de administrador que has especificado en el comando. El nombre del nuevo kubeconfig es USER_CLUSTER_NAME-kubeconfig.
Distribuir el nuevo archivo kubeconfig
Distribuye el nuevo archivo kubeconfig a todos los usuarios que lo utilicen para interactuar con el clúster.
Actualizar archivos de configuración de autenticación
Una vez completada la rotación de la AC, los archivos de configuración de autenticación deben actualizarse y redistribuirse. Para obtener más información, consulta Gestionar la identidad de los usuarios.
Rotación de certificados del plano de control
Si no se rota, tanto las autoridades de certificación del clúster de usuario como los certificados del plano de control caducan cinco años después de la fecha en la que se creó el clúster. Los certificados del plano de control del clúster de usuario se rotan automáticamente en un plazo de diez horas después de cada actualización del clúster de usuario, pero las CAs no se rotan automáticamente. Esto significa que se debe realizar una rotación de la CA al menos una vez cada cinco años, además de las actualizaciones de versión periódicas.
Para evitar que un clúster de usuarios deje de estar disponible, los certificados del plano de control se renuevan en un plazo de diez horas después de actualizar el clúster de usuarios. Cuando esto ocurre, aparece un mensaje en el estado de rotación de la CA del clúster de usuarios.
Para ver la última versión a la que se ha actualizado un clúster de usuarios cuando se han rotado 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 en un plazo de diez horas tras la actualización. Por ejemplo:
Last Leaf Certificates Rotation Version: 1.16.0-gke.0.
Solucionar problemas de rotación de una autoridad de certificación
El comando gkectl diagnose permite comprobar el estado esperado de una rotación de AC completada en un clúster de usuarios. Para obtener instrucciones sobre cómo ejecutar gkectl diagnose en un clúster de usuario, consulta Diagnosticar problemas de clústeres.
Si tienes problemas con una rotación de CA, ponte en contacto con el equipo de Asistencia de Google y proporciona el resultado de gkectl diagnose.