Sécurisez les charges de travail grâce aux certificats Kubernetes - Amazon EKS
Exemple de génération CSR avec SignerName

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.

Sécurisez les charges de travail grâce aux certificats Kubernetes

L'API Kubernetes Certificates automatise le provisionnement des informations d'identification X.509. L'API comporte 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é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.

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

  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 "
")

  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