Proteggi i carichi di lavoro con i certificati Kubernetes - Amazon EKS
Generazione CSR di esempio con signerNameConsiderazioni sulla firma dei certificati prima di aggiornare il cluster a Kubernetes 1.24

Aiutaci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Proteggi i carichi di lavoro con i certificati Kubernetes

L'API Kubernetes Certificates automatizza il provisioning delle credenziali X.509. L'API presenta un'interfaccia a riga di comando che consente ai client API Kubernetes di richiedere e ottenere certificati X.509 da un'autorità di certificazione (CA). Puoi utilizzare la risorsa (CSR) CertificateSigningRequest per chiedere la firma del certificato da parte di un firmatario designato. Le tue richieste vengono approvate o rifiutate prima di essere firmate. Kubernetes supporta sia i firmatari integrati che i firmatari personalizzati con comportamenti ben definiti. In questo modo, i clienti possono prevedere cosa succede ai loro. CSRs Per ulteriori informazioni sulla firma dei certificati, consulta firma delle richieste.

Uno dei firmatari integrati è kubernetes.io/legacy-unknown. L'API v1beta1 della risorsa CSR ha onorato questo firmatario "legacy-unknown". Tuttavia, l'v1API stabile di CSR non consente di signerName impostarlo kubernetes.io/legacy-unknown su.

La versione di Amazon EKS 1.21 e le versioni precedenti consentivano il valore legacy-unknown come signerName nell'API CSR v1beta1. Questa API consente all'autorità di certificazione (CA) di Amazon EKS di generare i certificati. Tuttavia, nella versione Kubernetes1.22, l'API CSR è stata sostituita dall'API v1beta1 CSR. v1 Questa API non supporta il signerName di «legacy-unknown». Per utilizzare l'autorità di certificazione (CA) di Amazon EKS per la generazione di certificati sul tuo cluster, devi utilizzare un firmatario personalizzato. come introdotto nella versione 1.22 di Amazon EKS. Per utilizzare la versione v1 dell'API CSR e generare un nuovo certificato, devi eseguire la migrazione di tutti i manifesti e i client dell'API esistenti. I certificati esistenti creati con l'API v1beta1 esistente sono validi e funzionanti fino alla scadenza dei certificati. Questo include gli output seguenti:

  • Distribuzione di attendibilità: nessuna. Non esiste un trust o una distribuzione standard per questo firmatario in un cluster Kubernetes.

  • Argomenti consentiti: tutti

  • Estensioni x509 consentite: rispetta le estensioni di utilizzo delle chiavi subjectAltName e elimina le altre estensioni

  • Utilizzo delle chiavi consentite: non devono includere altri utilizzi oltre ["key encipherment", "digital signature", "server auth"]

    Nota

    La firma dei certificati client non è supportata.

  • Scadenza/durata del certificato: 1 anno (predefinita e massima)

  • Bit CA consentito/non consentito: non consentito

Generazione CSR di esempio con signerName

Questa procedura mostra come generare un certificato di servizio per il nome DNS myserver.default.svc utilizzando signerName: beta.eks.amazonaws.com/app-serving. Utilizzala come guida per il tuo ambiente.

  1. Esegui il comando openssl genrsa -out myserver.key 2048 per generare una chiave privata RSA.

    openssl genrsa -out myserver.key 2048

  2. Utilizza il comando seguente per generare una richiesta di certificato.

    openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"

  3. Genera un valore base64 per la richiesta CSR e memorizzalo in una variabile da utilizzare in un passaggio successivo.

    base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")

  4. Per creare un file denominato mycsr.yaml, esegui il comando di seguito. Nell'esempio seguente, beta.eks.amazonaws.com/app-serving è 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. Invia la CSR.

    kubectl apply -f mycsr.yaml

  6. Approva il certificato di servizio.

    kubectl certificate approve myserver

  7. Verifica l'emissione del certificato.

    kubectl get csr myserver

    Di seguito viene riportato un output di esempio:

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

  8. Esporta il certificato emesso.

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

Considerazioni sulla firma dei certificati prima di aggiornare il cluster a Kubernetes 1.24

In Kubernetes 1.23 e versioni precedenti, i certificati con IP e DNS Subject Alternative kubelet Names () non verificabili vengono emessi automaticamente con nomi alternativi non verificabili. SANs SANs Vengono omessi dal certificato fornito. SANs Nei cluster 1.24 e in quelli successivi, i certificati kubelet di servizio non vengono emessi se non è possibile verificare una SAN. Ciò impedisce il funzionamento dei comandi kubectl exec e kubectl logs.

Prima di aggiornare il cluster a1.24, stabilisci se il cluster dispone di richieste di firma dei certificati (CSR) che non sono state approvate completando i seguenti passaggi:

  1. Esegui il comando seguente.

    kubectl get csr -A

    Di seguito viene riportato un output di esempio:

    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

    Se l'output restituito mostra una CSR con un firmatario kubernetes.io/kubelet-serving che riguarda ma non un nodo, devi approvare la Approved richiesta. Issued

  2. Approva manualmente la CSR. Sostituire csr-7znmf con il proprio valore.

    kubectl certificate approve csr-7znmf

Per l'approvazione automatica CSRs in futuro, ti consigliamo di scrivere un controller di approvazione in grado di convalidare e approvare automaticamente che contenga IP o DNS CSRs che SANs Amazon EKS non può verificare.