Kompatibilität von TLS-Zertifikaten vor einem Upgrade auf GKE 1.29 gewährleisten

Autopilot Standard

GKE-Cluster mit Version 1.29 oder höher unterstützen keine TLS-Zertifikate (Transportation Layer Security), 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 Cluster dieser Entfernung

GKE pausiert automatische Upgrades, wenn erkannt wird, dass ein Cluster Zertifikate verwendet, die nicht mit Version 1.29 kompatibel sind. Nachdem Sie die Zertifikate mithilfe von kompatiblen Signaturalgorithmen durch Zertifikate ersetzt haben oder Version 1.28 das Ende des Supports erreicht hat, setzt GKE automatische Upgrades fort.

Wenn Sie die inkompatiblen Zertifikate vor dem Upgrade auf 1.29 nicht ersetzen, können die folgenden Probleme mit Ihren Clustern 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 fehl, wenn die Kubernetes-Steuerungsebene 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 Ihre Webhooks und 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. GKE-Version 1.24 war die erste Version, die mit Go-Version 1.18 erstellt wurde. GKE-Builds von Kubernetes hatten diesen Debug-Switch bis Version 1.29 aktiviert. Der Wechsel wird in Go 1.24 entfernt. GKE 1.29 erstellt Kubernetes mit deaktiviertem Switch, um sich auf die zukünftige Entfernung des Debug-Switch durch Go vorzubereiten. Nachdem GKE Ihre Cluster auf Version 1.29 aktualisiert hat, schlagen Aufrufe von der Steuerungsebene des Clusters an Webhooks oder Erweiterungs-API-Server im Cluster fehl, die ein mit dem SHA-1-Algorithmus signiertes TLS-Zertifikat bereitstellen.

Betroffene Cluster bestimmen

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. Alternativ können Sie Logs verwenden, um Aufrufe von betroffenen Back-Ends aus Ihrem Cluster zu identifizieren.

Statistiken 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, indem Sie nach 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"

Die Audit-Logs enthalten den Hostnamen des betroffenen Back-Ends. Weitere Informationen zur Interpretation der Ergebnisse finden Sie im nächsten Abschnitt.

Hinweise aus Statistiken und Empfehlungen interpretieren

Eine Empfehlung enthält den Hostnamen des betroffenen Back-Ends und ob es sich um einen Webhook oder einen Erweiterungs-API-Server handelt. Hostnamen, die sich auf Dienste im Cluster beziehen, haben das Format <service-name>.<namespace>.svc.

Wenn das betroffene Backend-Zertifikat von einem Webhook-Server stammt, kann der Hostname entweder ein Dienst 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

Sehen Sie sich die folgende Beispielliste mit Empfehlungen an:

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 abzurufen. Die Ausgabe für einen Dienst 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 Diensten unterstützt werden.

Nachdem Sie die relevanten Back-End-Dienste zur Prüfung ermittelt haben, prüfen Sie anhand der folgenden Anleitung das Zertifikat der einzelnen Dienste, 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, entspricht dies dem Wert im 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 einen anderen Port auswählen, da dieser Port willkürlich ausgewählt wird.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Ersetzen Sie SERVICE_TARGET_PORT durch den Wert TargetPort aus dem Dienst. Wenn TargetPort nicht angegeben 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, 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 mit der certificate.k8s.io API TLS-Zertifikate in Ihrem Cluster verwalten, folgen Sie der Anleitung zum Erstellen einer Anfrage zur Zertifikatsignierung.

Portweiterleitung bereinigen

Suchen Sie den Prozess und beenden Sie ihn, um die im Hintergrund ausgeführte Portweiterleitung zu bereinigen.

Führen Sie den folgenden Befehl aus, um die laufenden Prozesse aufzulisten:
```
jobs
```
In der Ausgabe finden Sie die ID des zu beendenden Prozesses:
```
[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 mit dem folgenden openssl-Befehl das vom Backend verwendete Zertifikat an:

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, 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 mit der certificate.k8s.io API TLS-Zertifikate in Ihrem Cluster verwalten, folgen Sie der Anleitung zum Erstellen einer Anfrage zur Zertifikatsignierung.

Risiko eines Upgrades auf 1.29 minimieren

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 Supporterreicht. Sobald 1.28 das End of Support 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. Algorithmen, die vom Go-x509-Paket unterstützt werden, werden im Block const mit dieser Zeile aufgeführt. Suchen Sie in der Datei nach der Verwendung von InsecureAlgorithmError, um nicht unterstützte unsichere Signaturalgorithmen zu finden.

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