Google Distributed Cloud usa certificados y claves privadas para autenticar y encriptar las conexiones entre los componentes del sistema en 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 certificados de CA para 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 la 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 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
Ten en cuenta la siguiente limitación con los clústeres avanzados:
- Versión 1.31: La rotación de la CA no se admite en los clústeres avanzados.
- Versión 1.32 y posteriores: La rotación de CA es compatible con los clústeres avanzados, pero existen algunas diferencias menores que se indican cuando corresponde en este documento.
La rotación de certificados de CA se limita a las CA de etcd, clúster y proxy principal mencionadas anteriormente.
La rotación de certificados de CA se limita a los certificados emitidos automáticamente por Google Distributed Cloud. 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 reinicia 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 si tu 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 revoca el certificado de clúster anterior y las credenciales en el archivo kubeconfig ya no funcionan.
Una vez que se inicia una rotación de CA, no se puede pausar ni revertir.
Una rotación de CA puede tardar un tiempo considerable en completarse, según el tamaño del clúster de usuario.
Realiza una rotación de CA
Inicia la rotación:
gkectl update credentials certificate-authorities rotate \ --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIGReemplaza lo siguiente:
USER_CLUSTER_CONFIG: la ruta del archivo de configuración de tu clúster de usuario
ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
El comportamiento del comando difiere según 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, luego, se cierra. No es necesario que observes el resultado del comando durante toda la rotación de la CA. En su lugar, puedes verificar el progreso de forma periódica ejecutando el comando gkectl update credentials certificate-authorities status.
Si la rotación de 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 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
Para ver el estado de la rotación, haz lo siguiente:
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 incrementa automáticamente para diferenciar las CA 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 CA y un mensaje que describe qué CAVersion está usando cada componente del sistema en este momento.
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 las credenciales del clúster de usuario
En los clústeres que no tienen habilitado el clúster avanzado, debes obtener un nuevo archivo kubeconfig del clúster de usuario del clúster de administrador. Esto se debe a que la rotación de CA revoca la CA 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
Habilitado
Si el clúster avanzado está habilitado, el comando gkectl update credentials
certificate-authorities rotate es síncrono. El comando muestra mensajes de estado en la estación de trabajo de administrador a medida que avanza la rotación de la CA.
Después de que la CA se rota con éxito, el comando se cierra y se genera automáticamente un archivo kubeconfig nuevo. El resultado del comando proporciona el nombre del nuevo archivo kubeconfig y es similar al 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 kubeconfig se encuentra en el mismo directorio que el kubeconfig del clúster de administrador que especificaste en el comando. El nombre del nuevo kubeconfig es USER_CLUSTER_NAME-kubeconfig.
Distribuye el archivo kubeconfig nuevo
Distribuye el nuevo archivo kubeconfig a todas las personas que lo usan para interactuar con el clúster.
Actualiza los 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. Para obtener más información, consulta Administra la identidad del usuario.
Rotación de certificados del plano de control
Sin rotación, las CA del clúster de usuario y los certificados del plano de control vencen cinco años después 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 de clúster de usuario, pero las CA no se rotan de forma automática. Esto significa que la rotación de una CA debe realizarse al menos una vez cada cinco años, además de las actualizaciones regulares de las versiones.
Para evitar que un clúster de usuario deje de estar disponible, los certificados del plano de control se rotan en un plazo de diez horas después de 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 en un plazo de diez horas después de la 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. Para obtener instrucciones sobre cómo ejecutar gkectl diagnose 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.