Despliegue gestor de certificados para Kubernetes habilitado por Arc (vista previa)

Este artículo muestra cómo desplegar el gestor de certificados para la extensión Kubernetes habilitada por Arc (vista previa) en tus clústeres conectados a Arc. Se incluyen los pasos para una nueva implementación, junto con los requisitos para migrar desde un clúster que tiene código abierto cert-manager y trust-manager.

Prerrequisitos

Antes de instalar CME, asegúrese de cumplir los siguientes requisitos previos:

• Una cuenta de Azure. Si no tienes una, crea una cuenta gratuita antes de empezar.

• Un clúster Kubernetes habilitado para Arc desplegado en una regiónsoportada. Para obtener mejores resultados, utiliza una distribución Kubernetes que haya sido validada para su uso con cert-manager para Kuberneteshabilitado con Arc. Si aún no ha conectado el clúster a Azure Arc, siga nuestra guía de inicio rápido. Establezca variables de entorno para el nombre del clúster y Azure grupo de recursos, ya que los necesitará para instalar la extensión.

  export CLUSTER_NAME="AzureArcTest1"
  export RESOURCE_GROUP="AzureArcTest"
  

• El Administrador de Recursos de Máquina Conectada de Azure o un rol equivalente en el recurso del clúster que le permite implementar extensiones.

• La versión más reciente de CLI de Azure.

• La versión más reciente de las extensiones connectedk8s y k8s-extension CLI de Azure. Ejecute estos comandos para instalar o actualizar las extensiones:

  az extension add --upgrade -n connectedk8s
  az extension add --upgrade -n k8s-extension
  

• Una versión instalada de kubectl para el clúster (privilegios de administrador). Aunque no es estrictamente necesario para instalar la extensión, kubectl es útil para comprobar la instalación y administrar recursos personalizados de certificado en pasos posteriores.

• Si instaló anteriormente código abierto cert-manager o trust-manager manualmente, desinstálelos antes de implementar la extensión de Arc para evitar conflictos. La extensión conservará y reconocerá los recursos personalizados existentes (CA), siempre y cuando cumplan las convenciones de los proyectos de código abierto. Para más información, véase Migrar desde gestor de certificados de código abierto y gestorde fideos.

Los conocimientos generales sobre Kubernetes con Arc habilitado, cert-manager y trust-manager pueden ser útiles, pero no son necesarios para desplegar la extensión.

Desplegar cert-manager para Kubernetes con soporte de Arc

Para implementar cert-manager para Kubernetes con Arc habilitado (versión preliminar) en un clúster que aún no tiene cert-manager ni trust-manager, y que cumple los prerrequisitos, use el siguiente comando:

az k8s-extension create \
  --resource-group ${RESOURCE_GROUP} \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --name "azure-cert-management" \
  --extension-type "microsoft.certmanagement"

Recibirá automáticamente actualizaciones de versiones secundarias, que incluyen nuevas características y cambios no importantes. Si prefiere actualizar manualmente la extensión cuando sea necesario para obtener las características y correcciones más recientes, puede agregar --auto-upgrade-minor-version false.

Después de que CLI de Azure confirme que la instalación se realizó correctamente, verifique que los componentes se ejecutan en el clúster.

Entornos de PSA restringidos

Cert-manager para Kubernetes habilitado por Azure Arc requiere acceso con privilegios para la recopilación de registros en Azure con fines de soporte técnico y solución de problemas. Para entornos con estándares de seguridad de pod restringidos en los que PSA no permite el acceso con privilegios, la recopilación de registros en Azure se puede deshabilitar para cumplir los requisitos de seguridad.

Para deshabilitar la recopilación de registros, use --configuration-settings global.telemetry.logs.enabled=false. Esto evita que los volúmenes de registro se configuren y elimina la necesidad de acceso con privilegios, mientras que la recopilación de métricas continúa como de costumbre.

Para deshabilitar la recopilación de métricas, use --configuration-settings global.telemetry.metrics.enabled=false.

Migrar de gestor de certificados de código abierto y gestor de confianza

