Proteggi i carichi di lavoro con Kubernetes certificates - Amazon EKS
CSRGenerazione di esempi 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à.

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

Proteggi i carichi di lavoro con Kubernetes certificates

Il Kubernetes I certificati automatizzano il provisioning delle credenziali X.509. API APIDispone di un'interfaccia a riga di comando per Kubernetes APIclient per richiedere e ottenere certificati X.509 da un'autorità di certificazione (CA). È possibile utilizzare la risorsa CertificateSigningRequest (CSR) per richiedere che un firmatario indicato firmi il certificato. 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. The v1beta1 API of CSR Resource ha onorato questo firmatario sconosciuto per tradizione. Tuttavia, lo stable v1 API of CSR non consente di impostarlo su. signerName kubernetes.io/legacy-unknown

EKSLa versione Amazon 1.21 e le versioni precedenti consentivano il legacy-unknown valore come signerName in v1beta1 CSRAPI. Ciò API consente ad Amazon EKS Certificate Authority (CA) di generare certificati. Tuttavia, in Kubernetes versione1.22, è v1beta1 CSR API stata sostituita dalla v1 CSRAPI. Questo API non supporta l' signerName espressione «legacy-unknown». Se desideri utilizzare Amazon EKS CA per generare certificati sui tuoi cluster, devi utilizzare un firmatario personalizzato. È stato introdotto nella EKS versione Amazon1.22. Per utilizzare la CSR v1 API versione e generare un nuovo certificato, è necessario migrare tutti i manifesti e API i client esistenti. I certificati esistenti creati con quello esistente v1beta1 API sono validi e funzionano fino alla scadenza del certificato. Questo include gli output seguenti:

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

  • 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

CSRGenerazione di esempi con signerName

Questi passaggi mostrano come generare un certificato di servizio per l'myserver.default.svcutilizzo DNS del nomesignerName: beta.eks.amazonaws.com/app-serving. Utilizzala come guida per il tuo ambiente.

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

    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 base64 valore per la CSR richiesta 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 ilCSR.

    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.23e versioni precedenti, i certificati kubelet di servizio con IP non verificabile e DNS Subject Alternative Names (SANs) vengono emessi automaticamente con non verificabile. SANs SANsVengono omessi dal certificato fornito. Nei cluster 1.24 e in quelli successivi, i certificati di kubelet servizio non vengono emessi se non è SAN possibile verificarne uno. Ciò impedisce il funzionamento dei comandi kubectl exec e kubectl logs.

Prima di aggiornare il cluster a1.24, stabilisci 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 un firmatario CSR con kubernetes.io/kubelet-serving che si riferisce a un nodo Approved ma non Issued a un nodo, devi approvare la richiesta.

  2. CSRApprova manualmente il. 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 CSRs che DNS SANs Amazon non possa verificare. EKS