Asegúrate de que los certificados TLS sean compatibles antes de actualizar a GKE 1.29

Autopilot Estándar

Los clústeres de GKE que ejecutan la versión 1.29 o una posterior no son compatibles con los certificados de seguridad de la capa de transporte (TLS) firmados con el algoritmo SHA-1. Para evitar el impacto en tus clústeres, debes reemplazar los certificados incompatibles de los backends de webhook y de servidor de la API de extensión certificados mediante algoritmos de firma compatibles antes de actualizar tus clústeres a la versión 1.29.

Impacto de los clústeres de esta eliminación

GKE Pausa las actualizaciones automáticas cuando detecta que un clúster usa certificados que no son compatibles con la versión 1.29. Después de reemplazar los certificados por certificados que usan algoritmos de firma compatibles, o la versión 1.28 alcanza el final del ciclo de vida, GKE reanuda las actualizaciones automáticas.

Si no reemplazas los certificados incompatibles antes de actualizar a la versión 1.29, podrías experimentar los siguientes problemas con tus clústeres:

Los backends de webhook de GKE que usan certificados TLS firmados con el algoritmo SHA-1 dejarán de funcionar debido a una falla de autenticación. Las llamadas de webhook fallarán para que el plano de control de Kubernetes se comunique con tus webhooks con certificados incompatibles. Según la configuración, especialmente si usas webhooks de admisión, la imposibilidad de comunicarse con un webhook podría bloquear la creación de recursos en el clúster, como la creación de Pods, lo que puede ser muy disruptivo.
Las llamadas a las APIs que entregan los servidores de la API de extensión fallarán.

Por qué Kubernetes quita esta capacidad

GKE opera con Kubernetes de código abierto, que usa el componente kube-apiserver para comunicarse con los backends del servidor de la API de extensión y webhook mediante TLS. El componente kube-apiserver se escribe en el lenguaje de programación Go.

A partir de la versión 1.18 de Go, Go comenzó a rechazar los certificados TLS firmados con el algoritmo SHA-1, pero dejó un interruptor de depuración x509sha1=1 para habilitar el comportamiento anterior a fin de facilitar el proceso de migración. La versión 1.24 de GKE fue la primera versión compilada con la versión 1.18 de Go. Las compilaciones de GKE de Kubernetes habilitaron este interruptor de depuración hasta la versión 1.29. El interruptor se quitará en Go 1.24. GKE 1.29 compila Kubernetes con el interruptor inhabilitado para prepararse para la eliminación futura del interruptor de Go. Después de que GKE actualice tus clústeres a la versión 1.29, las llamadas desde el plano de control de tu clúster a webhooks o servidores de API de extensión en el clúster que proporcionen un certificado TLS firmado con el algoritmo SHA-1 fallarán.

Identifica los clústeres afectados

GKE supervisa tus clústeres y usa el servicio del recomendador para proporcionar orientación a través de estadísticas y recomendaciones que identifican clústeres que tienen backends de servidor de la API de extensión o webhook mediante certificados TLS firmados con el algoritmo SHA- 1. O bien, puedes usar registros para identificar llamadas a backends afectados desde tu clúster.

Cómo obtener estadísticas y recomendaciones

Para los clústeres que ejecutan la versión 1.24 o posterior, sigue las instrucciones para ver estadísticas y recomendaciones. Puedes obtener estadísticas mediante la CLI de gcloud o la API de recomendador si filtras con el subtipo DEPRECATION_K8S_SHA_1_CERTIFICATE.

Cómo obtener registros

Para los clústeres que ejecutan la versión 1.24 o posterior con Cloud Logging habilitado, GKE proporciona un registro de los Registros de auditoría de Cloud para identificar las llamadas a los backends afectados. del clúster. Puedes usar el siguiente filtro para buscar los registros:

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

Los registros de auditoría incluyen el nombre de host del backend afectado. Para obtener más información sobre cómo interpretar los resultados, consulta la siguiente sección.

Interpreta los lineamientos a partir de estadísticas y recomendaciones

Una recomendación incluye el nombre de host del backend afectado y si es un servidor de API de webhook o extensión. Los nombres de host que hacen referencia a los servicios en el clúster siguen el formato <service-name>.<namespace>.svc.

Si el certificado de backend afectado es de un servidor de webhook, el nombre de host puede ser un Service en el clúster o una URL. Para obtener más información, consulta Comunícate con el webhook.

Si el certificado afectado es de un servidor de la API de extensión, el nombre de host es un Service en el clúster. Para obtener más información, consulta Comunícate con el apiserver de extensión.

Una vez que hayas identificado el backend afectado, sigue las instrucciones para inspeccionar el certificado de un servicio o inspeccionar el certificado de un backend de URL, según el tipo.

Si tus clústeres no llamaron a los servidores con certificados afectados en los últimos 30 días, no verás ninguna recomendación.

Ejemplos de recomendaciones

