Protección de las cargas de trabajo con certificados de Kubernetes - Amazon EKS

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Protección de las 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 se rechazan antes de que se firmen. Kubernetes admite firmantes integrados y 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 v1 de CSR no permite que el signerName se establezca en kubernetes.io/legacy-unknown.

Si desea utilizar la CA de Amazon EKS para generar certificados en sus clústers, debe usar un firmante personalizado. 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 " ")
  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