Rotación de certificados en Azure Kubernetes Service (AKS)
Azure Kubernetes Service (AKS) usa certificados para la autenticación con muchos de sus componentes. Los clústeres con control de acceso basado en roles de Azure (Azure RBAC) que se crearon después de marzo de 2022 están habilitados con rotación automática de certificados. Puede que necesite rotar periódicamente esos certificados por motivos de seguridad o de directivas. Por ejemplo, puede establecer una directiva para girar todos los certificados cada 90 días.
Nota:
La rotación automática de certificados solo se habilita de manera 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
Este proceso puede tardar hasta 30 minutos para que
az aks rotate-certs
se complete. Si se produce un error en el comando antes de finalizar, useaz aks show
para comprobar que el estado del clúster esaz aks show
(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.
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