Compartir a través de

Introducción a la administración de certificados en AKS habilitado por Azure Arc

  • Artículo

Se aplica a: AKS en Azure Stack HCI 22H2, AKS en Windows Server

AKS habilitado por Azure Arc usa una combinación de certificados y autenticación basada en tokens para proteger la comunicación entre servicios (o agentes) responsables de diferentes operaciones dentro de la plataforma. La autenticación basada en certificados usa un certificado digital para identificar una entidad (agente, máquina, usuario o dispositivo) antes de conceder acceso a un recurso.

Agente en la nube

Al implementar AKS habilitado por Arc, AKS instala agentes que se usan para realizar diversas funciones dentro del clúster. Estos agentes incluyen:

  • Agente en la nube: un servicio responsable de la orquestación de la plataforma subyacente.
  • Agente de nodo: un servicio que reside en cada nodo que realiza el trabajo real de creación de una máquina virtual, de eliminación, etc.
  • Pod del sistema de administración de claves (KMS): un servicio responsable de la administración de claves.
  • Otros servicios: operador en la nube, administrador de certificados, etc.

El servicio de agente en la nube en AKS es responsable de orquestar las operaciones de creación, lectura, actualización y eliminación (CRUD) de componentes de infraestructura, como máquinas virtuales (VM), interfaces de red virtual (VNIC) y redes virtuales (VNET) en el clúster.

Para comunicarse con el agente en la nube, los clientes requieren que se aprovisionen certificados para proteger esta comunicación. Cada cliente requiere que se le asocie una identidad, lo cual define las reglas de control de acceso basado en roles (RBAC) asociadas al cliente. Cada identidad consta de dos entidades:

  • Un token, que se usa para la autenticación inicial y devuelve un certificado.
  • Un certificado, que se obtiene del proceso de inicio de sesión anterior y que se usa para la autenticación en cualquier comunicación.

Cada entidad es válida durante un período de tiempo específico (el valor predeterminado es de 90 días) y expira al final de este período. Para el acceso continuo al servicio de agente en la nube, cada cliente requiere que se renueve el certificado y se rote el token.

Tipos de certificado

Arc usa dos tipos de certificados en AKS habilitados:

  • Certificado de entidad de certificación del agente en la nube: el certificado que se usa para firmar o validar los certificados de cliente. Este certificado es válido durante 365 días (1 año).
  • Certificados de cliente: certificados emitidos por la entidad de certificación del agente en la nube para que los clientes se autentiquen en el agente en la nube. Estos certificados suelen ser válidos durante 90 días.

Microsoft recomienda actualizar los clústeres en un plazo de 60 días a partir de una nueva versión, no solo para garantizar que los certificados y tokens internos se mantengan actualizados, sino también para asegurarse de obtener acceso a nuevas características, correcciones de errores y mantenerse al día con las actualizaciones de seguridad críticas. Durante estas actualizaciones mensuales, el proceso de actualización rota los tokens que no se pueden rotar automáticamente durante las operaciones normales del clúster. La validez del certificado y del token se restablece en los 90 días predeterminados a partir de la fecha en que se actualiza el clúster.

Protección de la comunicación con certificados en AKS habilitados por Arc

Los certificados se utilizan para generar una comunicación segura entre los componentes de un clúster. AKS proporciona aprovisionamiento sin intervención y administración de certificados para componentes integrados de Kubernetes. En este artículo, aprenderá a aprovisionar y administrar certificados en AKS habilitado por Arc.

Certificados y CA

AKS genera y usa las siguientes entidades de certificación (CA) y certificados.

CA de 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 kubelet.
  • Cada kubelet uno también crea una solicitud de firma de certificado (CSR), que está firmada por la ENTIDAD de certificación del clúster, para la comunicación desde al kubelet servidor de API.
  • El almacén de valores de clave de etcd tiene un certificado firmado por la CA del clúster para la comunicación desde etcd al servidor de la API.

etcd CA

El almacén de valores de clave de etcd tiene una CA de etcd que firma los certificados para autenticar y autorizar la replicación de datos entre las réplicas de etcd en el clúster.

CA de proxy frontal

La CA de proxy frontal protege la comunicación entre el servidor de la API y el servidor de la API de extensiones.

Aprovisionamiento de certificados

El aprovisionamiento de certificados para se kubelet realiza mediante el arranque tls. Para los demás certificados, use la clave basada en YAML y la creación de certificados.

  • Los certificados se almacenan en /etc/kubernetes/pki.
  • Las claves son RSA 4096, EcdsaCurve: P384.

Nota:

Los certificados raíz son válidos durante 10 años. Todos los demás certificados no raíz son de corta duración y son válidos durante cuatro días.

Renovación y administración de certificados

Los certificados que no son raíz se renuevan automáticamente. Todos los certificados del plano de control para Kubernetes, excepto los certificados siguientes, se administran:

  • Certificado de servidor kubelet
  • Certificado de cliente kubeconfig

Como procedimiento recomendado de seguridad, debe usar el inicio de sesión único de Active Directory para la autenticación de usuario.

Revocación de certificados

La revocación de certificados debe ser poco frecuente y debe realizarse en el momento de la renovación del certificado.

Una vez que tenga el número de serie del certificado que quiere revocar, use el recurso personalizado de Kubernetes para definir y conservar la información de revocación. Cada objeto de revocación puede constar de una o varias entradas de revocación.

Para realizar una revocación, use una de las siguientes opciones:

  • Número de serie
  • Grupo
  • Nombre DNS
  • Dirección IP

Se puede especificar una notBefore hora para revocar solo los certificados emitidos antes de una marca de tiempo determinada. Si no se especifica una notBefore hora, se revocarán todos los certificados existentes y futuros que coincidan con la revocación.

Nota:

La revocación de certificados de kubelet servidor no está disponible actualmente.

Si usa un número de serie al realizar una revocación, puede usar el Repair-AksHciClusterCerts comando de PowerShell, que se describe a continuación, para que el clúster entre en un estado de trabajo. Si usa cualquiera de los otros campos enumerados anteriormente, asegúrese de especificar una notBefore hora.

apiVersion: certificates.microsoft.com/v1 
kind: RenewRevocation 
metadata: 
  name: my-renew-revocation 
  namespace: kube-system 
spec: 
  description: My list of renew revocations 
  revocations: 
  - description: Revoked certificates by serial number 
    kind: serialnumber 
    notBefore: "2020-04-17T17:22:05Z" 
    serialNumber: 77fdf4b1033b387aaace6ce1c18710c2 
  - description: Revoked certificates by group 
    group: system:nodes 
    kind: Group 
  - description: Revoked certificates by DNS 
    dns: kubernetes.default.svc. 
    kind: DNS 
  - description: Revoked certificates by DNS Suffix 
    dns: .cluster.local 
    kind: DNS 
  - description: Revoked certificates by IP 
    ip: 170.63.128.124 
    kind: IP

Pasos siguientes