El gestor de certificados para la extensión Kubernetes habilitada con Azure Arc sirve como sustituto tanto del gestor de certificados de código abierto como del gestorde confianzas. Antes de instalar cert-manager para Kubernetes con habilitación para Arc, debe desinstalar los recursos de código abierto.

Los pasos específicos para la desinstalación dependen del método de instalación. Para obtener instrucciones, consulte la documentación para desinstalar cert-manager y desinstalar trust-manager. Si usó Helm para la instalación, use este comando para verificar en qué espacios de nombres están instalados el cert-manager y el trust-manager.

helm list -A | grep -E 'trust-manager|cert-manager'

Después, use los siguientes comandos para desinstalar:

helm uninstall cert-manager -n "your namespace" --ignore-not-found
helm uninstall trust-manager -n "your namespace" --ignore-not-found

Configurar el gestor de certificados para Kubernetes habilitado con Arc

Después de desplegar el gestor de certificados para la extensión Kubernetes habilitada por Arc, configura cómo deben emitirse los certificados y luego solicita un certificado para una carga de trabajo. En un alto nivel, los pasos son:

1. Cree un recurso Issuer o ClusterIssuer para especificar una entidad de certificación (CA) que generará certificados firmados. Podría tratarse de una CA autofirmada, una cuenta registrada con un servidor de CA del entorno de administración de certificados automatizado (ACME), como Let's Encrypt (u otros) o una ENTIDAD de certificación cuyo certificado y clave privada se almacenan dentro del clúster como un secreto de Kubernetes.
2. Cree un recurso de certificado que solicite un certificado TLS e incluya los campos que se utilizan para generar Solicitudes de Firma de Certificado (CSRs), los cuales son cumplidos por el tipo de emisor referenciado en el recurso para un dominio o uso específico.
3. Deje que cert-manager cumpla la solicitud, lo que da como resultado un certificado firmado y una clave privada que se almacenan en un secreto de Kubernetes que la aplicación puede usar.
4. Opcionalmente, si el escenario requiere raíces de confianza personalizadas entre espacios de nombres, use trust-manager para distribuir los certificados de CA personalizados en todo el clúster.

En las secciones siguientes se explica un escenario de ejemplo para emitir un certificado autofirmado para un servicio en clúster.

Creación de un ClusterIssuer autofirmado

Creación de un clusterIssuer (CA autofirmado)

En primer lugar, configure un ClusterIssuer que use un certificado autofirmado como entidad de certificación. Este ClusterIssuer actuará como una autoridad certificadora interna para el clúster, firmando certificados para tus cargas de trabajo. La entidad de certificación debe estar respaldada por claves privadas generadas por RSA con una longitud mínima de 4096 bits.

En este ejemplo se usa un certificado autofirmado para demostrar el proceso, que es adecuado para la comunicación o las pruebas entre clústeres, pero no se recomienda para cargas de trabajo de producción.

Aplique el siguiente manifiesto YAML para crear un clusterIssuer autofirmado:

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: selfsigned-cluster-ca
  spec:
    selfSigned: {}
EOF

Esto define un ClusterIssuer denominado selfsigned-cluster-ca que emite certificados autofirmados (lo que significa que genera eficazmente un certificado de entidad de certificación raíz para la firma). Después de definir ClusterIssuer, cert-manager genera automáticamente una clave raíz y un certificado para este emisor en segundo plano. Almacena el certificado de CA generado y la clave en un secreto (por defecto denominado selfsigned-cluster-ca-cert en el mismo espacio de nombres que cert-manager, normalmente denominado cert-manager)

Creación de un certificado firmado por ClusterIssuer

Ahora solicite un certificado para un propósito específico (por ejemplo, autenticación de carga de trabajo). Crea un recurso de certificado que solicite un certificado para un nombre interno como domain my-service.mydomainlocal, firmado por la nueva CA del clúster auto-firmada.

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: Certificate
  metadata:
    name: my-service-cert
    namespace: default  # or the namespace where your application resides
  spec:
    secretName: my-service-tls 
    duration: 2160h            # 90 days (default) 
    renewBefore: 360h          # renew 15 days before expiration
    commonName: my-service.mydomain.local
    dnsNames:
    - my-service.mydomain.local
    issuerRef:
      name: selfsigned-cluster-ca     
      kind: ClusterIssuer
    privateKey:
      algorithm: RSA
      encoding: PKCS1
      size: 4096
      rotationPolicy: Always       
