Rotar autoridades de certificación

Google Distributed Cloud usa certificados y claves privadas para autenticar y cifrar las conexiones entre los componentes del sistema en los clústeres. La autoridad de certificación (CA) del clúster gestiona estos certificados y claves. Cuando ejecutas el comando bmctl update credentials certificate-authorities rotate, Google Distributed Cloud realiza las siguientes acciones:

  • El comando crea y sube nuevas autoridades de certificación (ACs) de clúster para la AC del clúster, la AC de etcd y la AC de front-proxy al espacio de nombres del clúster de usuarios en el clúster de administrador.

  • Los controladores del clúster de administrador sustituyen las autoridades de certificación del clúster de usuario por las que se acaban de generar.

  • Los controladores del clúster de administrador distribuyen los nuevos pares de claves de certificado de AC público y de certificado de hoja a los componentes del sistema del clúster de usuario.

  • El comando también actualiza el stackdriver-prometheus-etcd-scrape secreto, que Google Distributed Cloud creó durante la creación del clúster. Prometheus necesita este secreto para recoger métricas de etcd.

Para mantener la comunicación segura entre clústeres, rota la CA de tu clúster de usuarios periódicamente y siempre que haya una posible brecha de seguridad.

Antes de empezar

Antes de rotar la autoridad de certificación de tu clúster, planifica la rotación teniendo en cuenta las siguientes condiciones y consecuencias:

  • Asegúrate de que los clústeres de administrador y de usuario tengan la versión 1.9.0 o una posterior antes de iniciar la rotación de la CA.

  • La rotación de la CA es incremental, lo que permite que los componentes del sistema se comuniquen durante la rotación.

  • 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 de esperar que las cargas de trabajo se reinicien y se vuelvan a programar.

  • Si tu clúster de usuarios no tiene un plano de control de alta disponibilidad, es posible que el plano de control se quede inactivo durante breves periodos durante la rotación de la AC.

  • No se permiten operaciones de gestión de clústeres durante la rotación de la CA.

  • La duración de la rotación de la CA depende del tamaño del clúster. Por ejemplo, la rotación de CA puede tardar cerca de dos horas en completarse en un clúster con un plano de control y 50 nodos de trabajador.

Limitaciones

La función de rotación de la autoridad de certificación tiene las siguientes limitaciones:

  • La rotación de la AC no actualiza los certificados emitidos manualmente por un administrador, aunque la AC del clúster firme los certificados. Actualiza y redistribuye los certificados emitidos manualmente una vez que se haya completado la rotación de la AC del clúster de usuarios.

  • Una vez iniciada, la rotación de la autoridad certificadora no se puede pausar ni revertir.

Iniciar una rotación de la CA de un clúster

De forma predeterminada, los certificados TLS tienen un periodo de validez de un año. Google Distributed Cloud renueva estos certificados cuando rotas las autoridades de certificación. Google Distributed Cloud también renueva los certificados TLS durante las actualizaciones de clústeres. Te recomendamos que actualices tus clústeres con regularidad para que estén protegidos y sean compatibles, así como para evitar que caduquen los certificados TLS.

Usa el siguiente comando para iniciar el proceso de rotación de la CA:

bmctl update credentials certificate-authorities rotate --cluster CLUSTER_NAME \
    --kubeconfig KUBECONFIG

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster para el que quieres rotar las autoridades de certificación.
  • KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador. En el caso de los clústeres autogestionados, este archivo es el archivo kubeconfig del clúster.

El comando bmctl se cierra después de que se haya rotado correctamente la CA y se haya generado un nuevo archivo kubeconfig. La ruta estándar del archivo kubeconfig es bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Solucionar problemas de rotación de la CA de un clúster

El comando bmctl update credentials muestra el progreso de la rotación de la CA. El archivo update-credentials.log asociado se guarda en el siguiente directorio con marca de tiempo:

bmctl-workspace/CLUSTER_NAME/log/update-credentials-TIMESTAMP