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) usa certificados para la autenticación con muchos de sus componentes. Los clústeres con el control de acceso basado en rol de Azure (RBAC de Azure) creados después de marzo de 2022 están habilitados con la rotación automática de certificados. Es posible que tenga que rotar periódicamente esos certificados por motivos de seguridad o directiva. Por ejemplo, puede tener una directiva para rotar todos los certificados cada 90 días.
Nota
La rotación automática de certificados solo está habilitada de forma predeterminada para clústeres de AKS habilitados para RBAC.
En este artículo, se muestra cómo funciona la rotación de certificados en el clúster de AKS.
Antes de empezar
En este artículo se necesita la CLI de Azure versión 2.0.77 o posterior. Ejecute az --version
para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.
Certificados de AKS, entidades de certificación y cuentas de servicio
AKS genera y usa los siguientes certificados, entidades de certificación (CA) y cuentas de servicio (SA):
- El servidor de API de AKS crea una entidad de certificación denominada CA del clúster.
- El servidor de API tiene una CA del clúster que firma los certificados para la comunicación unidireccional desde el servidor de API a kubelets.
- Cada kubelet crea una solicitud de firma de certificado (CSR), que firma la CA del clúster, para la comunicación del kubelet con el servidor de API.
- El agregador de API usa la CA del clúster para emitir certificados para la comunicación con otras API. El agregador de API también puede tener su propia CA para emitir esos certificados, pero actualmente usa la CA del clúster.
- Cada nodo usa un tokens SA, que firma la CA del clúster.
- El cliente
kubectl
tiene un certificado para comunicarse con el clúster de AKS.
Microsoft mantiene todos los certificados mencionados en esta sección, excepto el certificado de clúster.
Nota
- Los clústeres de AKS creados antes de mayo de 2019 tienen certificados que caducan a los dos años.
- Los clústeres de AKS creados después de mayo de 2019 tienen certificados de entidad de certificación de clúster que caducan a los 30 años.
Puede verificar cuándo se creó su clúster usando el comando kubectl get nodes
, que le muestra la antigüedad de sus grupos de nodos.
Comprobar las fechas de expiración de los certificados
Comprobar la fecha de expiración del certificado del clúster
Compruebe la fecha de expiración del certificado de clúster mediante el comando
kubectl config view
.kubectl config view --raw -o jsonpath="{.clusters[?(@.name == '')].cluster.certificate-authority-data}" | base64 -d | openssl x509 -text | grep -A2 Validity
Comprobar la fecha de expiración del certificado del servidor API
Compruebe la fecha de expiración del certificado del servidor API usando el siguiente comando
curl
.curl https://{apiserver-fqdn} -k -v 2>&1 | grep expire
Comprobar la fecha de expiración del certificado de nodo del agente VMAS
Compruebe la fecha de expiración del certificado del nodo agente VMAS usando el comando
az vm run-command invoke
.az vm run-command invoke --resource-group MC_rg_myAKSCluster_region --name vm-name --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"
Comprobar la expiración del certificado para el nodo del agente del conjunto de escalado de máquinas virtuales
Compruebe la fecha de expiración del certificado del nodo del agente del conjunto de escalado de máquinas virtuales usando el comando
az vmss run-command invoke
.az vmss run-command invoke --resource-group "MC_rg_myAKSCluster_region" --name "vmss-name" --command-id RunShellScript --instance-id 1 --scripts "openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate" --query "value[0].message"
Rotación automática de certificados
Para que AKS rote automáticamente los certificados que no son de una entidad de certificación, el clúster debe tener un arranque de TLS que se habilita de forma predeterminada en todas las regiones de Azure.
Nota
- Si tiene un clúster existente, debe actualizar ese clúster para habilitar la rotación automática de certificados.
- No deshabilite el arranque para mantener la rotación automática habilitada.
- Si el clúster se encuentra en estado detenido durante la rotación automática de certificados, solo se rotan los certificados del plano de control. En este caso, debe volver a crear el grupo de nodos después de la rotación de certificados para iniciar la rotación de certificados del grupo de nodos.
En el caso de los clústeres de AKS creados o actualizados después de marzo de 2022, Azure Kubernetes Service rota automáticamente los certificados que no son de CA en el plano de control y los nodos de agente dentro del 80 % del tiempo válido del certificado de cliente, antes de que expiren sin tiempo de inactividad para el clúster.
¿Cómo comprobar si el grupo de nodos de agente actual está habilitado para el arranque TLS?
Compruebe si el clúster tiene habilitado el arranque de TLS; para ello, vaya a una a las siguientes rutas de acceso:
- En un nodo de Linux: /var/lib/kubelet/bootstrap-kubeconfig o /host/var/lib/kubelet/bootstrap-kubeconfig
- En un nodo Windows: C:\k\bootstrap-config
Para más información, consulte Conexión a los nodos de clúster de Azure Kubernetes Service para mantenimiento o solución de problemas.
Nota
La ruta de acceso del archivo puede cambiar a medida que evolucionan las versiones de Kubernetes.
Una vez configurada una región, cree un nuevo clúster o actualice uno existente para establecer la rotación automática del certificado del clúster. Debe actualizar el plano de control y el grupo de nodos para habilitar esta característica.
Rotación manual de los certificados del clúster
Advertencia
El uso de az aks rotate-certs
recrea todos sus nodos, conjuntos de escalado de máquinas virtuales y discos y puede provocar hasta 30 minutos de inactividad en su clúster de AKS.
Conéctese a su clúster usando el comando
az aks get-credentials
.az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME
Rote todos los certificados, CA y SA de su clúster usando el comando
az aks rotate-certs
.az aks rotate-certs --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME
Importante
El proceso podría tardar hasta 30 minutos en
az aks rotate-certs
completarse. Si se produce un error en el comando antes de finalizar, useaz aks show
para comprobar que el estado del clúster es Certificate Rotating (Rotación de certificados). Si el clúster se encuentra en un estado de error, vuelva a ejecutaraz aks rotate-certs
para rotar los certificados otra vez.Compruebe que los certificados antiguos ya no son válidos usando cualquier comando
kubectl
, comokubectl get nodes
.kubectl get nodes
Si no ha actualizado los certificados usados por
kubectl
, verá un error similar a la siguiente salida de ejemplo:Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "ca")
Actualice el certificado usado por
kubectl
usando el comandoaz aks get-credentials
con la marca--overwrite-existing
.az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME --overwrite-existing
Compruebe que los certificados se han actualizado usando el comando
kubectl get
.kubectl get nodes
Nota
Si tiene algún servicio que se ejecute sobre AKS, es posible que también tenga que actualizar los certificados.
Rotación de certificados de servicio de Kubelet
La rotación de certificados de servicio de Kubelet permite a AKS usar el arranque TLS del servidor kubelet para el arranque y la rotación de certificados de servicio firmados por la CA del clúster.
Limitaciones
- 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 tendrán kubelet que atiende la rotación de certificados habilitada de forma predeterminada cuando realicen su primera actualización a cualquier versión 1.27 o posterior de Kubernetes. Los nuevos grupos de nodos en Kubernetes versión 1.27 o superior tendrán la rotación de certificados de kubelet habilitada de forma predeterminada. Para ver si se ha habilitado la rotación de certificados de servicio de kubelet en su región, consulte Versiones de AKS.
Comprobación de que se ha habilitado la rotación de certificados de servicio de kubelet
A cada nodo con la característica habilitada se le asigna automáticamente la etiqueta kubernetes.azure.com/kubelet-serving-ca=cluster
. Compruebe que las etiquetas se han establecido con el comando kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca
.
kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca
Comprobación de que kubelet pasa por el proceso de arranque de TLS
Con esta característica habilitada, cada kubelet que ejecuta los nodos debe pasar por el proceso de arranque de TLS servicio.
Compruebe que el proceso de arranque se está llevando a cabo mediante el kubectl get
comando para obtener los objetos CSR actuales del clúster.
kubectl get csr --field-selector=spec.signerName=kubernetes.io/kubelet-serving
Todos los CSR en servicio deben estar en el estado Approved,Issued
, lo que indica que la solicitud de firma de certificado fue aprobada y se emitió un certificado firmado. Los CSR activos tienen un nombre de firmante de kubernetes.io/kubelet-serving
.
NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION
csr-8mx4w 113s kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:uoxr9r none Approved,Issued
csr-bchlj 111s kubernetes.io/kubelet-serving system:node:akswinp7000000 none Approved,Issued
csr-sb4wz 46m kubernetes.io/kubelet-serving system:node:akswinp6000000 none Approved,Issued
csr-zc4wt 46m kubernetes.io/kube-apiserver-client-kubelet system:bootstrap:ho7zyu none Approved,Issued
Comprobación de que kubelet usa un certificado obtenido del arranque TLS del servidor
Para confirmar si el kubelet del nodo usa un certificado de servicio firmado por la ENTIDAD de certificación del clúster, use [kubectl debug
][kubectl-debug] para examinar el contenido del directorio PKI de kubelet.
kubectl debug node/<node> -ti --image=mcr.microsoft.com/azurelinux/base/core:3.0 -- ls -l /host/var/lib/kubelet/kubelet-server-current.pem
Si hay un enlace simbólico kubelet-server-current.pem
, el kubelet ha arrancado o rotado su propio certificado de servicio a través del proceso de arranque mediante TLS y está firmado por la entidad de certificación del clúster.
Deshabilitación de la rotación de certificados de servicio de kubelet
Puede deshabilitar la rotación de certificados de kubelet mediante la actualización del grupo de nodos mediante el comando az aks nodepool update para especificar la etiqueta aks-disable-kubelet-serving-certificate-rotation=true
y, a continuación, volver a configurar los nodos. Se puede realizar una nueva imagen de nodo a través de una actualización de imagen de nodo o mediante el escalado del grupo a 0 instancias y, a continuación, realizar una copia de seguridad del valor deseado.
az aks nodepool update --cluster-name myCluster --resource-group myResourceGroup --name mynodepool --tags aks-disable-kubelet-serving-certificate-rotation=true
Pasos siguientes
Este artículo le muestra cómo rotar manual y automáticamente sus certificados de clúster, CA y SA. Para más información, consulte Procedimientos recomendados para la seguridad de clústeres y actualizaciones en Azure Kubernetes Service (AKS).
Azure Kubernetes Service