Rotación de credenciales de cluster

Descubra cómo rotar las credenciales de los clusters que ha creado mediante Container Engine for Kubernetes (OKE).

Para activar la comunicación TLS segura (anteriormente SSL) hacia, desde y dentro de los clusters, Kubernetes utiliza certificados PKI (infraestructura de clave pública) para la autenticación. Para obtener más información sobre los certificados PKI y los clusters de Kubernetes, consulte Certificados y requisitos PKI en la documentación de Kubernetes.

Los clusters que crea con Container Engine for Kubernetes tienen CA raíz de PKI (autoridades de certificación) y claves privadas para el cluster, el componente etcd y el componente de proxy frontal. Estas CA raíz se utilizan para firmar los certificados y las claves privadas que se utilizan en el cluster. Las CA raíz, los certificados firmados y las claves privadas que se utilizan en el cluster se conocen colectivamente como credenciales del cluster.

En los clusters que cree con Container Engine for Kubernetes, las CA raíz caducan después de cinco años. Para seguir utilizando un cluster, debe cambiar (o 'rotar') las credenciales del cluster antes de que finalice el período de cinco años. Además, es posible que su organización tenga directrices y políticas de seguridad que requieran que rote las credenciales del cluster con más frecuencia (en algunos casos, con mucha más frecuencia). Los mensajes que le informan de la próxima caducidad de las credenciales del cluster se muestran en la consola. También puede utilizar la consola, la CLI y la API para averiguar cuándo caducarán las credenciales del cluster.

Al rotar credenciales de cluster, debe actualizar los clientes de API de Kubernetes que utilizaban las credenciales anteriores para comunicarse con la API de Kubernetes. Estos clientes de API de Kubernetes incluyen archivos de kubeconfig y pods que se comunican directamente con la API de Kubernetes.

La rotación de credenciales de cluster es un proceso de tres pasos:

• Paso 1, Iniciar la fase de rotación de credenciales de inicio: durante la fase de rotación de credenciales de inicio, se crean nuevas CA raíz, claves privadas y certificados. Puede iniciar la fase Iniciar rotación de credenciales en cualquier momento, pero debe iniciar la rotación de credenciales antes de que caduquen las credenciales. El inicio de la rotación de credenciales antes de que caduquen las credenciales también evitará la interrupción del servicio.

  Al iniciar la fase de inicio de rotación de credenciales, especifique explícitamente la longitud de un 'período de retraso' antes de que la fase de finalización de rotación de credenciales se inicie automáticamente. El período de retraso permite actualizar los clientes de API de Kubernetes (paso 2). Durante el período de retraso, tanto las credenciales heredadas como las nuevas credenciales proporcionan una comunicación segura hacia, desde y dentro del cluster. El período de retraso que especifique no debe ser inferior a 1 día ni superior a 90 días. Puede iniciar manualmente la fase Completar rotación de credenciales antes de que finalice el período de retraso, siempre que las nuevas credenciales tengan al menos 24 horas de antigüedad y haya completado correctamente el paso 2.

  No inicie el paso 2 hasta que se hayan creado las nuevas CA raíz, las claves privadas y los certificados.

  Nota
  
  Al utilizar la CLI o la API para iniciar la fase de rotación de credenciales de inicio, especifique la longitud del período de retraso en el formato de duración ISO 8601. Por ejemplo:

  • utilice P5D para especificar cinco días
  • utilice P5DT5H para especificar cinco días y cinco horas
  • utilice P5DT5H5M para especificar cinco días, cinco horas y cinco minutos

  Para obtener más información sobre el formato de duración ISO 8601, busque en línea.

• Paso 2, Actualizar clientes de API de Kubernetes: cuando se hayan creado las nuevas CA raíz, claves privadas y certificados, y dentro del período de retraso especificado (no menos de 1 día y no más de 90 días):
  • Configure nuevos archivos kubeconfig para permitir el acceso al cluster mediante las nuevas credenciales y las credenciales heredadas.
  • Vuelva a crear o reiniciar los nodos de trabajador que alojan pods que se comunican directamente con el servidor de API de Kubernetes (o para evitar la interrupción en los nodos de trabajador, simplemente reinicie los pods ellos mismos).

  No inicie el paso 3 hasta que haya configurado nuevos archivos kubeconfig y haya vuelto a crear o reiniciar los nodos de trabajador (o simplemente haya reiniciado los pods).

• Paso 3, Iniciar la fase Completar rotación de credenciales: cuando haya terminado el paso 2 y dentro del período de retraso especificado (no menos de 1 día y no más de 90 días), puede iniciar manualmente la fase Completar rotación de credenciales. Durante la fase Completar rotación de credenciales, se retiran y eliminan las CA raíz heredadas, las claves privadas y los certificados. Inicie la fase Completar rotación de credenciales no antes de 24 horas después de haber iniciado la fase Iniciar rotación de credenciales y solo después de haber terminado el paso 2. Si las nuevas credenciales tienen al menos 24 horas de antigüedad, puede iniciar la fase Completar rotación de credenciales tan pronto como esté listo.

  Si no inicia manualmente la fase Completar rotación de credenciales durante el período de retraso especificado (no menos de 1 día y no más de 90 días), la fase Completar rotación de credenciales se inicia automáticamente al final del período de retraso.

  Una vez finalizada la fase de rotación de credenciales completas, recomendamos sustituir cualquier archivo kubeconfig creado durante el paso 2 (que contendrá tanto credenciales heredadas como nuevas credenciales) por un nuevo archivo kubeconfig que contenga solo las credenciales nuevas.

La fase de rotación de credenciales de inicio y la fase de rotación de credenciales completas se generan como solicitudes de trabajo independientes. Para realizar un seguimiento del progreso de la fase Iniciar rotación de credenciales y Finalizar rotación de credenciales, consulte el estado de la solicitud de trabajo correspondiente. Consulte Visualización de solicitudes de trabajo.

Puede rotar credenciales de cluster mediante la consola, la CLI y la API.

Tenga en cuenta lo siguiente al rotar las credenciales del cluster:

• La rotación de credenciales está soportada para clusters que ejecutan la versión 1.20 o posterior de Kubernetes.
• La simple actualización de la versión de Kubernetes en el plano de control de cluster no rota las credenciales. Debe completar todos los pasos del proceso de rotación de credenciales.
• La fase de rotación de credenciales de inicio y la fase de rotación de credenciales de finalización solo pueden comenzar cuando todos los nodos de trabajador del cluster tienen el estado READY (Listo). Si el estado de uno o más nodos de trabajador cambia a NOT READY durante la rotación de credenciales, las operaciones de rotación de credenciales se pausan hasta 24 horas, esperando a que todos los nodos vuelvan a tener el estado READY antes de reanudar. Si uno o más nodos de trabajador aún tienen el estado NOT READY después de 24 horas, se agota el tiempo de espera de las operaciones de rotación de credenciales.
• Si la fase Iniciar rotación de credenciales o Completar rotación de credenciales falla por algún motivo, las credenciales heredadas seguirán funcionando y no se darán de baja hasta que caduquen.
• Si no inicia manualmente la fase Completar rotación de credenciales dentro del período de retraso especificado (no menos de 1 día y no más de 90 días), la fase Completar rotación de credenciales se inicia automáticamente. Si no ha actualizado los clientes de API de Kubernetes antes de que finalice el período de retraso, el cluster experimentará una interrupción del servicio.
• La rotación de credenciales está soportada para clusters con nodos gestionados y para clusters con nodos autogestionados. La rotación de credenciales no está soportada aún para los clusters con nodos virtuales.