Consulta la siguiente lista de recomendaciones de ejemplo:

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

Para obtener detalles del clúster y el servicio, describe la recomendación. El resultado de un servicio llamado example-webhook en el espacio de nombres default es similar al siguiente:

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>

Inspecciona el certificado de un servicio

Los webhooks y los servidores de la API de extensión pueden estar respaldados por servicios.

Una vez que hayas identificado los servicios de backend relevantes para inspeccionar, usa las siguientes instrucciones para inspeccionar el certificado de cada servicio y verificar qué certificados usan el algoritmo SHA-1 y deben actualizarse.

Busca el selector y el puerto de destino del Service:
```
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
```
Reemplaza NAMESPACE y SERVICE_NAME por los valores de targetValue.

El resultado es similar al siguiente:
```
Name: example-service
Namespace: default
Labels: run=nginx
Selector: run=nginx
Type: ClusterIP
IP: 172.21.xxx.xxx
Port: 443
TargetPort: 444
```
Este resultado indica que example-service tiene el selector run=nginx y el puerto de destino 444.

Nota: Cuando TargetPort no está incluido, es el mismo valor que el campo Port.

Busca un Pod que coincida con el selector:

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

El resultado es similar al siguiente:

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

Este resultado indica que el Pod coincidente es example-pod.

Configura un redirección de puertos desde tu localhost kubectl al Pod.

Nota: En los siguientes comandos, se usa el puerto 8888, pero puedes elegir un puerto diferente, ya que se selecciona de manera arbitraria.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Reemplaza SERVICE_TARGET_PORT por el valor TargetPort del Service. Si no se incluye TargetPort, usa el valor Port.
Usa openssl para mostrar el certificado que usa el Service:
```
openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
```
En este resultado de ejemplo, se muestra un certificado válido firmado con el algoritmo SHA-256:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
```
En este resultado de ejemplo, se muestra un certificado no válido firmado con el algoritmo SHA-1:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
Si el resultado del certificado es similar, debes actualizar el certificado para usar un algoritmo de firma compatible. Por ejemplo, si usas la API de certificate.k8s.io para administrar certificados TLS en tu clúster, puedes seguir las instrucciones paa crear una solicitud de firma de certificado.

Limpia el puerto de redirección

Para limpiar el puerto de redirección que se ejecuta en segundo plano, busca el proceso y finalízalo.

Ejecuta el siguiente comando para enumerar los procesos en ejecución:
```
jobs
```
Consulta el resultado para obtener el ID del proceso que deseas finalizar:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Este resultado de ejemplo indica que el ID del proceso es 1.
Para finalizar el proceso, reemplaza PROCESS_ID:
```
kill %PROCESS_ID
```
Consulta el siguiente resultado:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
En este resultado de ejemplo, se muestra que el proceso finalizó.

Inspecciona el certificado de un backend de URL

Si el webhook usa un backend de url, conéctate de forma directa al nombre de host especificado en la URL. Por ejemplo, si la URL es https://example.com:123/foo/bar, usa el siguiente comando openssl para mostrar el certificado que usa el backend:

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

En este resultado de ejemplo, se muestra un certificado válido firmado con el algoritmo SHA-256:

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

En este resultado de ejemplo, se muestra un certificado no válido firmado con el algoritmo SHA-1:

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

Si el resultado del certificado es similar, debes actualizar el certificado para usar un algoritmo de firma compatible. Por ejemplo, si usas la API de certificate.k8s.io para administrar certificados TLS en tu clúster, puedes seguir las instrucciones paa crear una solicitud de firma de certificado.

Mitiga el riesgo de actualizar a 1.29

Una vez que identificaste los clústeres afectados y sus servicios de backend mediante certificados firmados con el algoritmo SHA-1, debes actualizar los Services para usar certificados con algoritmos de firma compatibles antes de la actualización. los clústeres a la versión 1.29.

GKE detecta de forma automática los clústeres afectados y no se actualizarán de forma automática a la versión 1.29 hasta que ya no se usen certificados incompatibles o la versión 1.28 finalice de la vida. Una vez que la versión 1.28 alcance el final del ciclo de vida, los clústeres se actualizarán de forma automática a la versión 1.29.

Algoritmos de firma compatibles

La versión 1.29 de GKE es compatible con los algoritmos compatibles en el paquete de Go x509. Esto incluye los siguientes algoritmos:

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

Para encontrar algoritmos disponibles, consulta el archivo de origen x509.go y busca UnknownSignatureAlgorithm SignatureAlgorithm = iota. Los algoritmos que admiten el paquete Go x509 se enumeran en el bloque const con esta línea. Para encontrar algoritmos de firma no seguros no compatibles, busca los usos de InsecureAlgorithmError en el archivo.

Recursos

Consulta los siguientes recursos para obtener más información sobre este cambio:

Notas de la versión de Go 1.18
Eliminación del interruptor de depuración de Go 1.24 x509sha1
Algoritmos compatibles Go x509