**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écurisation des charges de travail grâce aux certificats Kubernetes
<a name="cert-signing"></a>

L'API Kubernetes Certificates [X.509](https://www.itu.int/rec/T-REC-X.509)automatise le provisionnement des informations d'identification. L'API comporte une interface de ligne de commande permettant aux clients de l'API Kubernetes de demander et d'obtenir des [X.509 certificats](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) 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 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](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/).

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 les extensions d'utilisation du sujet AltName et de la clé 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/certificate durée de vie : 45 jours (par défaut et maximum)
+ Bit CA allowed/disallowed : non autorisé

## Exemple de génération CSR avec SignerName
<a name="csr-example"></a>

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

1. 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"
   ```

1. 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 "
   ")
   ```

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

1. Envoyez la CSR.

   ```
   kubectl apply -f mycsr.yaml
   ```

1. Approuvez le certificat de service.

   ```
   kubectl certificate approve myserver
   ```

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

1. Exportez le certificat émis.

   ```
   kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt
   ```