Kompatibilität mit TLS-Zertifikaten vor dem Upgrade auf GKE 1.29 gewährleisten

Autopilot Standard

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 und SERVICE_NAME durch die Werte aus targetValue.

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 Selektor run=nginx und den Zielport 444 hat.

Hinweis: Wenn TargetPort nicht enthalten ist, hat es denselben Wert wie das Feld Port.

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.

Hinweis: Diese nächsten Befehle verwenden Port 8888. Sie können jedoch auch einen anderen Port auswählen, da dieser Port beliebig ausgewählt wird.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Ersetzen Sie SERVICE_TARGET_PORT durch den Wert TargetPort des Dienstes. Wenn TargetPort nicht enthalten ist, verwenden Sie den Wert Port.
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