EOF

Esta especificación incluye los siguientes campos:

• secretName: my-service-tls es donde se almacenará el certificado TLS y la clave resultantes (como un secreto en el mismo espacio de nombres). Las aplicaciones usarán este secreto.
• commonName y dnsNames especificar el(los) nombre(s) del sujeto para el certificado. En este ejemplo se usa un nombre DNS de servicio ficticio.
• issuerRef Apunta al emisor que creaste. Configura kind: ClusterIssuer y name para que te haga referencia a tu CA ClusterIssuer auto-firmado.

En pocos segundos, el gestor de certificados genera una clave privada y crea una CertificateSigningRequest para el emisor referenciado. Dado que este emisor está autofirmado, cert-manager actuará como firmante mediante la clave de CA que generó anteriormente.

Distribuir el paquete de confianza (opcional)

Si solo usas certificados autofirmados dentro de tu clúster, puede que quieras que todas las cargas de trabajo confíen en la CA raíz autofirmada del clúster a través de los espacios de nombres. El gestor de confianza puede distribuir la autoridad certificadora como ConfigMap cuando sea necesario.

Crea un Certificate recurso para almacenar la CA autofirmada en el secreto selfsigned-cluster-ca-cert:

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: Certificate
  metadata:
    name: selfsigned-cluster-ca-cert
    namespace: cert-manager
  spec:
    isCA: true
    commonName: selfsigned-cluster-ca-cert
    secretName: selfsigned-cluster-ca-cert
    privateKey:
      algorithm: ECDSA
      size: 256
      rotationPolicy: Always      
    issuerRef:
      name: selfsigned-cluster-ca
      kind: ClusterIssuer
      group: cert-manager.io
EOF

Cree un recurso Bundle para configurar trust manager y distribuir el certificado de autoridad de certificación.

cat <<EOF | kubectl apply -f -
  apiVersion: trust.cert-manager.io/v1alpha1
  kind: Bundle
  metadata:
    name: cluster-ca-bundle
    namespace: cert-manager
  spec:
    sources:
    - secret:
        name: selfsigned-cluster-ca-cert
        key: tls.crt
    target:
      configMap:
        key: ca.crt
EOF

Esta configuración indica a trust-manager que tome los datos del certificado del secreto especificado (selfsigned-cluster-ca-cert) y los publique en un ConfigMap llamado cluster-ca-bundle en todos los namespaces. El ConfigMap tiene una entrada ca.crt de datos que contiene el certificado de autoridad certificadora. Al aplicar este paquete, trust-manager creará y actualizará configMaps en consecuencia.

Cualquier pod puede entonces montar el cluster-ca-bundle ConfigMap para confiar en la CA personalizada, o el ConfigMap puede ser referenciado por otras extensiones. Utilizar un paquete de confianza es especialmente útil si se utiliza una CA corporativa; De forma similar, distribuirías esa CA a todos los pods que necesiten confiar en ella.

Eliminar el gestor de certificados para Kubernetes habilitado por Arc (vista previa)

Para desinstalar el gestor de certificados de la extensión Kubernetes habilitada para Arc (previsualización), utilice el siguiente comando:

az k8s-extension delete \
  --resource-group ${RESOURCE_GROUP} \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --name "azure-cert-management"

Este comando quita las implementaciones cert-manager y trust-manager. No quita secretos ni mapas de configuración para conjuntos de confianza, pero quita los controladores que los mantienen actualizados. Los certificados o emisores que haya creado permanecerán y los usuarios de esos certificados podrán seguir utilizándolos hasta que expiren. Para eliminar completamente el gestor de certificados del clúster, elimina los certificados y recursos del emisor que creaste, así como cualquier secreto que se haya generado.