Compartir a través de

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

  • Artículo

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?

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

  2. 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.

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

  2. 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, use az aks show para comprobar que el estado del clúster es az aks show (Rotación de certificados). Si el clúster se encuentra en un estado de error, vuelva a ejecutar az aks rotate-certs para rotar los certificados otra vez.

  3. Compruebe que los certificados antiguos ya no son válidos usando cualquier comando kubectl, como kubectl 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")

  4. 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 --name $CLUSTER_NAME --overwrite-existing

  5. 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).