Helfen Sie mit, diese Seite 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.
Möchten Sie zu diesem Benutzerhandbuch beitragen? Wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet. Ihre Beiträge werden dazu beitragen, dass unser Benutzerhandbuch für alle besser wird.
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 Die Zertifikats-API automatisiert die Bereitstellung von X.509-Anmeldeinformationen.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 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
. Die v1beta1
-API der CSR-Ressource berücksichtigte diesen Unterzeichnertyp „legacy-unknown“. Die stabile v1
API von CSR erlaubt es jedoch nicht, auf eingestellt signerName
zu kubernetes.io/legacy-unknown
werden.
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. Jedoch in Kubernetes Version1.22
, die v1beta1
CSR-API wurde durch die v1
CSR-API ersetzt. Diese API unterstützt den signerNamen „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. Für diesen Unterzeichner gibt es keine Standardvertrauensstellung oder -verteilung 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
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.
-
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
-
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"
-
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 " ")
-
Führen Sie den folgenden Befehl aus, um eine Datei mit dem Namen
mycsr.yaml
zu erstellen. Im folgenden Beispiel istbeta.eks.amazonaws.com/app-serving
dersignerName
.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
-
Reichen Sie die CSR ein.
kubectl apply -f mycsr.yaml
-
Genehmigen Sie das Bereitstellungszertifikat.
kubectl certificate approve myserver
-
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
-
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.23
und früher wurden kubelet
Serverzertifikate mit nicht verifizierbaren IP- und DNS-Betreffnamen (SANs) automatisch mit nicht verifizierbaren Namen ausgestellt. SANs Sie SANs werden im bereitgestellten Zertifikat weggelassen. In Clustern 1.24
und neueren Versionen kubelet
werden keine Serverzertifikate 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 fest1.24
, ob Ihr Cluster über Zertifikatssignieranfragen (CSR) verfügt, die nicht genehmigt wurden, indem Sie die folgenden Schritte ausführen:
-
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-Signaturer anzeigt, der
Approved
aber nichtIssued
für einen Knotenbestimmt ist, müssen Sie die Anfrage genehmigen. -
Genehmigen Sie die CSR manuell. Ersetzen Sie
csr-
durch Ihren eigenen Wert.7znmf
kubectl certificate approve csr-7znmf
Für die automatische Genehmigung CSRs in future empfehlen wir Ihnen, einen Genehmigungscontroller zu schreiben, der automatisch alle IP-Adressen oder DNS validieren und genehmigen kann CSRs , SANs die Amazon EKS nicht verifizieren kann.