Diese Seite wurde von der Cloud Translation API übersetzt.

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 sind. 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 der Entfernung auf Cluster

GKE pausiert automatische Upgrades, wenn erkannt wird, dass in einem Cluster Zertifikate verwendet werden, die mit Version 1.29 inkompatibel sind. Nachdem Sie die Zertifikate durch Zertifikate mit kompatiblen Signieralgorithmen ersetzt haben oder Version 1.28 das Ende des Supports erreicht hat, setzt GKE automatische Upgrades fort.

Wenn Sie die inkompatiblen Zertifikate nicht vor dem Upgrade auf Version 1.29 ersetzen, können die folgenden Probleme mit Ihren Clustern auftreten:

GKE-Webhook-Backends, 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 von APIs, die von den Erweiterungs-API-Servern bereitgestellt werden, schlagen fehl.

Warum wird diese Funktion in Kubernetes 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. GKE-Version 1.24 war die erste Version, die mit Go-Version 1.18 erstellt wurde. In GKE-Builds von Kubernetes war dieser Debugging-Switch bis Version 1.29 aktiviert. Der Switch wird in Go 1.24 entfernt. In GKE 1.29 wird Kubernetes mit deaktiviertem Switch erstellt, um sich auf die zukünftige Entfernung des Debugging-Switches in 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 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. Alternativ können Sie anhand von Logs Aufrufe an betroffene Back-Ends aus Ihrem Cluster identifizieren.

Statistiken und Empfehlungen abrufen

Bei Clustern mit Version 1.24 oder höher folgen Sie 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.

So erhalten Sie Logs

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 zum Interpretieren der Ergebnisse finden Sie im nächsten Abschnitt.

Anleitung aus Statistiken und Empfehlungen interpretieren

Eine Empfehlung enthält den Hostnamen des betroffenen Backends und gibt an, ob es sich um einen Webhook- oder Erweiterungs-API-Server handelt. Hostnamen, die auf Dienste im Cluster verweisen, 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-APIServer 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

Hier ist 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).

Wenn Sie Details zum Cluster und zum Dienst abrufen möchten, beschreiben Sie die Empfehlung. Die Ausgabe für einen Dienst mit dem Namen example-webhook im Namespace default sieht 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 entsprechenden Backend-Dienste bestimmt haben, können Sie das Zertifikat jedes einzelnen Dienstes prüfen, 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 es dem Wert des Felds 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 :In den folgenden Befehlen wird der Port 8888 verwendet. Sie können jedoch auch einen anderen Port auswählen, da dieser Port willkürlich ausgewählt wurde.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Ersetzen Sie SERVICE_TARGET_PORT durch den TargetPort-Wert aus dem Dienst. Wenn TargetPort nicht enthalten ist, verwenden Sie den Wert Port.
Verwenden Sie openssl, um das vom Dienst verwendete Zertifikat aufzurufen:
```
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, damit ein kompatibler Signaturalgorithmus verwendet wird. Wenn Sie beispielsweise die certificate.k8s.io API verwenden, um TLS-Zertifikate in Ihrem Cluster zu verwalten, können Sie der Anleitung zum Erstellen einer Anfrage zur Zertifikatsignierung folgen.

Portweiterleitung bereinigen

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

Führen Sie den folgenden Befehl aus, um die laufenden Prozesse aufzulisten:
```
jobs
```
Sehen Sie sich die Ausgabe an, um die ID des zu beendenden Prozesses zu ermitteln:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Diese Beispielausgabe gibt an, dass die Prozess-ID 1 ist.
Beenden Sie den Prozess und ersetzen Sie PROCESS_ID:
```
kill %PROCESS_ID
```
Die Ausgabe sieht so aus:
```
[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, geben Sie den folgenden openssl-Befehl aus, um das vom Backend verwendete Zertifikat auszugeben:

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, damit ein kompatibler Signaturalgorithmus verwendet wird. Wenn Sie beispielsweise die certificate.k8s.io API verwenden, um TLS-Zertifikate in Ihrem Cluster zu verwalten, können Sie der Anleitung zum Erstellen einer Anfrage zur Zertifikatsignierung folgen.

Risiko eines Upgrades auf Version 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 Supporterreicht. Sobald 1.28 das End of Support erreicht hat, werden die Cluster automatisch auf 1.29 aktualisiert.

Kompatible Signaturalgorithmen

GKE-Version 1.29 ist mit unterstützten Algorithmen im Go-Paket x509 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-Paket „x509“ unterstützt werden, sind im const-Block mit dieser Zeile aufgeführt. Suchen Sie in der Datei nach Verwendungen 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
Go x509 unterstützte Algorithmen