GKE-Cluster mit Version 1.29 oder höher unterstützen keine Transport Layer Layer-Zertifikate (TLS), die mit dem SHA-1-Algorithmus signiert wurden. Um Auswirkungen auf Ihre Cluster zu vermeiden, müssen Sie inkompatible Zertifikate von Webhook- und Extension API-Server-Back-Ends ersetzen. Zertifikate mit kompatiblen Signaturalgorithmen vor dem Upgrade Ihrer Cluster auf Version 1.29.
Auswirkungen auf die Entfernung dieser Cluster
GKE bricht automatische Upgrades ab, wenn erkannt wird, dass ein Cluster Zertifikate verwendet, die mit Version 1.29 nicht kompatibel sind. Nachdem Sie die Zertifikate mithilfe von kompatiblen Signaturalgorithmen durch Zertifikate ersetzt haben oder die Version 1.28 das Ende des Lebenszyklus erreicht hat, setzt GKE die automatischen Upgrades fort.
Wenn Sie vor dem Upgrade auf 1.29 die inkompatiblen Zertifikate nicht ersetzen, können bei Ihren Clustern die folgenden Probleme auftreten:
- GKE-Webhook-Back-Ends, die TLS-Zertifikate verwenden, die mit dem SHA-1-Algorithmus signiert sind, funktionieren aufgrund eines Authentifizierungsfehlers nicht mehr. Webhook-Aufrufe schlagen für die Kubernetes-Steuerungsebene fehl, die mit Ihren Webhooks mit inkompatiblen Zertifikaten kommuniziert. Je nach Konfiguration, insbesondere wenn Sie Zulassungs-Webhooks verwenden, kann die Kontaktaufnahme mit einem Webhook möglicherweise die Ressourcenerstellung in Ihrem Cluster blockieren, z. B. die Pod-Erstellung. Dies kann sehr störend sein.
- Aufrufe an APIs, die von den Erweiterungs-API-Servern bereitgestellt werden, schlagen fehl.
Warum Kubernetes diese Funktion entfernt
GKE basiert auf dem Open-Source-Kubernetes-System, das die kube-apiserver-Komponente verwendet, um Ihren Webhook und Erweiterungs-API-Server-Back-Ends über TLS zu kontaktieren. Die kube-apiserver-Komponente ist in der Programmiersprache Go geschrieben.
Ab Go-Version 1.18 hat Go mit dem SHA-1-Algorithmus signierte TLS-Zertifikate abgelehnt, jedoch einen Debug-Switch x509sha1=1
belassen, um das alte Verhalten zu aktivieren und den Migrationsprozess zu vereinfachen.
Die GKE-Version 1.24 war die erste Version, die mit der Go-Version 1.18 erstellt wurde. GKE-Builds von Kubernetes haben diesen Debug-Switch bis Version 1.29 aktiviert. Der Switch wird in Go 1.24 entfernt. GKE 1.29 erstellt Kubernetes mit deaktiviertem Switch, um das zukünftige Entfernen des Debug-Switch in Go vorzubereiten. Nachdem GKE Ihre Cluster auf Version 1.29 aktualisiert hat, schlagen Aufrufe von der Steuerungsebene Ihres Clusters an Webhooks oder Erweiterungs-API-Server im Cluster fehl, die ein mit dem SHA-1-Algorithmus signiertes TLS-Zertifikat bereitstellen.
Betroffene Cluster identifizieren
GKE überwacht Ihre Cluster und verwendet den Recommender-Dienst, um über Insights und Empfehlungen die Identifizierung von Clustern mit Webhooks oder Erweiterungs-API-Server-Back-Ends über TLS-Zertifikate zu ermöglichen, die mit dem SHA-1-Algorithmus signiert sind. Sie können auch Logs verwenden, um Aufrufe von betroffenen Back-Ends aus Ihrem Cluster zu identifizieren.
Informationen und Empfehlungen erhalten
Folgen Sie für Cluster mit Version 1.24 oder höher der Anleitung zum Aufrufen von Statistiken und Empfehlungen.
Sie können Statistiken mit der gcloud CLI oder der Recommender API abrufen und mit dem Untertyp DEPRECATION_K8S_SHA_1_CERTIFICATE
filtern.
Logs abrufen
Für Cluster mit Version 1.24 oder höher mit aktiviertem Cloud Logging bietet GKE ein Cloud-Audit-Loglog, um Aufrufe von betroffenen Back-Ends aus Ihrem Cluster zu identifizieren. Mit dem folgenden Filter können Sie nach den Logs suchen:
logName =~ "projects/.*/logs/cloudaudit.googleapis.com%2Factivity"
resource.type = "k8s_cluster"
operation.producer = "k8s.io"
"insecure-sha1.invalid-cert.kubernetes.io"
Audit-Logs enthalten den Hostnamen des betroffenen Back-Ends. Weitere Informationen zur Interpretation der Ergebnisse finden Sie im nächsten Abschnitt.
Anleitung aus Statistiken und Empfehlungen interpretieren
Eine Empfehlung enthält den Hostnamen des betroffenen Back-Ends und gibt an, ob es sich um einen Webhook oder einen Erweiterungs-API-Server handelt. Hostnamen, die auf Services im Cluster verweisen, haben das Format <service-name>.<namespace>.svc
.
Wenn das betroffene Back-End-Zertifikat von einem Webhook-Server stammt, kann der Hostname entweder ein Service im Cluster oder eine URL sein. Weitere Informationen finden Sie unter Webhook kontaktieren.
Wenn das betroffene Zertifikat von einem Erweiterungs-API-Server stammt, ist der Hostname ein Dienst im Cluster. Weitere Informationen finden Sie unter Erweiterungs-API-Server kontaktieren.
Folgen Sie nach der Identifizierung des betroffenen Back-Ends der Anleitung zur Prüfung des Zertifikats eines Dienstes oder zum Prüfen des Zertifikats eines URL-Back-Ends, je nach Typ.
Wenn Ihre Cluster in den letzten 30 Tagen keine Server mit betroffenen Zertifikaten aufgerufen haben, werden keine Empfehlungen angezeigt.
Beispielempfehlungen
Im Folgenden finden Sie eine Beispielliste mit Empfehlungen:
RECOMMENDATION_ID PRIMARY_IMPACT_CATEGORY RECOMMENDATION_STATE LAST_REFRESH_TIME PRIORITY RECOMMENDER_SUBTYPE DESCRIPTION
26bfcb32-6f2a-407c-874f-8cf55b3af912 RELIABILITY ACTIVE 2024-02-15T01:09:04.454456273Z P2 DEPRECATION_K8S_SHA_1_CERTIFICATE Update the webhook and/or extension API servers that use certificates signed with SHA-1 algorithm to use certificates with compatible signing algorithms prior to upgrading the cluster to version 1.29. [Learn more](https://cloud.google.com/kubernetes-engine/docs/deprecations/sha1-1-29#mitigate_the_risk_of_upgrading_to_129).
Beschreiben Sie die Empfehlung, um Details zum Cluster und Dienst zu erhalten.
Die Ausgabe für einen Service namens example-webhook
im Namespace default
sieht in etwa so aus:
associatedInsights:
- insight: projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/insightTypes/google.container.DiagnosisInsight/insights/d76887a8-9eed-41a0-9459-d49dee43455e
content:
overview:
featureDeprecationRecommendation:
- featureName: x.509_certificate_signature_algorithm
featureReplacementValue: algorithm [compatible with GKE v1.29](https://cloud.google.com/kubernetes-engine/docs/deprecations/sha1-1-29#compatible-signing-algorithms)
featureValue: SHA1
stopServingVersion: '1.29'
targetType: hostname
targetValue: example-webhook.default.svc
targetClusters:
- clusterId: 3be916a554724c79a2314c8baee3fd57cf1c39df1ad34c3daf291db701b6d541
clusterUri: //container.googleapis.com/projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/clusters/<CLUSTER_NAME>
description: Update the webhook and/or extension API servers that use certificates
signed with SHA-1 algorithm to use certificates with compatible signing algorithms
prior to upgrading the cluster to version 1.29. [Learn more](https://cloud.google.com/kubernetes-engine/docs/deprecations/sha1-1-29#mitigate_the_risk_of_upgrading_to_129).
etag: '"ad50aac8278951d5"'
lastRefreshTime: '2024-02-15T01:09:04.454456273Z'
name: projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/recommenders/google.container.DiagnosisRecommender/recommendations/26bfcb32-6f2a-407c-874f-8cf55b3af912
primaryImpact:
category: RELIABILITY
reliabilityProjection:
risks:
- SERVICE_DISRUPTION
priority: P2
recommenderSubtype: DEPRECATION_K8S_SHA_1_CERTIFICATE
stateInfo:
state: ACTIVE
targetResources:
- //container.googleapis.com/projects/<CLUSTER_PROJECT_NUMBER>/locations/<CLUSTER_LOCATION>/clusters/<CLUSTER_NAME>
Zertifikat eines Dienstes prüfen
Sowohl Webhooks als auch Erweiterungs-API-Server können von Services unterstützt werden.
Nachdem Sie die entsprechenden zu prüfenden Back-End-Dienste ermittelt haben, können Sie anhand der folgenden Anleitung prüfen, welches Zertifikat ein Dienst verwendet, um festzustellen, welche Zertifikate den SHA-1-Algorithmus verwenden und aktualisiert werden müssen.
Suchen Sie den Selektor und den Zielport des Dienstes:
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
Ersetzen Sie
NAMESPACE
undSERVICE_NAME
durch die Werte austargetValue
.Die Ausgabe sieht in etwa so aus:
Name: example-service Namespace: default Labels: run=nginx Selector: run=nginx Type: ClusterIP IP: 172.21.xxx.xxx Port: 443 TargetPort: 444
Diese Ausgabe gibt an, dass
example-service
den Selektorrun=nginx
und den Zielport444
hat.Suchen Sie einen Pod, der dem Selektor entspricht:
kubectl get pods --namespace=NAMESPACE --selector=run=nginx
Die Ausgabe sieht in etwa so aus:
NAME READY STATUS RESTARTS AGE example-pod 1/1 Running 0 21m
Diese Ausgabe gibt an, dass der übereinstimmende Pod
example-pod
ist.Richten Sie eine Portweiterleitung vom Localhost
kubectl
zum Pod ein.kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
Ersetzen Sie
SERVICE_TARGET_PORT
durch den WertTargetPort
des Dienstes. WennTargetPort
nicht enthalten ist, verwenden Sie den WertPort
.Verwenden Sie
openssl
, um das vom Dienst verwendete Zertifikat anzuzeigen:openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
Diese Beispielausgabe zeigt ein gültiges Zertifikat, das mit dem SHA-256-Algorithmus signiert wurde:
Certificate: Data: ... Signature Algorithm: sha256WithRSAEncryption ... Signature Algorithm: sha256WithRSAEncryption
Diese Beispielausgabe zeigt ein ungültiges Zertifikat an, das mit dem SHA-1-Algorithmus signiert wurde:
Certificate: Data: ... Signature Algorithm: sha1WithRSAEncryption ... Signature Algorithm: sha1WithRSAEncryption
Wenn die Ausgabe des Zertifikats ähnlich ist, müssen Sie das Zertifikat aktualisieren, um einen kompatiblen Signaturalgorithmus zu verwenden. Wenn Sie beispielsweise die
certificate.k8s.io
API zum Verwalten von TLS-Zertifikaten in Ihrem Cluster verwenden, können Sie der Anleitung zum Erstellen einer Zertifikatsignierungsanfrage folgen.
Portweiterleitung bereinigen
Wenn Sie die im Hintergrund ausgeführte Portweiterleitung bereinigen möchten, suchen Sie den Prozess und beenden Sie ihn.
Führen Sie den folgenden Befehl aus, um die laufenden Prozesse aufzulisten:
jobs
In der Ausgabe finden Sie die ID des Prozesses, mit dem sie beendet werden soll:
[1]+ Running kubectl port-forward pods/example-pod 8888:444 &
Diese Beispielausgabe zeigt an, dass die Prozess-ID
1
lautet.Beenden Sie den Vorgang und ersetzen Sie
PROCESS_ID
:kill %PROCESS_ID
Sehen Sie sich die folgende Ausgabe an:
[1]+ Terminated kubectl port-forward pods/example 8888:444
Diese Beispielausgabe zeigt, dass der Prozess beendet wurde.
Zertifikat eines URL-Back-Ends prüfen
Wenn der Webhook ein url
-Backend verwendet, stellen Sie eine direkte Verbindung zum in der URL angegebenen Hostnamen her. Wenn die URL beispielsweise https://example.com:123/foo/bar
lautet, zeigen Sie den folgenden openssl
-Befehl an, um das vom Back-End verwendete Zertifikat anzuzeigen:
openssl s_client -connect example.com:123 </dev/null | openssl x509 -noout -text
Diese Beispielausgabe zeigt ein gültiges Zertifikat, das mit dem SHA-256-Algorithmus signiert wurde:
Certificate:
Data:
...
Signature Algorithm: sha256WithRSAEncryption
...
Signature Algorithm: sha256WithRSAEncryption
Diese Beispielausgabe zeigt ein ungültiges Zertifikat an, das mit dem SHA-1-Algorithmus signiert wurde:
Certificate:
Data:
...
Signature Algorithm: sha1WithRSAEncryption
...
Signature Algorithm: sha1WithRSAEncryption
Wenn die Ausgabe des Zertifikats ähnlich ist, müssen Sie das Zertifikat aktualisieren, um einen kompatiblen Signaturalgorithmus zu verwenden. Wenn Sie beispielsweise die certificate.k8s.io
API zum Verwalten von TLS-Zertifikaten in Ihrem Cluster verwenden, können Sie der Anleitung zum Erstellen einer Zertifikatsignierungsanfrage folgen.
Risiko der Aktualisierung auf 1.29 verringern
Nachdem Sie die betroffenen Cluster und deren Back-End-Dienste mithilfe von Zertifikaten ermittelt haben, die mit dem SHA-1-Algorithmus signiert wurden, müssen Sie die Dienste vor dem Upgrade der Cluster auf Version 1.29 zur Verwendung von Zertifikaten mit kompatiblen Signaturalgorithmen aktualisieren.
Betroffene Cluster werden von GKE automatisch erkannt und es werden keine automatischen Upgrades auf Version 1.29 durchgeführt, bis entweder inkompatible Zertifikate nicht mehr verwendet werden oder Version 1.28 das End of Lifeerreicht. Sobald 1.28 das End of Life erreicht hat, werden die Cluster automatisch auf 1.29 aktualisiert.
Kompatible Signaturalgorithmen
Die GKE-Version 1.29 ist mit unterstützten Algorithmen im Go x509-Paket kompatibel. Dazu gehören die folgenden Algorithmen:
SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519
Informationen zu den verfügbaren Algorithmen finden Sie in der x509.go-Quelldatei. Suchen Sie nach UnknownSignatureAlgorithm SignatureAlgorithm = iota
. Die vom Go x509-Paket unterstützten Algorithmen werden im Block const
mit dieser Zeile aufgeführt. Wenn Sie nicht unterstützte unsichere Signaturalgorithmen finden möchten, suchen Sie in der Datei nach Verwendungen von InsecureAlgorithmError
.
Ressourcen
Weitere Informationen zu dieser Änderung finden Sie in den folgenden Ressourcen:
- Versionshinweise für Go 1.18
- Go 1.24 x509sha1 – Debug-Switch entfernen
- Von Go x509 unterstützte Algorithmen