Signature des certificats - Amazon EKS
Exemple de CSRCSR en Kubernetes 1.24

Aidez à améliorer cette page

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

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.

Signature des certificats

L'API Kubernetes Certificates automatise la mise en service des informations d'identification X.509. Cet API dispose d'une interface de ligne de commande permettant aux clients de l'API Kubernetes de demander et d'obtenir des certificats X.509 auprès d'une autorité de certification (CA). Vous pouvez utiliser la ressource 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é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.

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. En revanche, dans la version 1.22 de Kubernetes, l'API CSR v1beta1 est remplacée par l'API CSR v1. Cette API ne prend pas en charge le signerName d'« héritage inconnu ». 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 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 utilise des clés pour les extensions 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.

  1. Exécutez la commande openssl genrsa -out myserver.key 2048 pour générer une clé privée RSA.

    openssl genrsa -out myserver.key 2048

  2. 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"

  3. Générez une valeur base64 pour 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 "\n")

  4. Pour créer un fichier nommé mycsr.yaml, exécutez la commande suivante. Dans l'exemple suivant, beta.eks.amazonaws.com/app-serving est le 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. Envoyez la CSR.

    kubectl apply -f mycsr.yaml

  6. Approuvez le certificat de service.

    kubectl certificate approve myserver

  7. Vérifiez que le certificat a été émis.

    kubectl get csr myserver

    L'exemple qui suit illustre un résultat.

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

  8. 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 service kubelet dotés d'une adresse IP et d'un SAN (Subject Alternative Name) invérifiables étaient automatiquement émis avec un SAN invérifiable. Les SAN sont omis du certificat fourni. Dans les versions 1.24 et ultérieures des clusters, les certificats de service kubelet ne sont pas émis si le SAN est invérifiable. Cela entrave le fonctionnement des commandes kubectl exec et kubectl logs.

Avant de procéder à la mise à niveau de votre cluster vers 1.24, déterminez si celui-ci possède des demandes de signature de certificat (CSR) qui n'ont pas été approuvées en effectuant les étapes suivantes :

  1. Exécutez la commande suivante.

    kubectl get csr -A

    L'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, Issued

    Si la sortie renvoyée présente un CSR dont le signataire kubernetes.io/kubelet-serving est Approved mais pas Issued pour un nœud, vous devez approuver la demande.

  2. Approuvez manuellement le CSR. Remplacez csr-7znmf par votre propre valeur.

    kubectl certificate approve csr-7znmf

À l'avenir, pour approuver automatiquement les CSR, nous vous recommandons de créer un contrôleur d'approbation capable de valider et d'approuver automatiquement les CSR contenant des adresses IP ou des SAN DNS qu'Amazon EKS n'a pas la capacité de vérifier.