I cluster GKE che eseguono la versione 1.29 o successive non supportano i certificati TLS (Transport Layer Security) firmati con l'algoritmo SHA-1. Per evitare ripercussioni sui tuoi cluster, devi sostituire i certificati incompatibili dei backend webhook e del server API di estensioni con certificati che utilizzano algoritmi di firma compatibili prima di eseguire l'upgrade dei cluster alla versione 1.29.
Impatto di questa rimozione sui cluster
GKE mette in pausa gli upgrade automatici quando rileva che un cluster utilizza certificati incompatibili con la versione 1.29. Dopo aver sostituito i certificati con certificati che utilizzano algoritmi di firma compatibili o quando la versione 1.28 raggiunge il termine 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:
- I backend webhook GKE che utilizzano certificati TLS firmati con l'algoritmo SHA-1 non funzioneranno più a causa di un errore di autenticazione. Le chiamate ai webhook non andranno a buon fine per il piano di controllo Kubernetes che comunica con i tuoi webhook con certificati incompatibili. A seconda della configurazione, soprattutto se utilizzi webhook di ammissione, la mancata convocazione di un webhook potrebbe bloccare la creazione di risorse nel cluster, ad esempio la creazione di pod, il che può essere molto dannoso.
- Le chiamate alle API servite dai server API di estensione non andranno a buon fine.
Perché Kubernetes sta rimuovendo questa funzionalità
GKE gestisce Kubernetes open source, che utilizza il componente kube-apiserver per contattare i backend del server API di webhook ed estensioni utilizzando TLS. Il componente kube-apiserver è scritto nel linguaggio di programmazione Go.
Dalla versione 1.18 di Go, Go ha iniziato a rifiutare i certificati TLS firmati con l'algoritmo SHA-1, ma ha lasciato un'opzione di debugx509sha1=1
per attivare il vecchio comportamento e semplificare la procedura di migrazione.
La versione 1.24 di GKE è stata la prima versione creata utilizzando la versione 1.18 di Go. Le build di Kubernetes di GKE avevano attivato questo interruttore di debug
fino alla versione 1.29. L'opzione verrà rimessa in Go 1.24. Le build GKE 1.29 compilano Kubernetes con l'opzione disattivata per prepararsi alla futura rimozione dell'opzione di debug da Go. Dopo che GKE esegue l'upgrade dei cluster alla versione 1.29,
le chiamate dal piano di controllo del cluster a webhook o server API di estensioni nel
cluster che forniscono un certificato TLS firmato con l'algoritmo SHA-1 non andranno a buon fine.
Identificare i cluster interessati
GKE monitora i tuoi cluster e utilizza il servizio Recommender per fornire indicazioni tramite approfondimenti e consigli che identificano i cluster con backend di server API delle estensioni o webhook che utilizzano certificati TLS firmati con l'algoritmo SHA-1. In alternativa, puoi utilizzare i log per identificare le chiamate ai backend interessati dal tuo cluster.
Come ricevere approfondimenti e consigli
Per i cluster che eseguono la versione 1.24 o successive, segui le istruzioni per visualizzare informazioni e consigli.
Puoi ottenere approfondimenti utilizzando l'interfaccia a riga di comando gcloud o l'API Recommender, filtrando con il sottotipoDEPRECATION_K8S_SHA_1_CERTIFICATE
.
Come ottenere i log
Per i cluster che eseguono la versione 1.24 o successive con Logging Cloud abilitato, GKE fornisce un log Audit log di Cloud per identificare le chiamate ai backend interessati dal tuo cluster. Puoi utilizzare il 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"
I log di controllo includono il nome host del backend interessato. Per scoprire di più su come interpretare i risultati, consulta la sezione successiva.
Interpreta le indicazioni fornite da approfondimenti e consigli
Un consiglio include il nome host del backend interessato e se si tratta di un webhook o di un server API di estensione. I nomi host che fanno riferimento ai servizi nel
cluster seguono il formato <service-name>.<namespace>.svc
.
Se il certificato del backend interessato proviene da un server webhook, il nome host può essere un servizio nel cluster o un URL. Per scoprire di più, consulta Contattare il webhook.
Se il certificato interessato proviene da un server API di estensioni, il nome host è un servizio nel cluster. Per saperne di più, consulta la sezione Contattare l'apiserver dell'estensione.
Dopo aver identificato il backend interessato, segui le istruzioni per controllare il certificato di un servizio o controllare il certificato di un backend URL, a seconda del tipo.
Se i tuoi cluster non hanno chiamato i server con i certificati interessati negli ultimi 30 giorni, non visualizzerai alcun consiglio.
Consigli di esempio
Di seguito è riportato un esempio di elenco 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 visualizzare i dettagli del cluster e del servizio, descrivi il
consiglio.
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>
Controllare il certificato di un servizio
Sia i webhook che i server API di estensione possono essere supportati da Services.
Dopo aver identificato i servizi di backend pertinenti da ispezionare, segui le istruzioni riportate di seguito per ispezionare il certificato di ciascun servizio e verificare quali certificati 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 la 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
kubectl
localhost al pod:kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
Sostituisci
SERVICE_TARGET_PORT
con il valoreTargetPort
del Servizio. SeTargetPort
non è incluso, utilizza il valorePort
.Utilizza
openssl
per mostrare il certificato utilizzato dal Servizio:openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
Questo esempio di output mostra un certificato valido firmato con l'algoritmo SHA-256:
Certificate: Data: ... Signature Algorithm: sha256WithRSAEncryption ... Signature Algorithm: sha256WithRSAEncryption
Questo esempio di output mostra un certificato non valido firmato con l'algoritmo SHA-1:
Certificate: Data: ... Signature Algorithm: sha1WithRSAEncryption ... Signature Algorithm: sha1WithRSAEncryption
Se l'output del certificato è simile, devi aggiornarlo per utilizzare un algoritmo di firma compatibile. Ad esempio, se utilizzi l'API
certificate.k8s.io
per gestire i certificati TLS nel tuo cluster, puoi seguire le istruzioni per creare una richiesta di firma del certificato.
Ripulire il port forwarding
Per ripulire il reindirizzamento di porta in esecuzione in background, individua il processo e terminalo.
Esegui il comando seguente per elencare i processi in esecuzione:
jobs
Consulta l'output per ottenere l'ID del processo da terminare:
[1]+ Running kubectl port-forward pods/example-pod 8888:444 &
Questo esempio di output indica che l'ID processo è
1
.Termina la procedura sostituendo
PROCESS_ID
:kill %PROCESS_ID
Visualizza il seguente output:
[1]+ Terminated kubectl port-forward pods/example 8888:444
Questo esempio di output mostra che il processo è stato interrotto.
Controllare il certificato di un backend 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 esempio di output mostra un certificato valido firmato con l'algoritmo SHA-256:
Certificate:
Data:
...
Signature Algorithm: sha256WithRSAEncryption
...
Signature Algorithm: sha256WithRSAEncryption
Questo esempio di output mostra un certificato non valido firmato con l'algoritmo SHA-1:
Certificate:
Data:
...
Signature Algorithm: sha1WithRSAEncryption
...
Signature Algorithm: sha1WithRSAEncryption
Se l'output del certificato è simile, devi aggiornarlo per utilizzare un algoritmo di firma compatibile. Ad esempio, se utilizzi l'API certificate.k8s.io
per gestire i certificati TLS nel tuo cluster, puoi seguire le istruzioni per creare una richiesta di firma del certificato.
Ridurre il rischio di upgrade alla versione 1.29
Dopo aver identificato i cluster interessati e i relativi servizi di backend che utilizzano certificati firmati con l'algoritmo SHA-1, devi aggiornare i servizi in modo che utilizzino certificati con algoritmi di firma compatibili prima di eseguire l'upgrade dei cluster alla versione 1.29.
I cluster interessati vengono rilevati automaticamente da GKE e non verrà eseguito l'upgrade automatico alla versione 1.29 finché i certificati incompatibili non saranno più utilizzati o la versione 1.28 non raggiungerà la fine del supporto. Una volta che la versione 1.28 avrà raggiunto la fine del supporto, verrà eseguito l'upgrade automatico dei cluster alla versione 1.29.
Algoritmi di firma compatibili
La versione 1.29 di GKE è compatibile con gli algoritmi supportati nel package Go x509. Sono inclusi i seguenti algoritmi:
SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519
Per trovare gli algoritmi disponibili, consulta il file di codice fonte x509.go e cerca UnknownSignatureAlgorithm SignatureAlgorithm = iota
. Gli algoritmi supportati dal pacchetto Go x509 sono elencati nel blocco const
con questa riga. Per trovare gli algoritmi di firma non sicuri non supportati, cerca gli utilizzi di InsecureAlgorithmError
nel file.
Risorse
Per ulteriori informazioni su questa modifica, consulta le seguenti risorse:
- Note di rilascio di Go 1.18
- Rimozione dell'opzione di debug x509sha1 in Go 1.24
- Algoritmi supportati di Go x509