I cluster GKE che eseguono la versione 1.29 o successive non supportano Certificati TLS (Transportation Layer Security) firmati con l'algoritmo SHA-1 algoritmo. Per evitare conseguenze sul tuo devi sostituire i certificati incompatibili webhook e l'API delle estensioni server backend con certificati che utilizzano la firma compatibile algoritmi prima di eseguire l'upgrade dei cluster Versione 1.29.
Impatto sui cluster di questa rimozione
GKE mette in pausa upgrade quando rileva che un cluster utilizza certificati incompatibili con Versione 1.29. Dopo aver sostituito i certificati con certificati utilizzando algoritmi di firma compatibili o versione 1.28 raggiunge la fine del supporto, GKE riprende gli upgrade automatici.
Se non sostituisci i certificati incompatibili prima di eseguire l'upgrade alla versione 1.29, potresti riscontrare i seguenti problemi con i tuoi cluster:
- Backend webhook GKE che utilizzano certificati TLS firmati con l'algoritmo SHA-1 smetterà di funzionare a causa di un errore di autenticazione. Webhook non riusciranno perché il piano di controllo Kubernetes comunica con webhook con certificati non compatibili. In base alla configurazione, soprattutto se utilizzi i webhook di ammissione, il mancato contatto con un webhook bloccare la creazione di risorse sul tuo cluster, ad esempio la creazione di pod, che può essere molto invasivi.
- Le chiamate alle API gestite dai server API delle estensioni non andranno a buon fine.
Perché Kubernetes sta rimuovendo questa funzionalità
GKE gestisce Kubernetes open source, che utilizza Componente kube-apiserver per contattare i backend webhook e dei server API delle estensioni utilizzando TLS. La Il componente kube-apiserver è scritto nel linguaggio di programmazione Go.
A partire da Go versione 1.18, Go ha iniziato a rifiutare i certificati TLS firmati con
Algoritmo SHA-1, ma ha lasciato un'opzione di debug
x509sha1=1
per attivare il comportamento precedente in modo da semplificare il processo di migrazione.
La versione 1.24 di GKE è stata la prima creata utilizzando la versione di Go
1,18. Le build GKE di Kubernetes hanno abilitato questa opzione di debug
fino alla versione 1.29. L'opzione verrà rimossa in Go
1,24. Build GKE 1.29
Kubernetes con l'opzione disabilitata per prepararsi alla futura rimozione del componente Go
di debug. Dopo che GKE ha eseguito l'upgrade dei cluster alla versione 1.29,
dal piano di controllo del cluster ai webhook o ai server API delle estensioni in
il cluster che fornisce un certificato TLS firmato con l'algoritmo SHA-1
non riuscito.
Identifica i cluster interessati
GKE monitora i cluster e utilizza il motore per suggerimenti per fornire indicazioni tramite approfondimenti e Suggerimenti che identificano i cluster con server API delle estensioni o webhook backend che utilizzano certificati TLS firmati con l'algoritmo SHA-1. In alternativa, puoi utilizzare per identificare le chiamate ai backend interessati dal tuo cluster.
Come ottenere approfondimenti e consigli
Per i cluster che eseguono la versione 1.24 o successive, segui le istruzioni per visualizzare
insight e
personalizzati.
Puoi ottenere insight utilizzando gcloud CLI, o
API Recommender, filtrando in base al sottotipo
DEPRECATION_K8S_SHA_1_CERTIFICATE
.
Come ottenere i log
Per i cluster che eseguono 1.24 o versioni successive con Cloud Logging attivato, GKE offre una Log di Cloud Audit Logs per identificare le chiamate ai backend interessati dal tuo cluster. Puoi utilizzare lo seguente filtro per cercare i log:
logName =~ "projects/.*/logs/cloudaudit.googleapis.com%2Factivity"
resource.type = "k8s_cluster"
operation.producer = "k8s.io"
"insecure-sha1.invalid-cert.kubernetes.io"
Gli audit log includono il nome host del backend interessato. Per scoprire di più su su come interpretare i risultati, consulta la sezione successiva.
Interpretare le indicazioni basate su approfondimenti e consigli
Un suggerimento include il nome host del backend interessato e se
è un server API delle estensioni o webhook. Nomi host che fanno riferimento ai Servizi in
nel cluster hanno il formato <service-name>.<namespace>.svc
.
Se il certificato di backend interessato proviene da un server webhook, il nome host può essere un servizio nel cluster o un URL. Per ulteriori informazioni, consulta la sezione Come contattare il webhook.
Se il certificato interessato proviene da un server API di estensione, il nome host è un servizio nel cluster. Per saperne di più, consulta Come contattare l'estensione apiserver.
Una volta identificato il backend interessato, segui le istruzioni per esaminare il certificato di un servizio o controllare il di un backend di URL, a seconda del tipo.
Se i tuoi cluster non hanno chiamato server con certificati interessati negli ultimi Dopo 30 giorni, non visualizzerai alcun consiglio.
Consigli di esempio
Consulta il seguente elenco di esempi di consigli:
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).
Per ottenere i dettagli del cluster e del servizio, descrivi il
consigliato.
L'output per un servizio denominato example-webhook
nello spazio dei nomi default
è
simile al seguente:
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>
Esamina il certificato di un servizio
Sia i webhook che i server API delle estensioni possono essere supportati dai servizi.
Dopo aver identificato i servizi di backend pertinenti da esaminare, utilizza il seguire le istruzioni per esaminare il certificato di ciascun Servizio al fine di verificare utilizzano l'algoritmo SHA-1 e devono essere aggiornati.
Trova il selettore e la porta di destinazione del servizio:
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
Sostituisci
NAMESPACE
eSERVICE_NAME
con i valori ditargetValue
.L'output è simile al seguente:
Name: example-service Namespace: default Labels: run=nginx Selector: run=nginx Type: ClusterIP IP: 172.21.xxx.xxx Port: 443 TargetPort: 444
Questo output indica che
example-service
ha il selettorerun=nginx
e porta di destinazione444
.Trova un pod corrispondente al selettore:
kubectl get pods --namespace=NAMESPACE --selector=run=nginx
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE example-pod 1/1 Running 0 21m
Questo output indica che il pod corrispondente è
example-pod
.Configura un port forwarding dal tuo localhost
kubectl
al pod:kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
Sostituisci
SERVICE_TARGET_PORT
con il valoreTargetPort
dal Servizio. SeTargetPort
non è incluso, utilizza il valorePort
.Usa
openssl
per mostrare il certificato utilizzato dal servizio:openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
Questo output di esempio mostra un certificato valido firmato con Algoritmo SHA-256:
Certificate: Data: ... Signature Algorithm: sha256WithRSAEncryption ... Signature Algorithm: sha256WithRSAEncryption
Questo output di esempio mostra un certificato non valido firmato con l'algoritmo SHA-1 algoritmo:
Certificate: Data: ... Signature Algorithm: sha1WithRSAEncryption ... Signature Algorithm: sha1WithRSAEncryption
Se l'output del certificato è simile, devi aggiornarlo per utilizzare un algoritmo di firma compatibile. Per Ad esempio, se utilizzi l'API
certificate.k8s.io
per gestire i certificati TLS per il cluster, puoi seguire le istruzioni per creare una firma richiesta.
Pulisci la porta in avanti
Per pulire il port forwarding in esecuzione in background, trova il processo e e terminarla.
Esegui questo comando per elencare i processi in esecuzione:
jobs
Visualizza l'output per ottenere l'ID del processo da terminare:
[1]+ Running kubectl port-forward pods/example-pod 8888:444 &
Questo output di esempio indica che l'ID di processo è
1
.Termina la procedura, sostituendo
PROCESS_ID
:kill %PROCESS_ID
Visualizza l'output seguente:
[1]+ Terminated kubectl port-forward pods/example 8888:444
Questo output di esempio mostra che il processo è stato interrotto.
Esamina il certificato di un backend di URL
Se il webhook utilizza un backend url
, connettiti direttamente al nome host specificato
nell'URL. Ad esempio, se l'URL è https://example.com:123/foo/bar
, utilizza
il seguente comando openssl
per mostrare il certificato utilizzato dal backend:
openssl s_client -connect example.com:123 </dev/null | openssl x509 -noout -text
Questo output di esempio mostra un certificato valido firmato con Algoritmo SHA-256:
Certificate:
Data:
...
Signature Algorithm: sha256WithRSAEncryption
...
Signature Algorithm: sha256WithRSAEncryption
Questo output di esempio mostra un certificato non valido firmato con l'algoritmo SHA-1 algoritmo:
Certificate:
Data:
...
Signature Algorithm: sha1WithRSAEncryption
...
Signature Algorithm: sha1WithRSAEncryption
Se l'output del certificato è simile, devi aggiornarlo
per utilizzare un algoritmo di firma compatibile. Per
Ad esempio, se utilizzi l'API certificate.k8s.io
per gestire i certificati TLS
per il cluster, puoi seguire le istruzioni per creare una firma
richiesta.
Riduci il rischio dell'upgrade alla versione 1.29
Dopo aver identificato i cluster interessati e i relativi servizi di backend utilizzando firmati con un algoritmo SHA-1, devi aggiornare i servizi certificati con firma compatibile algoritmi prima di eseguire l'upgrade dei cluster Versione 1.29.
I cluster interessati vengono rilevati automaticamente da GKE e non vengono con upgrade automatico versione 1.29, fino a quando i certificati incompatibili non saranno più utilizzati la versione 1.28 raggiunge la fine del supporto. Quando la versione 1.28 raggiunge la fine del supporto, verrà eseguito l'upgrade automatico dei cluster alla versione 1.29.
Algoritmi di firma compatibili
GKE versione 1.29 è compatibile con gli algoritmi supportati in Pacchetto Go x509. Sono inclusi i seguenti algoritmi:
SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519
Per trovare gli algoritmi disponibili, consulta la fonte di x509.go
file e cerca
UnknownSignatureAlgorithm SignatureAlgorithm = iota
. Gli algoritmi Go
I supporti dei pacchetti x509 sono elencati nel blocco const
con questa riga. Per trovare
algoritmi di firma non sicuri, cerca usi di
InsecureAlgorithmError
nel file.
Risorse
Per ulteriori informazioni su questa modifica, consulta le seguenti risorse:
- Note di rilascio per Go 1.18
- Vai alla versione 1.24 x509sha1 debug switch rimozione
- Algoritmi supportati per Go x509