Protección de cargas de trabajo con certificados de Kubernetes - Amazon EKS
Ejemplo de CSRCSR en Kubernetes 1.24

Ayude a mejorar esta página

¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.

Protección de cargas de trabajo con certificados de Kubernetes

La API de certificados de Kubernetes automatiza el aprovisionamiento de credenciales X.509. La API cuenta con una interfaz de línea de comandos para que los clientes API de Kubernetes soliciten y obtengan Certificados X.509 de una entidad de certificación (CA). Se puede usar un recurso CertificateSigningRequest (CSR) para solicitar que un firmante indicado firme el certificado. Las solicitudes se aprueban o rechazan antes de firmarlas. Kubernetes admite tanto firmantes integrados como firmantes personalizados con comportamientos bien definidos. De esta forma, los clientes pueden predecir qué sucede con sus CSR. Para obtener más información sobre la firma de certificados, consulte acerca de la firma de solicitudes.

Uno de los firmantes integrados es kubernetes.io/legacy-unknown. La API v1beta1 del recurso de CSR honró a este firmante desconocido de legado. Sin embargo, la API estable de CSR v1 no permite que el signerName se establezca en kubernetes.io/legacy-unknown.

La versión 1.21 de Amazon EKS y las versiones anteriores permitían el valor legacy-unknown como el signerName en la API de CSR v1beta1. Esta API permite a la autoridad de certificación (CA) de Amazon EKS generar certificados. Sin embargo, en la versión 1.22 de Kubernetes, la API de CSR v1beta1 se sustituyó por la API de CSR v1. Esta API no admite el signerName de “legado desconocido”. Si desea utilizar la CA de Amazon EKS para generar certificados en sus clústers, debe usar un firmante personalizado. Se introdujo en la versión de Amazon EKS 1.22. Para utilizar la versión de la API de CSR v1 y generar un nuevo certificado, debe migrar cualquier manifiesto y cliente API existentes. Los certificados existentes creados con las API v1beta1 anteriores son válidas y funcionan hasta que caduque el certificado. Esta incluye lo siguiente:

  • Distribución de confianza: ninguna. No hay confianza o distribución estándar para este firmante en un clúster de Kubernetes.

  • Temas permitidos: cualquiera

  • Extensiones x509 permitidas: honra las extensiones de uso de subjectAltName y clave y descarta otras extensiones

  • Usos de clave permitidos: no debe incluir usos más allá de [“cifrado de clave”, “firma digital”, “autenticación del servidor”]

    nota

    No se admite la firma de certificados de cliente.

  • Vida útil del certificado/caducidad: 1 año (predeterminado y máximo)

  • Bit CA permitido/no permitido: no permitido

Generación de CSR de ejemplo con signerName

En estos pasos se muestra cómo generar un certificado de publicación para el nombre de DNS myserver.default.svc con signerName: beta.eks.amazonaws.com/app-serving. Úselo como guía para su propio entorno.

  1. Ejecute el comando openssl genrsa -out myserver.key 2048 para generar una clave privada RSA.

    openssl genrsa -out myserver.key 2048

  2. Utilice el siguiente comando para generar una solicitud de certificado.

    openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"

  3. Genere un valor base64 para la CSR y almacénelo en una variable para utilizarlo en un paso posterior.

    base_64=$(cat myserver.csr | base64 -w 0 | tr -d "\n")

  4. Ejecute el siguiente comando para crear un archivo llamado mycsr.yaml. En el siguiente ejemplo, beta.eks.amazonaws.com/app-serving es el signerName.

    cat >mycsr.yaml <<EOF
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myserver
spec:
  request: $base_64
  signerName: beta.eks.amazonaws.com/app-serving
  usages:
    - digital signature
    - key encipherment
    - server auth
EOF

  5. Envíe la CSR.

    kubectl apply -f mycsr.yaml

  6. Apruebe el certificado de entrega.

    kubectl certificate approve myserver

  7. Compruebe que se emitió el certificado.

    kubectl get csr myserver

    Un ejemplo de salida sería el siguiente.

    NAME       AGE     SIGNERNAME                           REQUESTOR          CONDITION
myserver   3m20s   beta.eks.amazonaws.com/app-serving   kubernetes-admin   Approved,Issued

  8. Exporte el certificado emitido.

    kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt

Consideraciones sobre la firma de certificados antes de actualizar el clúster a la versión 1.24 de Kubernetes

En la versión 1.23 de Kubernetes y anteriores, los certificados de servicio de kubelet con nombres alternativos de asunto (SAN) de IP y DNS no verificables se emitían automáticamente con SAN no verificables. Los SAN se omiten del certificado aprovisionado. En 1.24 y clústeres posteriores, no se emiten certificados de servicio de kubelet si no se puede verificar un SAN. Esto impide que los comandos kubectl exec y kubectl logs funcionen.

Antes de actualizar el clúster a la versión 1.24, complete los siguientes pasos para determinar si el clúster tiene solicitudes de firma de certificados (CSR) que no se hayan aprobado:

  1. Ejecute el siguiente comando de la .

    kubectl get csr -A

    Un ejemplo de salida sería el siguiente.

    NAME        AGE   SIGNERNAME                      REQUESTOR                                                  REQUESTEDDURATION   CONDITION
csr-7znmf   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-42-149.region.compute.internal      <none>              Approved
csr-9xx5q   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-65-38.region.compute.internal      <none>              Approved, Issued

    Si el resultado devuelto muestra una CSR con un firmante de kubernetes.io/kubelet-serving que está Approved, pero que no se ha Issued para un nodo, entonces deberá aprobar la solicitud.

  2. Apruebe la CSR de forma manual. Reemplace csr-7znmf por su propio valor.

    kubectl certificate approve csr-7znmf

Para aprobar automáticamente las solicitudes de firma de certificados en el futuro, recomendamos escribir un controlador de aprobación que pueda validar y aprobar automáticamente las CSR que contengan SAN IP o DNS que Amazon EKS no pueda verificar.