Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Kubernetes Service (AKS) clústeres usan certificados para la autenticación entre varios componentes, incluidos los componentes del plano de control administrados de AKS y los componentes del plano de datos. En este artículo se proporciona información general sobre la administración y la rotación de certificados en AKS.
Importante
A partir del 1 de abril de 2027 Azure Kubernetes Service (AKS) ya no admite la aks-disable-kubelet-serving-certificate-rotation=true etiqueta del grupo de nodos para deshabilitar la rotación de certificados de servicio de Kubelet (KSCR). Puede crear nuevos grupos de nodos con esta etiqueta, pero AKS no lo respetará. Este comportamiento significa que los grupos de nodos se crearán con KSCR habilitado. En el caso de los grupos de nodos existentes, KSCR se habilitará automáticamente en su siguiente operación de nueva imagen. Antes de esta fecha, puede actualizar sus grupos de nodos mediante el comando az aks nodepool update con la etiqueta aks-disable-kubelet-serving-certificate-rotation=true. Para prepararse para la eliminación, debe actualizar las cargas de trabajo con la ruta de acceso del certificado correcta. Para obtener más información, consulte la Incidencia de retirada de GitHub. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS.
Nota
La autorización de certificados para el cliente de nodo y los certificados de servicio está habilitada de forma predeterminada para los clústeres que habilitan RBAC de Kubernetes.
- Los clústeres de AKS creados antes de mayo de 2019 tienen certificados de CA de clúster que expiran después de dos años.
- Los clústeres de AKS creados después de mayo de 2019 tienen certificados de CA de clúster que expiran después de 30 años.
¿Qué es la rotación de certificados?
La rotación de certificados es el proceso de reemplazar certificados digitales por otros nuevos para mantener la seguridad y evitar interrupciones. Es una práctica de seguridad fundamental que se realiza para reemplazar los certificados expirados, mitigar los riesgos de las claves en peligro y responder a nuevos requisitos de seguridad. Este proceso puede implicar la renovación automática de certificados o reemplazarlos manualmente. A menudo, requiere una ventana de mantenimiento planeado para reemplazos complejos, especialmente cuando un certificado raíz está implicado.
Certificados, entidades de certificación y tokens de cuenta de servicio en AKS
AKS genera y usa los siguientes certificados, entidades de certificación (CA) y tokens de cuentas de servicio (SA):
| Certificate | Description | Método de rotación |
|---|---|---|
| Entidad de certificación del clúster | Creado por AKS en su nombre y es único para el clúster. Este certificado de CA se utiliza para emitir certificados de cliente y de servidor para los kubelets que se ejecutan en el plano de datos y el certificado que utiliza el servidor de API. | Manual |
| Token de cuenta de servicio | JSON Web Tokens (JWT) firmados por el certificado de la CA del clúster. Los kubelets que se ejecutan en los nodos del agente solicitan y renuevan automáticamente estos tokens. Para obtener más información, consulte Iniciar un pod mediante la proyección de tokens de cuenta de servicio. | Se actualiza automáticamente como parte de la rotación manual de la CA del clúster |
| Certificado de servidor de API | Firmado y emitido por el certificado de entidad de certificación del clúster. Este certificado se usa siempre que se establecen conexiones basadas en TLS con el servidor de API, como con kubectl. |
Se actualiza automáticamente como parte de la rotación manual de la CA del clúster |
| Certificado de servicio de Kubelet | En los clústeres que tienen habilitada la rotación de certificados de servicio de kubelet, el certificado de la CA del clúster es el que emite y firma este certificado. De lo contrario, el nodo del agente genera y firma automáticamente este certificado. Este certificado establece conexiones basadas en TLS con componentes que necesitan conectarse a cualquiera de los endpoints de servicio de kubelet, como metrics-server. | Automático para clústeres habilitados con la rotación de certificados de servicio de kubelet |
| Certificado de cliente de Kubelet | Firmado y emitido por el certificado de entidad de certificación del clúster. Este certificado usa un protocolo de arranque TLS específico de AKS que proporciona kubelet su certificado de cliente y kubeconfig correspondiente antes de que se inicie kubelet. El protocolo TLS de AKS solo está habilitado en clústeres de Kubernetes versión 1.32 o posterior. | Se actualiza automáticamente de manera predeterminada mediante el mecanismo de arranque inicial estándar de TLS y como parte de la rotación manual de la CA del clúster |
kubectl certificado de cliente |
Se usa para la autenticación basada en certificados con el servidor de API. | Rotación manual después de la rotación manual de CA del clúster |
Nota
AKS no administra ningún certificado creado para o específico de la carga de trabajo de un cliente.
Rotación automática de certificados en AKS
AKS rota automáticamente los siguientes certificados:
- Los clústeres creados después de marzo de 2022 con RBAC de Kubernetes habilitado tienen activada de forma predeterminada la autorrotación del certificado de cliente de kubelet.
Nota
Es posible que tenga que rotar periódicamente estos certificados manualmente por motivos de seguridad o directiva. Por ejemplo, puede tener una directiva para rotar todos los certificados cada 90 días. De forma predeterminada, la rotación automática del certificado de cliente de kubelet se realiza manualmente.
Limitaciones para la rotación automática de certificados
Las siguientes limitaciones se aplican a la rotación automática de certificados:
- El clúster debe usar el arranque tls de vainilla o el arranque tls seguro de AKS, que se está implementando de forma predeterminada en todas las regiones de Azure.
- Para los clústeres existentes, debe actualizar el clúster para habilitar la rotación automática de certificados.
Rotación manual de certificados en AKS
Debe rotar manualmente los siguientes certificados:
- Certificados de CA del clúster mediante
az aks rotate-certs. -
kubectlcertificados de cliente con el comandoaz aks get-credentials(después de la rotación manual del certificado de la CA del clúster).
Al rotar el certificado de entidad de certificación del clúster, también se actualizan los siguientes certificados secundarios:
- Tokens de cuenta de servicio (SA)
- Certificados de servidor de API
- Certificados de cliente de Kubelet
- Certificados de servidor kubelet (si la rotación de certificados de servicio de kubelet está habilitada en el clúster)
Después de rotar el certificado de la CA del clúster, también debe rotar manualmente los certificados de cliente kubectl para garantizar el acceso continuo al servidor API.
Inicialización TLS para el certificado de cliente de kubelet
Kubelet usa un protocolo de arranque TLS específico de AKS y se basa en la identidad del nodo dentro de Entra ID. Esta identidad proporciona kubelet su certificado de cliente y kubeconfig correspondiente antes de que se inicie kubelet. Este cambio pretende reforzar la seguridad de los nodos de AKS eliminando la dependencia de kubelet de un secreto estático de token de arranque para registrarse en el servidor API. Si se produce un error en el protocolo de arranque TLS seguro por cualquier motivo, kubelet todavía puede registrarse con el servidor de API mediante un token de arranque y el nodo finalmente estará listo. Verá aksService (en lugar de system:bootstrap:<>) en el campo de solicitante de los objetos de solicitud de firma de certificado (CSR) creados por el protocolo.
El certificado de cliente kubelet todavía se encuentra dentro de /var/lib/kubelet/pki/kubelet-client-current.pem en nodos de Linux y C:\k\pki\kubelet-client-current.pem en nodos de Windows. Bootstrap-kubeconfig todavía se encuentra en el mismo lugar. AKS continúa rotando automáticamente este certificado como parte de su proceso de rotación de certificados.
Rotación de certificados de servicio de Kubelet
La rotación de certificados de servidor de kubelet permite a AKS usar el arranque de TLS del servidor de kubelet tanto para el arranque como para la rotación de certificados de servidor firmados por la entidad de certificación del clúster.
Para obtener más información, consulte Administración y rotación de certificados en Azure Kubernetes Service (AKS).
Limitaciones de la rotación del certificado de servidor de Kubelet
- Se admite en la versión 1.27 y posteriores de Kubernetes.
- No se admite cuando el grupo de nodos usa una instantánea del grupo de nodos basada en cualquier imagen de nodo anterior a
202501.12.0. - Esta característica no se puede habilitar manualmente. Los grupos de nodos existentes tienen kubelet que atiende la rotación de certificados habilitada de forma predeterminada después de realizar su primera actualización a cualquier versión 1.27 o posterior de Kubernetes. Los nuevos grupos de nodos con la versión 1.27 o posterior de Kubernetes tienen habilitada de forma predeterminada la rotación del certificado de servicio de kubelet. Para ver si la rotación de certificados de servicio de kubelet está habilitada en su región, consulte Versiones de AKS.
- RBAC de Kubernetes debe estar habilitado en el clúster para que la rotación del certificado de servidor de kubelet esté habilitada. Si tiene un clúster existente, debe actualizar ese clúster para habilitar RBAC de Kubernetes.