Sécurisez les charges de travail avec Kubernetes certificates - Amazon EKS
CSRexempleCSRsdans 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 tous.

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.

Sécurisez les charges de travail avec Kubernetes certificates

Le Kubernetes Les API certificats automatisent le provisionnement des informations d'identification X.509. APIIl dispose d'une interface de ligne de commande pour Kubernetes APIclients pour demander et obtenir des certificats X.509 auprès d'une autorité de certification (CA). Vous pouvez utiliser la ressource CertificateSigningRequest (CSR) pour demander à un signataire indiqué 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 dotés de comportements bien définis. De cette façon, les clients peuvent prévoir ce qu'il adviendra de leurCSRs. 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. La CSR ressource v1beta1 API of a rendu hommage à cet ancien signataire inconnu. Cependant, le stable v1 API de CSR ne permet pas signerName de définir le surkubernetes.io/legacy-unknown.

Les EKS versions Amazon 1.21 et antérieures autorisaient la legacy-unknown valeur comme signerName entrée v1beta1 CSRAPI. Cela API permet à l'Amazon EKS Certificate Authority (CA) de générer des certificats. Cependant, dans Kubernetes version1.22, le v1beta1 CSR API a été remplacé par le v1 CSRAPI. Cela API ne supporte pas l'expression signerName « 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 EKS version Amazon1.22. Pour utiliser la CSR v1 API version et générer un nouveau certificat, vous devez migrer tous les manifestes et API clients existants. Les certificats existants créés à partir des certificats existants v1beta1 API sont valides et fonctionnent jusqu'à leur expiration. Cela inclut les éléments suivants :

  • Distribution d'approbation : aucune. Il n'y a pas de confiance ou de distribution standard pour ce signataire dans un Kubernetes grappe.

  • 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é

CSRGénération d'exemples avec signerName

Ces étapes montrent comment générer un certificat de service pour myserver.default.svc l'utilisation DNS du nomsignerName: beta.eks.amazonaws.com/app-serving. Utilisez-le comme guide pour votre propre environnement.

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

    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 base64 valeur pour la CSR demande et stockez-la dans une variable pour une utilisation 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. Soumettez leCSR.

    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

Entrée Kubernetes 1.23et dans les versions antérieures, les certificats de kubelet service dont l'adresse IP est invérifiable et les noms alternatifs de DNS sujet (SANs) 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 s'SANils ne peuvent pas être vérifiés. 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 :

  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 le résultat renvoyé indique CSR un kubernetes.io/kubelet-servingsignataire qui Approved n'est pas Issued destiné à un nœud, vous devez approuver la demande.

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

    kubectl 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 celles CSRs qu'DNSSANsAmazon ne EKS peut pas vérifier.