Rotación de certificados en Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) usa certificados para la autenticación con muchos de sus componentes. Debe rotar periódicamente esos certificados por motivos de seguridad o directiva. En este artículo, se muestra cómo funciona la rotación de certificados en el clúster de AKS.

Prerrequisitos

• En este artículo se necesita la CLI de Azure versión 2.0.77 o posterior. Compruebe la versión con el comando az --version. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

• Configure kubectl para conectarse al clúster de AKS mediante el az aks get-credentials comando :

  az aks get-credentials --resource-group <resource-group> --name <cluster-name>
  

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 de clúster, que firma certificados para la comunicación unidireccional desde el servidor de API a kubelet.
• 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 de agente utiliza un token de SA, que la autoridad de certificación del clúster firma.
• 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.

Fechas de expiración del certificado

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 de API mediante el comando siguiente curl :

  curl https://{apiserver-fqdn} -k -v 2>&1 | grep expire
  

Comprobación de la fecha de expiración del certificado del nodo del agente (VM) de la máquina virtual

• Compruebe la fecha de expiración del certificado de nodo del agente de máquina virtual mediante el az vm run-command invoke comando .

  Parámetros clave en este comando: --resource-group <node-resource-group>: el grupo de recursos que contiene el nodo del agente de máquina virtual. - --name <vm-name>: el nombre del nodo del agente de máquina virtual. - --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate": script que recupera la fecha de expiración del certificado de servidor de API ubicado en /etc/kubernetes/certs/apiserver.crt.

  az vm run-command invoke --resource-group <node-resource-group> --name <vm-name> --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"
  

Comprobación de la expiración del certificado para el nodo del agente del conjunto de escalado de máquinas virtuales de Azure

• Compruebe la fecha de expiración del certificado del nodo del agente del conjunto de escalado de máquinas virtuales de Azure mediante el az vmss run-command invoke comando .

  Parámetros clave en este comando: --resource-group <node-resource-group>: el grupo de recursos que contiene el nodo del agente del conjunto de escalado de máquinas virtuales de Azure. - --name <vmss-name>: nombre del conjunto de escalado de máquinas virtuales de Azure. - --instance-id 1: el identificador de instancia del nodo del agente del conjunto de escalado de máquinas virtuales de Azure. - --scripts "openssl x509 -in  /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate": script que recupera la fecha de expiración del certificado de cliente kubelet ubicado en /var/lib/kubelet/pki/kubelet-client-current.pem.

  az vmss run-command invoke --resource-group <node-resource-group> --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 manual de los certificados del clúster

1. 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 <cluster-name>
   

   Importante

   El comando az aks rotate-certs vuelve a crear todos sus nodos de agente, Virtual Machine Scale Sets de Azure y discos. Este comando también puede provocar hasta 30 minutos de tiempo de inactividad para el clúster de AKS. Si se produce un error en el comando antes de completarse, use el comando [az aks show][az-aks-show] para comprobar que el estado del clúster es Certificate Rotating. Si el clúster está en estado de error, vuelva a ejecutar el az aks rotate-certs comando para volver a rotar los certificados.

2. Compruebe que los certificados antiguos ya no son válidos mediante ningún kubectl comando. En el ejemplo siguiente se usa el kubectl get nodes comando :

   kubectl get nodes
   

   Si no actualizó los certificados usados por kubectl, verá un error similar al siguiente resultado 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")
   

3. Actualice el certificado usado por kubectl usando el comando az aks get-credentials con la marca --overwrite-existing.

   az aks get-credentials --resource-group <resource-group> --name <cluster-name> --overwrite-existing
   

4. Compruebe que los certificados se actualizan mediante el kubectl get comando .

   kubectl get nodes
   

Si tiene algún servicio que se ejecute sobre AKS, es posible que tenga que actualizar también sus certificados.

Rotar el certificado de servicio del kubelet

Cuando se rota el certificado de servicio del kubelet, AKS permite el arranque de seguridad de la capa de transporte (TLS) del servidor kubelet tanto para el arranque inicial como para la rotación de certificados de servicio firmados por la CA del clúster.

