Aidez à améliorer cette page
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
L'API des certificats Kubernetes automatise le provisionnement des informations d'identification X.509.CertificateSigningRequest (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 bien définis. De cette façon, les clients peuvent prévoir ce qu'il adviendra de leur CSRs. 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'v1API stable de CSR ne permet pas signerName de définir le surkubernetes.io/legacy-unknown.
La version 1.21 et les versions antérieures d'Amazon EKS acceptaient la valeur legacy-unknown en tant que signerName dans l'API CSR v1beta1. Cette API permet à l'autorité de certification (CA) Amazon EKS de générer des certificats. Cependant, dans la version Kubernetes1.22, l'API v1beta1 CSR a été remplacée par l'v1API CSR. Cette API ne prend pas en charge le nom de signature « legacy-unknown ». Si vous souhaitez utiliser Amazon EKS CA pour générer des certificats sur vos clusters, vous devez utiliser un signataire personnalisé. Il a été introduit dans la version 1.22 d'Amazon EKS. 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 aucune confiance ou distribution standard pour ce signataire dans un cluster Kubernetes.
-
Sujets autorisés : tous
-
Extensions x509 autorisées : honore subjectAltName et utilise les extensions clés et supprime 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
Considérations relatives à la signature des certificats avant la mise à niveau de votre cluster vers Kubernetes 1.24
Dans Kubernetes 1.23 et versions antérieures, les certificats de kubelet service dont l'adresse IP et les noms alternatifs de sujet DNS (SANs) ne sont pas vérifiables sont automatiquement émis avec la mention « invérifiable ». SANs Ils SANs sont omis du certificat provisionné. Dans 1.24 les clusters et versions ultérieures, les certificats de kubelet service ne sont pas émis si un SAN ne peut pas être vérifié. Cela entrave le fonctionnement des commandes kubectl exec et kubectl logs.
Avant de procéder à la mise à niveau de votre cluster vers1.24, déterminez si votre cluster contient des demandes de signature de certificat (CSR) qui n'ont pas été approuvées en effectuant les étapes suivantes :
-
Exécutez la commande suivante.
kubectl get csr -AL'exemple qui suit illustre un résultat.
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, IssuedSi la sortie renvoyée indique un CSR avec un signataire kubernetes.io/kubelet-serving
qui n'est pas Issueddestiné à un nœudApproved, vous devez approuver la demande. -
Approuvez manuellement le CSR. Remplacez
csr-par votre propre valeur.7znmfkubectl certificate approve csr-7znmf
Pour une approbation automatique CSRs à l'avenir, nous vous recommandons d'écrire un contrôleur d'approbation capable de valider et d'approuver automatiquement les adresses IP ou DNS CSRs qu' SANs Amazon EKS ne peut pas vérifier.
