Zertifikatsignierung - Amazon EKS
CSR-BeispielCSRs in Kubernetes 1.24

Helfen Sie 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.

Zertifikatsignierung

Die Kubernetes-Zertifikats-API automatisiert die Bereitstellung der X.509-Anmeldeinformationen. Das API-Feature verfügt über eine Befehlszeilenschnittstelle, über die Kubernetes-API-Clients X.509-Zertifikate von einer Zertifizierungsstelle (CA) anfordern und abrufen können. Sie können die CertificateSigningRequest (CSR)-Ressource verwenden, um anzufordern, 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 definierten Verhaltensweisen. Auf diese Weise können Kunden vorhersehen, was mit ihren CSRs passiert. Weitere Informationen zur Zertifikatsignatur finden Sie unter Signieren von Anforderungen.

Einer der integrierten Unterzeichner ist kubernetes.io/legacy-unknown. Die v1beta1-API der CSR-Ressource berücksichtigte diesen Unterzeichnertyp „legacy-unknown“. Die stabile v1-API von CSR lässt jedoch nicht zu, dass signerName auf kubernetes.io/legacy-unknown festgelegt wird.

Amazon-EKS-Version 1.21 und ältere Versionen ermöglichten es, den Wert legacy-unknown als den signerName in der v1beta1-CSR-API festzulegen. Diese API ermöglicht es der Amazon EKS Certificate Authority (CA), Zertifikate zu generieren. In Kubernetes Version 1.22 wurde die v1beta1-CSR-API durch die v1-CSR-API ersetzt. Diese API unterstützt den signerName von „legacy-unknown“ nicht. Wenn Sie Amazon EKS CA zum Generieren von Zertifikaten verwenden möchten, müssen Sie einen benutzerdefinierten Unterzeichner verwenden. Dies wurde in Version 1.22 von Amazon EKS eingeführt. 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 der vorhandenen v1beta1-API erstellt wurden, sind gültig und funktionieren, bis sie ablaufen. Diese umfasst die folgenden Funktionen:

  • Vertrauensverteilung: keine. Es gibt kein Standardvertrauen oder eine Standardverteilung für diesen Unterzeichner in einem Kubernetes-Cluster.

  • Zulässige Themen: beliebig

  • Zulässige x509-Erweiterungen: Besitzer- subjectAltName und Schlüsselnutzungserweiterungen 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

Beispiel CSR-Erstellung mit signerName

Diese Schritte veranschaulichen, wie Sie ein Bereitstellungszertifikat für DNS-Namen myserver.default.svc mit signerName: beta.eks.amazonaws.com/app-serving erstellen. Verwenden Sie dies als Leitfaden für Ihre eigene Umgebung.

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

    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-Variablen für die Verwendung in einem späteren Schritt.

    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 die CSR ein.

    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 Zertifikatssignierung vor dem Upgrade Ihres Clusters auf Kubernetes 1.24

In Kubernetes 1.23 und älter werden kubelet-Bereitstellungszertifikate mit nicht verifizierbaren IP- und DNS-Subject Alternative Names (SANs) automatisch mit nicht verifizierbaren SANs ausgestellt. Diese SANs werden im bereitgestellten Zertifikat weggelassen. In 1.24- und neuere Clustern werden keine kubelet-Bereitstellungszertifikate ausgestellt, wenn ein SAN nicht verifiziert werden kann. Dadurch wird verhindert, dass die kubectl exec- und kubectl logs-Befehle funktionieren.

Stellen Sie vor dem Upgrade Ihres Clusters auf 1.24 fest, ob Ihr Cluster Zertifikatsignierungsanforderungen (CSR) hat, 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 die zurückgegebene Ausgabe eine CSR mit einem kubernetes.io/kubelet-serving-Unterzeichner anzeigt, der Approved, aber nicht Issued für einen Knoten ist, müssen Sie die Anforderung genehmigen.

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

    kubectl certificate approve csr-7znmf

Um CSRs in Zukunft automatisch zu genehmigen, empfehlen wir, dass Sie einen genehmigenden Controller schreiben, der CSRs automatisch validieren und genehmigen kann, die IP- oder DNS-SANs enthalten, die Amazon EKS nicht verifizieren kann.