Google Distributed Cloud usa certificados y claves privadas para autenticar la comunicación entre los componentes del sistema Kubernetes en un clúster de administrador. Cuando creas un clúster de administrador, se crean nuevos certificados de autoridad de certificación (AC) y estos certificados raíz se usan para emitir certificados de hoja adicionales para los componentes del sistema de Kubernetes.
Esta guía solo se aplica a la rotación de los certificados de CA del clúster de administrador. En el caso de los clústeres de usuarios, consulta Rotar los certificados de la autoridad de certificación de un clúster de usuarios.
El sistema Kubernetes usa tres certificados de CA en un clúster de administrador:
El certificado de AC de etcd protege la comunicación del servidor de la API de Kubernetes con las réplicas de etcd, así como la comunicación entre las réplicas de etcd. Este certificado tiene una firma automática.
El certificado de CA del clúster protege la comunicación entre el servidor de la API de Kubernetes y todos los clientes internos de la API de Kubernetes, como kubelet, el gestor de controladores y el programador. Este certificado tiene una firma automática.
El certificado de AC del proxy frontal protege la comunicación con las APIs agregadas. Este certificado tiene una firma automática.
Puedes usar gkectl para activar una rotación de certificados. Durante una rotación, gkectl sustituye los certificados de AC del sistema principal del clúster de administrador por certificados recién generados. A continuación, distribuye los nuevos certificados de AC, certificados de hoja y claves privadas a los componentes del sistema del clúster de administrador. 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.
Si no se rotan, los certificados de AC y los certificados del plano de control caducarán tras un periodo de tiempo desde la fecha en que se creó el clúster.
El periodo de vencimiento depende del tipo de clúster y de la versión en la que se haya creado:
- Clústeres avanzados:
- Caducidad de 10 años
- Clústeres no avanzados:
- Creados antes de la versión 1.5: caducidad de 10 años
- Creado entre las versiones 1.5 y 1.16: caducidad de 5 años
- Creadas después de la versión 1.16: caducidad de 30 años
Los certificados del plano de control se rotan automáticamente durante una actualización del clúster, pero las autoridades de certificación no se rotan automáticamente. Esto significa que se debe realizar una rotación de la CA antes de la fecha de vencimiento de la CA, además de las actualizaciones de versión periódicas.
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 los certificados etcd, de clúster y de proxy frontal mencionados 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 AC del sistema.
La rotación de certificados de la AC reinicia el servidor de la API de Kubernetes, otros procesos del plano de control y cada nodo del clúster de administrador varias veces. Cada fase de una rotación se desarrolla de forma similar a una actualización de clúster. Aunque el clúster de administradores y los clústeres de usuarios que gestiona siguen operativos durante la rotación de certificados, es posible que las cargas de trabajo del clúster de administradores se reinicien y se vuelvan a programar. También debes esperar breves periodos de inactividad del plano de control del clúster de administración y del plano de control del clúster de usuarios.
Debes actualizar el archivo kubeconfig del clúster de administrador durante la rotación de un certificado y de nuevo cuando se haya completado. Esto se debe a que el certificado del clúster antiguo se ha revocado y las credenciales del archivo kubeconfig ya no funcionarán.
Una vez iniciada, la rotación de un certificado de AC no se puede deshacer.
La rotación de un certificado de CA puede tardar bastante en completarse, en función del tamaño del clúster.
Si se interrumpe el proceso de rotación de certificados, se puede reanudar volviendo a ejecutar el mismo comando. Sin embargo, debes asegurarte de que solo se ejecute un comando de rotación a la vez.
Iniciar la rotación
Para iniciar la rotación de certificados, ejecuta el siguiente comando:
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
Haz los cambios siguientes:
ADMIN_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de administrador
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
El comando gkectl update credentials certificate-authorities rotate inicia y realiza la primera mitad de la rotación. A continuación, el comando se detiene para que puedas ejecutar el siguiente comando y actualizar el archivo kubeconfig.
Actualizar el archivo kubeconfig
Cuando se detenga el comando gkectl update credentials certificate-authorities rotate, actualiza el archivo kubeconfig del clúster de administrador. De esta forma, se insertarán un nuevo certificado de cliente y un nuevo certificado de AC en el archivo kubeconfig. El certificado de cliente antiguo se elimina del archivo kubeconfig y el certificado de CA antiguo permanece en el archivo kubeconfig.
gkectl update credentials certificate-authorities update-kubeconfig \ --admin-cluster \ --config ADMIN_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Continuar la rotación
Ejecuta el siguiente comando para completar la segunda parte del procedimiento. El comando no se ejecuta hasta que gkectl verifica que el archivo kubeconfig actualizado se encuentra en el directorio actual.
gkectl update credentials certificate-authorities rotate \ --admin-cluster \ --complete \ --config ADMIN_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Cuando se completa la rotación, se indica la versión actual de la CA.
Vuelve a actualizar el archivo kubeconfig
Una vez completada la segunda mitad de la rotación, vuelve a actualizar el archivo kubeconfig. De esta forma, se elimina el certificado de AC antiguo del archivo kubeconfig.
gkectl update credentials certificate-authorities update-kubeconfig \ --admin-cluster \ --config ADMIN_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_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. El archivo kubeconfig que has especificado en el comando se sustituye por uno nuevo. El resultado del comando es similar al siguiente:
Beginning CA rotation with generated CA ... Successfully rotated CA for admin cluster. The kubeconfig file "/home/ubuntu/kubeconfig" has been updated. Done rotating certificate-authorities
Distribuir el nuevo archivo kubeconfig
Distribuye el nuevo archivo kubeconfig del clúster de administrador a todos los usuarios del clúster.