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 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 los clústeres, debes reemplazar los certificados incompatibles de los backends de webhook y servidor de la API de extensión con certificados mediante algoritmos de firma compatibles antes de actualizar tus clústeres a la versión 1.29.

Impacto de esta eliminación en los clústeres

GKE pausa las actualizaciones automáticas cuando detecta que un clúster usa certificados que son incompatibles con la versión 1.29. Después de reemplazar los certificados por certificados mediante algoritmos de firma compatibles o la versión 1.28 alcanza el fin de la asistencia, GKE reanuda las actualizaciones automáticas.

Si no reemplazas los certificados incompatibles antes de actualizar a la versión 1.29, es posible que experimentes 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 el plano de control de Kubernetes que se comunica con tus webhooks con certificados incompatibles. Según la configuración, especialmente si usas webhooks de admisión, no 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 perjudicial.
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 su versión 1.18, Go comenzó a rechazar 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 habían habilitado 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 del plano de control de tu clúster a los webhooks o los servidores de la API de extensión en el clúster que proporcionan 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 los 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 gcloud CLI o la API de recomendador y filtrar 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 la guía de las estadísticas y recomendaciones

Una recomendación incluye el nombre de host del backend afectado y si es el servidor de webhook o de la API de extensión. Los nombres de host que hacen referencia a los objetos Service 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 servicio en el clúster o una URL. Para obtener más información, consulta Comunícate con el webhook.

Si el certificado afectado proviene de un servidor de 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 la extensión apiserver.

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 ejemplos de recomendaciones:

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

Los webhooks y los servidores de la API de extensión pueden tener el respaldo de Services.

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 no se incluye el TargetPort, 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: Estos siguientes comandos usan el puerto 8888; sin embargo, puedes elegir un puerto diferente, ya que este se elige 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 la redirección de puertos

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

Ejecuta el siguiente comando para mostrar los procesos en ejecución:
```
jobs
```
Ve el resultado para obtener el ID del proceso que finalizará:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Este resultado de ejemplo indica que el ID del proceso es 1.
Reemplaza PROCESS_ID para finalizar el proceso:
```
kill %PROCESS_ID
```
Consulta el siguiente resultado:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
Este resultado de ejemplo 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 automáticamente 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 alcance el final de asistencia. Una vez que la versión 1.28 llegue al fin de la asistencia, 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 algoritmos compatibles en el paquete Go x509. Esto incluye los siguientes algoritmos:

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

Para encontrar los algoritmos disponibles, consulta el archivo de origen x509.go y busca UnknownSignatureAlgorithm SignatureAlgorithm = iota. Los algoritmos que admite el paquete de 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 x509sha1 de Go 1.24
Algoritmos compatibles de Go x509