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.509CertificateSigningRequest
(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.
-
Ejecute el comando
openssl genrsa -out myserver.key 2048
para generar una clave privada RSA.openssl genrsa -out myserver.key 2048
-
Utilice el siguiente comando para generar una solicitud de certificado.
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
-
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 " ")
-
Ejecute el siguiente comando para crear un archivo llamado
mycsr.yaml
. En el siguiente ejemplo,beta.eks.amazonaws.com/app-serving
es elsignerName
.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
-
Envíe la CSR.
kubectl apply -f mycsr.yaml
-
Apruebe el certificado de entrega.
kubectl certificate approve myserver
-
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
-
Exporte el certificado emitido.
kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt