Firma dei certificati - Amazon EKS
CSR di esempioCSR in Kubernetes 1.24

Aiutaci a migliorare questa pagina

Vuoi contribuire a questa guida per l'utente? Scorri fino alla fine di questa pagina e seleziona Modifica questa pagina su GitHub. I tuoi contributi contribuiranno a rendere la nostra guida utente migliore per tutti.

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

Firma dei certificati

L'API Kubernetes Certificates automatizza il provisioning delle credenziali X.509. L'API include un'interfaccia a riga di comando per i client dell'API di Kubernetes per la richiesta e l'acquisizione dei 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 che vengano firmate. Kubernetes supporta sia firmatari incorporati che firmatari personalizzati con funzionamenti ben definiti. In questo modo, i client possono prevedere cosa succede alle loro CSR. 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'API v1 stabile di CSR non consente l'impostazione di signerName su kubernetes.io/legacy-unknown.

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 1.22 di Kubernetes, l'API CSR v1beta1 è stata sostituita dall'API CSR v1. che 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 alcuna distribuzione o attendibilità standard per questo firmatario in un cluster Kubernetes.

  • Argomenti consentiti: tutti

  • Estensioni x509 consentite: rispetta le estensioni di utilizzo delle chiavi subjectAltName e scarta 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 "\n")

  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 alla versione 1.24 di Kubernetes

In Kubernetes 1.23 e versioni precedenti, i certificati di servizio kubelet con IP non verificabili e nomi alternativi dell'oggetto (SAN) DNS venivano emessi automaticamente con SAN non verificabili. I SAN vengono omessi dal certificato fornito. Nei cluster 1.24 e versioni successive, i certificati di servizio kubelet non vengono emessi se non è possibile verificare un SAN. Ciò impedisce il funzionamento dei comandi kubectl exec e kubectl logs.

Prima di aggiornare il cluster a 1.24, verifica se nel cluster sono presenti 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 è Approved ma non Issued per un nodo, devi approvare la richiesta.

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

    kubectl certificate approve csr-7znmf

Per approvare automaticamente le CSR in futuro, ti consigliamo di scrivere un controller di approvazione che possa convalidare e approvare automaticamente le CSR contenenti SAN IP o DNS che Amazon EKS non può verificare.