Sichere Workloads mit Kubernetes Zertifikate - Amazon EKS
CSRBeispielCSRsin Kubernetes 1.24

Hilf mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Sichere Workloads mit Kubernetes Zertifikate

Das Tool Kubernetes Certificates automatisiert die Bereitstellung von X.509-Anmeldeinformationen. API Es API verfügt über eine Befehlszeilenschnittstelle für Kubernetes APIClients, um X.509-Zertifikate von einer Zertifizierungsstelle (CA) anzufordern und zu erhalten. Sie können die Ressource CertificateSigningRequest (CSR) verwenden, um zu verlangen, dass ein benannter Unterzeichner das Zertifikat signiert. Ihre Anfragen werden entweder genehmigt oder abgelehnt, bevor sie signiert werden. Kubernetes unterstützt sowohl integrierte Unterzeichner als auch benutzerdefinierte Unterzeichner mit klar definiertem Verhalten. Auf diese Weise können Kunden vorhersagen, was mit ihren passiert. CSRs Weitere Informationen zur Zertifikatsignatur finden Sie unter Signieren von Anforderungen.

Einer der integrierten Unterzeichner ist kubernetes.io/legacy-unknown. The v1beta1 API of CSR Resource hat diesen noch unbekannten Unterzeichner geehrt. Die stabile Version v1 API von erlaubt es jedoch CSR nicht, auf gesetzt signerName zu werden. kubernetes.io/legacy-unknown

In der EKS Amazon-Version 1.21 und früher war der legacy-unknown Wert als signerName in zulässig v1beta1 CSRAPI. APIDadurch kann die Amazon EKS Certificate Authority (CA) Zertifikate generieren. Jedoch in Kubernetes Version1.22, die v1beta1 CSR API wurde durch die ersetzt v1 CSRAPI. Das signerName von „Legacy-Unknown“ wird API nicht unterstützt. Wenn Sie Amazon EKS CA für die Generierung von Zertifikaten auf Ihren Clustern verwenden möchten, müssen Sie einen benutzerdefinierten Unterzeichner verwenden. Es wurde in der EKS Amazon-Version eingeführt1.22. Um die CSR v1 API Version zu verwenden und ein neues Zertifikat zu generieren, müssen Sie alle vorhandenen Manifeste und API Clients migrieren. Bestehende Zertifikate, die mit dem vorhandenen Zertifikat erstellt wurden, v1beta1 API sind gültig und funktionieren, bis das Zertifikat abläuft. Diese umfasst die folgenden Funktionen:

  • Vertrauensverteilung: keine. Für diesen Unterzeichner gibt es keine Standardvertrauensstellung oder -verteilung in einem Kubernetes Cluster.

  • Zulässige Themen: beliebig

  • Zulässige x509-Erweiterungen: Erlaubt subjectAltName Nutzungserweiterungen und verwirft andere Erweiterungen

  • Zulässige Schlüsselnutzung: Darf keine anderen Nutzungen als [„Schlüsselverschlüsselung“, „digitale Signatur“, „Serverauth“] enthalten

    Anmerkung

    Das Signieren von Clientzertifikaten wird nicht unterstützt.

  • Ablauf/Zertifikatslebensdauer: 1 Jahr (Standard und Maximum)

  • CA-Bit zulässig/unzulässig: unzulässig

Beispielgenerierung mit CSR signerName

Diese Schritte zeigen, wie Sie ein Serving-Zertifikat für die DNS myserver.default.svc Namensverwendung generierensignerName: beta.eks.amazonaws.com/app-serving. Verwenden Sie dies als Leitfaden für Ihre eigene Umgebung.

  1. Führen Sie den openssl genrsa -out myserver.key 2048 Befehl aus, um einen RSA privaten Schlüssel zu generieren.

    openssl genrsa -out myserver.key 2048

  2. Führen Sie den folgenden Befehl aus, um eine Zertifikatsanforderung zu erstellen.

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

  3. Generieren Sie einen base64 Wert für die CSR Anfrage und speichern Sie ihn in einer Variablen, um ihn in einem späteren Schritt zu verwenden.

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

  4. Führen Sie den folgenden Befehl aus, um eine Datei mit dem Namen mycsr.yaml zu erstellen. Im folgenden Beispiel ist beta.eks.amazonaws.com/app-serving der 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. Reichen Sie das einCSR.

    kubectl apply -f mycsr.yaml

  6. Genehmigen Sie das Bereitstellungszertifikat.

    kubectl certificate approve myserver

  7. Stellen Sie sicher, dass das Zertifikat ausgestellt wurde.

    kubectl get csr myserver

    Eine Beispielausgabe sieht wie folgt aus.

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

  8. Exportieren Sie das ausgestellte Zertifikat.

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

Überlegungen zur Zertifikatsignierung vor dem Upgrade Ihres Clusters auf Kubernetes 1.24

In Kubernetes 1.23und früher wurden kubelet Serverzertifikate mit nicht überprüfbarer IP-Adresse und alternativen DNS Betreffnamen (SANs) automatisch mit nicht verifizierbaren Namen ausgestellt. SANs Sie SANs werden im bereitgestellten Zertifikat weggelassen. In Clustern 1.24 und neueren Versionen werden kubelet keine Serverzertifikate ausgestellt, wenn ein Zertifikat nicht verifiziert werden SAN kann. Dadurch wird verhindert, dass die kubectl exec- und kubectl logs-Befehle funktionieren.

Stellen Sie vor dem Upgrade Ihres Clusters auf fest1.24, ob Ihr Cluster über Zertifikatssignieranfragen (CSR) verfügt, die nicht genehmigt wurden, indem Sie die folgenden Schritte ausführen:

  1. Führen Sie den folgenden Befehl aus.

    kubectl get csr -A

    Eine Beispielausgabe sieht wie folgt aus.

    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

    Wenn in der zurückgegebenen Ausgabe ein Zeichen CSR mit einem kubernetes.io/kubelet-servingUnterzeichner angezeigt wird, das Approved aber nicht Issued für einen Knoten bestimmt ist, müssen Sie die Anfrage genehmigen.

  2. Genehmigen Sie die CSR manuell. Ersetzen Sie csr-7znmf durch Ihren eigenen Wert.

    kubectl certificate approve csr-7znmf

Für die automatische Genehmigung CSRs in future empfehlen wir, dass Sie einen für die Genehmigung Verantwortlichen einrichten, der automatisch validieren und genehmigen kannCSRs, wenn diese IP-Adressen enthalten oder DNS SANs die Amazon nicht verifizieren EKS kann.