Esta página se ha traducido con Cloud Translation API.

Asegurar la compatibilidad de los certificados TLS antes de actualizar a GKE 1.29

Autopilot Standard

Los clústeres de GKE que ejecutan la versión 1.29 o una posterior no admiten certificados de seguridad en la capa de transporte (TLS) firmados con el algoritmo SHA-1. Para evitar que se vean afectados tus clústeres, debes sustituir los certificados incompatibles de los back-ends del webhook y del servidor de la API de extensión por certificados que usen algoritmos de firma compatibles antes de actualizar tus clústeres a la versión 1.29.

Consecuencias de esta eliminación en los clústeres

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 sustituir los certificados por certificados que usen algoritmos de firma compatibles o cuando la versión 1.28 llegue al final de la asistencia, GKE reanudará las actualizaciones automáticas.

Si no sustituyes los certificados incompatibles antes de actualizar a la versión 1.29, es posible que tus clústeres tengan los siguientes problemas:

Los back-ends de webhook de GKE que usen certificados TLS firmados con el algoritmo SHA-1 dejarán de funcionar debido a un fallo de autenticación. Las llamadas de webhook fallarán si el plano de control de Kubernetes se comunica con tus webhooks con certificados incompatibles. En función de tu configuración, sobre todo si usas webhooks de admisión, si no se puede contactar con un webhook, se puede bloquear la creación de recursos en tu clúster, como la creación de pods, lo que puede ser muy perjudicial.
Las llamadas a las APIs servidas por los servidores de APIs de la extensión fallarán.

Por qué Kubernetes va a eliminar esta función

GKE utiliza Kubernetes de código abierto, que usa el componente kube-apiserver para ponerse en contacto con los back-ends de tu webhook y del servidor de la API de extensión mediante TLS. El componente kube-apiserver está escrito en el lenguaje de programación Go.

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

Identifica los clústeres afectados

GKE monitoriza tus clústeres y usa el servicio Recommender para ofrecerte orientación a través de estadísticas y recomendaciones que identifican los clústeres que tienen back-ends de servidor de API de extensiones o webhook que usan certificados TLS firmados con el algoritmo SHA-1. También puedes usar los registros para identificar las llamadas a los back-ends afectados desde tu clúster.

Cómo obtener estadísticas y recomendaciones

En 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 con la CLI de gcloud o la API Recommender, filtrando por el subtipo DEPRECATION_K8S_SHA_1_CERTIFICATE.

Cómo obtener registros

En los clústeres que ejecutan la versión 1.24 o posterior con Cloud Logging habilitado, GKE proporciona un registro de auditoría de Cloud para identificar las llamadas a los back-ends afectados desde tu 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 sección siguiente.

Interpretar las directrices de las estadísticas y las recomendaciones

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

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

Si el certificado afectado es de un servidor de API de extensión, el nombre de host es un servicio del clúster. Para obtener más información, consulta el artículo Contactar con el apiserver de la 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 han llamado a 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 información sobre el 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>

Inspeccionar el certificado de un servicio

Tanto los webhooks como los servidores de APIs de extensión pueden estar respaldados por servicios.

Una vez que hayas identificado los servicios de backend relevantes que quieres inspeccionar, sigue estas instrucciones para inspeccionar el certificado de cada servicio y comprobar qué certificados usan el algoritmo SHA-1 y deben actualizarse.

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

El resultado debería ser 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: Si no se incluye TargetPort, el valor es el mismo que el del campo Port.

Buscar un pod que coincida con el selector:

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

El resultado debería ser similar al siguiente:

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

Esta salida indica que el pod coincidente es example-pod.

Configura un reenvío de puertos desde tu kubectl localhost al pod:

Nota: Los siguientes comandos usan el puerto 8888, pero puedes elegir otro puerto, ya que este se ha elegido de forma arbitraria.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Sustituye SERVICE_TARGET_PORT por el valor de TargetPort del servicio. Si no se incluye TargetPort, utilice el valor Port.
Usa openssl para mostrar el certificado que usa el servicio:
```
openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
```
En este ejemplo se muestra un certificado válido firmado con el algoritmo SHA-256:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
```
En este 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 actualizarlo para que use un algoritmo de firma compatible. Por ejemplo, si usas la API certificate.k8s.io para gestionar certificados TLS en tu clúster, puedes seguir las instrucciones para crear una solicitud de firma de certificado.

Limpiar la redirección de puertos

Para limpiar el reenvío de puertos que se está ejecutando en segundo plano, busca el proceso y termina.

Ejecuta el siguiente comando para enumerar los procesos en ejecución:
```
jobs
```
Consulta la salida para obtener el ID del proceso que se va a finalizar:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Esta salida de ejemplo indica que el ID de proceso es 1.
Termina el proceso y sustituye PROCESS_ID:
```
kill %PROCESS_ID
```
Consulta el siguiente resultado:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
En este ejemplo de salida se muestra que el proceso se ha terminado.

Inspeccionar el certificado de un backend de URL

Si el webhook usa un backend de url, conéctate directamente 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 ejemplo se muestra un certificado válido firmado con el algoritmo SHA-256:

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

En este 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 actualizarlo para que use un algoritmo de firma compatible. Por ejemplo, si usas la API certificate.k8s.io para gestionar certificados TLS en tu clúster, puedes seguir las instrucciones para crear una solicitud de firma de certificado.

Mitigar el riesgo de actualizar a la versión 1.29

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

GKE detecta automáticamente los clústeres afectados y no se actualizarán automáticamente a la versión 1.29 hasta que se dejen de usar los certificados incompatibles o hasta que la versión 1.28 llegue al final del periodo de asistencia. Cuando la versión 1.28 llegue al final del periodo de asistencia, los clústeres se actualizarán automáticamente a la versión 1.29.

Algoritmos de firma compatibles

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

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

Para ver los algoritmos disponibles, consulta el archivo de origen x509.go y busca UnknownSignatureAlgorithm SignatureAlgorithm = iota. Los algoritmos que admite el paquete Go x509 se enumeran en el bloque const con esta línea. Para encontrar algoritmos de firma inseguros no compatibles, busca 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
Go 1.24 Eliminación del interruptor de depuración x509sha1
Consulta los algoritmos compatibles de Go x509.