Limitaciones de la rotación de certificados de servicio 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. La rotación de certificados de servicio de Kubelet está habilitada de forma predeterminada en los grupos de nodos existentes cuando realizan su primera actualización a cualquier versión 1.27 o posterior de Kubernetes. La rotación de certificados de servicio de Kubelet está habilitada de forma predeterminada en nuevos grupos de nodos mediante kubernetes versión 1.27 o posterior. Para ver si la rotación de certificados de servicio de kubelet está habilitada en su región, compruebe las versiones de AKS.

Comprobación de que la rotación de certificados de servicio de kubelet está habilitada

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 establecen mediante el kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca comando .

  kubectl get nodes -L kubernetes.azure.com/kubelet-serving-ca
  

  La salida debe mostrar la etiqueta kubernetes.azure.com/kubelet-serving-ca con el valor cluster de cada nodo del agente.

Verifique que la inicialización TLS de kubelet está funcionando

• Compruebe que el proceso de arranque se está llevando a cabo mediante el kubectl get comando .

  kubectl get csr --field-selector=spec.signerName=kubernetes.io/kubelet-serving
  

  En la salida, todos los CSR de servicio deben estar en el estado Approved,Issued, lo que indica que el CSR fue aprobado y se le emitió un certificado firmado. Los CSR activos tienen un nombre de firmante de kubernetes.io/kubelet-serving. Por ejemplo:

  NAME        AGE    SIGNERNAME                                    REQUESTOR                    REQUESTEDDURATION   CONDITION
  csr-1ab2c   113s   kubernetes.io/kube-apiserver-client-kubelet   system:bootstrap:uoxr9r      none              Approved,Issued
  csr-defgh   111s   kubernetes.io/kubelet-serving                 system:node:akswinp7000000   none              Approved,Issued
  csr-ij3kl   46m    kubernetes.io/kubelet-serving                 system:node:akswinp6000000   none              Approved,Issued
  csr-mn4op   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

• Confirme que kubelet utiliza un certificado de servicio firmado por la CA del clúster mediante el comando kubectl debug.

  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 un vínculo simbólico kubelet-server-current.pem existe, entonces el kubelet arrancó/rotó su propio certificado de servicio, y la CA del clúster lo firmó.

Deshabilitación de la rotación de certificados de servicio de kubelet

• Deshabilite la rotación de certificados de kubelet al actualizar el grupo de nodos con el comando az aks nodepool update con la etiqueta aks-disable-kubelet-serving-certificate-rotation=true.

  az aks nodepool update --cluster-name <cluster-name> --resource-group <resource-group> --name <node-pool-name> --tags aks-disable-kubelet-serving-certificate-rotation=true
  

1. Restablezca la imagen inicial de sus nodos utilizando una actualización de imagen de nodo o escalando el grupo a cero instancias y luego nuevamente al valor deseado.

Autorotación de los certificados

Tenga en cuenta las siguientes consideraciones al usar la autorotación de certificados:

• Si tiene un clúster existente, debe actualizar ese clúster para habilitar la rotación automática de certificados.
• No deshabilite TLS Bootstrap para mantener habilitada la habilitación automática de certificados.
• 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, AKS rota automáticamente los certificados que no son de CA en el plano de control y en los nodos del agente dentro de 80% del tiempo válido del certificado de cliente antes de que expiren sin tiempo de inactividad para el clúster.

Verificar que el arranque TLS esté habilitado en el grupo de nodos del agente actual

1. Compruebe que el clúster tiene habilitado TLS Bootstrapping; para ello, navegue a una de 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 de Windows: C:\k\bootstrap-config

   para más información, consulte Conexión a los nodos de clúster de Azure Kubernetes Service (AKS) para mantenimiento o solución de problemas.

   Nota

   La ruta de acceso del archivo puede cambiar a medida que evolucionan las versiones de Kubernetes.

2. Una vez configurada una región, cree un nuevo clúster o actualice un clúster existente para configurar la rotación automática de certificados para el certificado del clúster. Debe actualizar el plano de control y el grupo de nodos para habilitar esta característica.

Contenido relacionado

• Procedimientos recomendados para la seguridad y las actualizaciones del clúster en Azure Kubernetes Service (AKS).