Aidez à améliorer cette page
Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.
Sécurisation des charges de travail grâce aux certificats Kubernetes
L’API Kubernetes Certificates automatise le provisionnement des informations d’identification X.509CertificateSigningRequest (CSR) pour demander à un signataire désigné de signer le certificat. Vos demandes sont approuvées ou refusées avant d’être signées. Kubernetes prend en charge à la fois les signataires intégrés et les signataires personnalisés, avec des comportements clairement définis. De cette façon, les clients peuvent prédire ce qu'il advient de leurs CSR. Pour en savoir plus sur la signature des certificats, consultez les demandes de signature
L'un des signataires intégrés est kubernetes.io/legacy-unknown. L'API v1beta1 de la ressource CSR a honoré ce signataire d'héritage inconnu. Cependant, l’API v1 stable de CSR ne permet pas de définir signerName sur kubernetes.io/legacy-unknown.
Si vous souhaitez utiliser Amazon EKS CA pour générer des certificats sur vos clusters, vous devez utiliser un signataire personnalisé. Pour utiliser la version de l'API CSR v1 et générer un nouveau certificat, vous devez migrer tous les manifestes et clients API existants. Les certificats existants créés avec l'API v1beta1 existante sont valides et fonctionnent jusqu'à l'expiration du certificat. Cela inclut les éléments suivants :
-
Distribution d'approbation : aucune. Il n’existe pas d’approbation ou de distribution standard pour ce signataire dans un cluster Kubernetes.
-
Sujets autorisés : tous
-
Extensions x509 autorisées : honore SubjectAltName et les extensions d'utilisation des clés et rejette les autres extensions
-
Utilisations de clés autorisées : ne doit pas inclure les utilisations au-delà de [« chiffrement de clé », « signature numérique », « authentification du serveur »]
Note
La signature de certificat client n'est pas prise en charge.
-
Expiration/durée de vie du certificat : 1 an (par défaut et maximum)
-
Bit CA autorisé/interdit : non autorisé
Exemple de génération CSR avec SignerName
Ces étapes montrent comment générer un certificat de service pour un nom DNS myserver.default.svc en utilisant signerName: beta.eks.amazonaws.com/app-serving. Utilisez-le comme guide pour votre propre environnement.
-
Exécutez la commande
openssl genrsa -out myserver.key 2048pour générer une clé privée RSA.openssl genrsa -out myserver.key 2048 -
Utilisez la commande suivante pour générer une demande de certificat.
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc" -
Générez une valeur
base64pour la demande CSR et stockez-la dans une variable, car vous en aurez besoin lors d'une étape ultérieure.base_64=$(cat myserver.csr | base64 -w 0 | tr -d " ") -
Pour créer un fichier nommé
mycsr.yaml, exécutez la commande suivante. Dans l'exemple suivant,beta.eks.amazonaws.com/app-servingest lesignerName.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 -
Envoyez la CSR.
kubectl apply -f mycsr.yaml -
Approuvez le certificat de service.
kubectl certificate approve myserver -
Vérifiez que le certificat a été émis.
kubectl get csr myserverL'exemple qui suit illustre un résultat.
NAME AGE SIGNERNAME REQUESTOR CONDITION myserver 3m20s beta.eks.amazonaws.com/app-serving kubernetes-admin Approved,Issued -
Exportez le certificat émis.
kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt