Vérifier la compatibilité des certificats TLS avant la mise à niveau vers GKE 1.29

Autopilot Standard

Les clusters GKE exécutant la version 1.29 ou ultérieure ne sont pas compatibles avec les certificats TLS (Transport Layer Security) signés avec l'algorithme SHA-1. Pour éviter tout impact sur vos clusters, vous devez remplacer les certificats incompatibles des backends de webhooks et de serveur d'API d'extensions par des certificats utilisant des algorithmes de signature compatibles avant de mettre à niveau vos clusters vers la version 1.29.

Impact de cette suppression sur les clusters

GKE suspend les mises à niveau automatiques lorsqu'il détecte qu'un cluster utilise des certificats incompatibles avec la version 1.29. Une fois que vous avez remplacé les certificats par des certificats utilisant des algorithmes de signature compatibles ou si la version 1.28 atteint la fin de sa période de compatibilité, GKE reprend les mises à niveau automatiques.

Si vous ne remplacez pas les certificats incompatibles avant de passer à la version 1.29, vous pouvez rencontrer les problèmes suivants avec vos clusters :

Les backends de webhooks GKE qui utilisent des certificats TLS signés avec l'algorithme SHA-1 cessent de fonctionner en raison d'un échec d'authentification. Les appels webhook échouent pour le plan de contrôle Kubernetes communiquant avec vos webhooks dotés de certificats non compatibles. En fonction de votre configuration, en particulier si vous utilisez des webhooks d'admission, le fait de ne pas parvenir à contacter un webhook peut bloquer la création de ressources (par exemple, de pods) sur votre cluster, ce qui peut être très disruptif.
Les appels vers les API diffusées par les serveurs d'API d'extensions échouent.

Pourquoi Kubernetes supprime cette fonctionnalité ?

GKE exploite Kubernetes Open Source, qui utilise le composant kube-apiserver pour contacter vos backends de webhooks et de serveur d'API d'extensions à l'aide de TLS. Le composant kube-apiserver est écrit dans le langage de programmation Go.

À partir de la version 1.18 de Go, Go a commencé à rejeter les certificats TLS signés avec l'algorithme SHA-1, mais a laissé un commutateur de débogage x509sha1=1 pour activer l'ancien comportement afin de faciliter le processus de migration. La version 1.24 de GKE est la première version créée à l'aide de la version 1.18 de Go. Les builds GKE de Kubernetes avaient activé ce commutateur de débogage jusqu'à la version 1.29. Le commutateur sera supprimé dans Go 1.24. GKE 1.29 compile Kubernetes avec le commutateur désactivé pour préparer la suppression future du commutateur de débogage de Go. Après que GKE a mis à niveau vos clusters vers la version 1.29, les appels du plan de contrôle de votre cluster vers les webhooks ou les serveurs d'API d'extensions du cluster qui fournissent un certificat TLS signé avec l'algorithme SHA-1 échouent.

Identifier les clusters concernés

GKE surveille vos clusters et utilise l'outil de recommandation pour vous fournir des conseils via des insights et des recommandations sur la façon d'identifier les clusters dotés de backends de webhooks ou de serveur d'API d'extensions utilisant des certificats TLS signés avec l'algorithme SHA-1. Vous pouvez également identifier les appels vers les backends concernés de votre cluster à l'aide des journaux.

Obtenir des insights et des recommandations

Pour les clusters exécutant la version 1.24 ou ultérieure, suivez les instructions pour afficher des insights et des recommandations. Vous pouvez obtenir des insights à l'aide de la gcloud CLI ou de l'API Recommender en filtrant avec le sous-type DEPRECATION_K8S_SHA_1_CERTIFICATE.

Obtenir des journaux

Pour les clusters exécutant les versions 1.24 ou ultérieures avec Cloud Logging activé, GKE fournit un journal Cloud Audit Logs pour identifier les appels vers les backends concernés de votre cluster. Vous pouvez utiliser le filtre suivant pour rechercher les journaux :

logName =~ "projects/.*/logs/cloudaudit.googleapis.com%2Factivity"
resource.type = "k8s_cluster"
operation.producer = "k8s.io"
"insecure-sha1.invalid-cert.kubernetes.io"

Les journaux d'audit indiquent le nom d'hôte du backend concerné. Pour en savoir plus sur l'interprétation des résultats, consultez la section suivante.

Interpréter les conseils à partir d'insights et de recommandations

Une recommandation indique le nom d'hôte du backend concerné, et s'il s'agit d'un webhook ou d'un serveur d'API d'extensions. Les noms d'hôtes qui font référence aux services du cluster respectent le format <service-name>.<namespace>.svc.

Si le certificat du backend concerné provient d'un serveur de webhook, le nom d'hôte peut être un service du cluster ou une URL. Pour en savoir plus, consultez la section Contacter le webhook.

Si le certificat concerné provient d'un serveur d'API d'extensions, le nom d'hôte est un service du cluster. Pour en savoir plus, consultez la section Contacter le serveur d'API d'extensions.

Une fois que vous avez identifié le backend concerné, suivez les instructions pour inspecter le certificat d'un service ou inspecter le certificat d'un backend d'URL, selon le type.

Si vos clusters n'ont pas appelé de serveurs avec des certificats concernés au cours des 30 derniers jours, vous ne verrez aucune recommandation.

Exemples de recommandations

Consultez la liste d'exemples de recommandations suivante :

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

Pour obtenir des détails sur le cluster et le service, décrivez la recommandation. La sortie d'un service nommé example-webhook dans l'espace de noms default est semblable à celle-ci :

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>

Inspecter le certificat d'un service

Les webhooks et les serveurs d'API d'extensions peuvent être sauvegardés par des services.

Une fois que vous avez identifié les services de backend pertinents à inspecter, suivez les instructions ci-dessous pour inspecter le certificat de chaque service afin de vérifier quels certificats utilisent l'algorithme SHA-1 et doivent être mis à jour.

Recherchez le sélecteur et le port cible du service :
```
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
```
Remplacez NAMESPACE et SERVICE_NAME par les valeurs de targetValue.

Le résultat ressemble à ce qui suit :
```
Name: example-service
Namespace: default
Labels: run=nginx
Selector: run=nginx
Type: ClusterIP
IP: 172.21.xxx.xxx
Port: 443
TargetPort: 444
```
Ce résultat indique que example-service dispose du sélecteur run=nginx et du port cible 444.

Remarque : Lorsque TargetPort n'est pas inclus, il correspond à la valeur indiquée dans le champ Port.

Recherchez un pod correspondant au sélecteur :

kubectl get pods --namespace=NAMESPACE --selector=run=nginx

Le résultat ressemble à ce qui suit :

NAME          READY   STATUS    RESTARTS   AGE
example-pod   1/1     Running   0          21m

Ce résultat indique que le pod correspondant est example-pod.

Configurez un transfert de port de votre hôte local kubectl vers le pod :

Remarque : Les commandes suivantes utilisent le port 8888, mais vous pouvez choisir un autre port, car celui-ci est choisi de manière arbitraire.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Remplacez SERVICE_TARGET_PORT par la valeur TargetPort du service. Si TargetPort n'est pas inclus, utilisez la valeur Port.
Utilisez openssl pour afficher le certificat utilisé par le service :
```
openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
```
Cet exemple de résultat montre un certificat valide signé avec l'algorithme SHA-256 :
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
```
Cet exemple de résultat montre un certificat non valide signé avec l'algorithme SHA-1 :
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
Si la sortie du certificat est semblable, vous devez le mettre à jour pour utiliser un algorithme de signature compatible. Par exemple, si vous utilisez l'API certificate.k8s.io pour gérer les certificats TLS dans votre cluster, vous pouvez suivre les instructions permettant de créer une requête de signature de certificat.

Supprimer le transfert de port

Pour supprimer le transfert de port en arrière-plan, recherchez le processus et arrêtez-le.

Exécutez la commande suivante pour répertorier les processus en cours :
```
jobs
```
Consultez le résultat pour obtenir l'ID du processus à arrêter :
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Cet exemple de résultat indique que l'ID du processus est 1.
Arrêtez le processus en remplaçant PROCESS_ID :
```
kill %PROCESS_ID
```
Consultez le résultat suivant :
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
Cet exemple de résultat indique que le processus a été arrêté.

Inspecter le certificat d'un backend d'URL

Si le webhook utilise un backend url, connectez-vous directement au nom d'hôte spécifié dans l'URL. Par exemple, si l'URL est https://example.com:123/foo/bar, exécutez la commande openssl suivante pour afficher le certificat utilisé par le backend :

openssl s_client -connect example.com:123 </dev/null | openssl x509 -noout -text

Cet exemple de résultat montre un certificat valide signé avec l'algorithme SHA-256 :

Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption

Cet exemple de résultat montre un certificat non valide signé avec l'algorithme SHA-1 :

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

Si la sortie du certificat est semblable, vous devez le mettre à jour pour utiliser un algorithme de signature compatible. Par exemple, si vous utilisez l'API certificate.k8s.io pour gérer les certificats TLS dans votre cluster, vous pouvez suivre les instructions permettant de créer une requête de signature de certificat.

Limiter le risque de passer à la version 1.29

Après avoir identifié les clusters concernés et les services de backend associés utilisant des certificats signés avec l'algorithme SHA-1, vous devez mettre à jour les services pour utiliser des certificats avec des algorithmes de signature compatibles avant de procéder à la mise à niveau des clusters vers la version 1.29.

Les clusters concernés sont automatiquement détectés par GKE et ne sont pas mis à niveau automatiquement vers la version 1.29 tant que les certificats incompatibles ne sont plus utilisés ou que la version 1.28 atteint la fin de sa période de compatibilité. Lorsque la version 1.28 atteint la fin de sa période de compatibilité, les clusters sont mis à niveau automatiquement vers la version 1.29.

Algorithmes de signature compatibles

La version 1.29 de GKE est compatible avec les algorithmes du package Go x509, y compris les suivants :

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

Pour trouver les algorithmes disponibles, consultez le fichier source x509.go et recherchez UnknownSignatureAlgorithm SignatureAlgorithm = iota. Les algorithmes compatibles avec le package Go x509 sont répertoriés dans le bloc const avec cette ligne. Pour trouver les algorithmes de signature non sécurisés incompatibles, recherchez InsecureAlgorithmError dans le fichier.

Ressources

Pour en savoir plus sur ce changement, consultez les ressources suivantes :

Notes de version Go 1.18
Suppression du commutateur de débogage x509sha1 dans Go 1.24
Algorithmes compatibles avec Go x509