Assicurati la compatibilità dei certificati TLS prima di eseguire l'upgrade a GKE 1.29

I cluster GKE che eseguono la versione 1.29 o successive non supportano i certificati Transport Layer Security (TLS) firmati con l'algoritmo SHA-1. Per evitare conseguenze sui tuoi cluster, devi sostituire i certificati incompatibili dei backend del webhook e del server API delle estensioni con certificati che utilizzano algoritmi di firma compatibili prima di eseguire l'upgrade dei cluster alla versione 1.29.

Impatto sui cluster di questa rimozione

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 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:

  • I backend webhook GKE che utilizzano certificati TLS firmati con l'algoritmo SHA-1 smetteranno di funzionare a causa dell'errore di autenticazione. Le chiamate 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 controllo dell'ammissione, il mancato contatto con un webhook potrebbe bloccare la creazione di risorse sul cluster, ad esempio la creazione di pod, il che può essere molto problematico.
  • Le chiamate alle API gestite dai server API di estensione non andranno a buon fine.

Perché Kubernetes sta rimuovendo questa funzionalità

GKE utilizza 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.

A partire dalla versione 1.18, Go ha iniziato a rifiutare i certificati TLS firmati con l'algoritmo SHA-1, ma ha lasciato un'opzione di debug x509sha1=1 per attivare il vecchio comportamento e semplificare la procedura di migrazione. GKE 1.24 è stata la prima versione creata utilizzando Go 1.18. Le build di Kubernetes di GKE avevano abilitato questo flag di debug fino alla versione 1.29. L'opzione verrà rimossa in Go 1.24. Le build di GKE 1.29 creano Kubernetes con l'opzione disattivata per prepararsi alla futura rimozione dell'opzione di debug di Go. Dopo che GKE esegue l'upgrade dei cluster alla versione 1.29, le chiamate dal piano di controllo del cluster ai webhook o ai server API di estensione 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 webhook o server API delle estensioni 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 ottenere approfondimenti e consigli

Per i cluster che eseguono la versione 1.24 o successive, segui le istruzioni per visualizzare approfondimenti e consigli. Puoi ottenere insight utilizzando gcloud CLI o l'API Recommender, filtrando con il sottotipo DEPRECATION_K8S_SHA_1_CERTIFICATE.

Come ottenere i log

Per i cluster che eseguono la versione 1.24 o successive con Cloud Logging abilitato, GKE fornisce un log Cloud Audit Logs 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.

Interpretare le indicazioni di approfondimenti e consigli

Un consiglio include il nome host del backend interessato e indica 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 di backend interessato proviene da un server webhook, il nome host può essere un servizio nel cluster o un URL. Per saperne di più, consulta Contattare il webhook.

Se il certificato interessato proviene da un server API delle 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 ispezionare il certificato di un servizio o ispezionare il certificato di un backend URL, a seconda del tipo.

Se i tuoi cluster non hanno chiamato server con certificati interessati negli ultimi 30 giorni, non vedrai alcun consiglio.

Esempi di consigli

Vedi il seguente elenco di consigli di esempio:

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 suggerimento. 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>

Esaminare il certificato di un servizio

Sia i webhook che i server API di estensione possono essere supportati dai servizi.

Dopo aver identificato i servizi di backend pertinenti da esaminare, utilizza le seguenti istruzioni per esaminare il certificato di ogni servizio e verificare quali certificati utilizzano l'algoritmo SHA-1 e devono essere aggiornati.

  1. Trova il selettore e la porta di destinazione del servizio:

    kubectl describe service --namespace=NAMESPACE SERVICE_NAME

    Sostituisci NAMESPACE e SERVICE_NAME con i valori di targetValue.

    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 selettore run=nginx e la porta di destinazione 444.

  2. 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.

  3. Configura un port forwarding da localhost kubectl al pod:

    kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &

    Sostituisci SERVICE_TARGET_PORT con il valore TargetPort del servizio. Se TargetPort non è incluso, utilizza il valore Port.

  4. Utilizza 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 l'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:

    Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption

    Se l'output del certificato è simile, devi aggiornare il certificato 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.

Pulire il port forward

Per pulire l'inoltro delle porte in esecuzione in background, trova il processo e terminalo.

  1. Esegui il comando seguente 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 processo è 1.

  2. Termina la procedura, sostituendo PROCESS_ID:

    kill %PROCESS_ID

    Vedi l'output seguente:

    [1]+  Terminated              kubectl port-forward pods/example 8888:444

    Questo output di esempio 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 output di esempio mostra un certificato valido firmato con l'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:

Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption

Se l'output del certificato è simile, devi aggiornare il certificato 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 eseguire l'upgrade alla versione 1.29

Dopo aver identificato i cluster interessati e i relativi servizi di backend utilizzando 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 fino a quando i certificati incompatibili non saranno più utilizzati o la versione 1.28 raggiungerà la fine del supporto. Una volta che la versione 1.28 avrà raggiunto la fine del supporto, i cluster verranno aggiornati automaticamente alla versione 1.29.

Algoritmi di firma compatibili

GKE versione 1.29 è compatibile con gli algoritmi supportati nel pacchetto 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 origine x509.go e cerca UnknownSignatureAlgorithm SignatureAlgorithm = iota. Gli algoritmi supportati dal pacchetto Go x509 sono elencati nel blocco const con questa riga. Per trovare 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: