Garanta a compatibilidade dos certificados TLS antes de fazer upgrade para o GKE 1.29

Autopilot Padrão

Os clusters do GKE que executam a versão 1.29 ou mais recente não são compatíveis com certificados TLS (Transport Layer Security) assinados com o algoritmo SHA-1. Para evitar impacto nos clusters, você precisa substituir certificados incompatíveis de back-ends de webhook e servidor da API de extensão por certificados usando algoritmos de assinatura compatíveis antes de fazer upgrade dos clusters para a versão 1.29.

Impacto nos clusters desta remoção

O GKE pausa os upgrades automáticos quando detecta que um cluster está usando certificados incompatíveis com a versão 1.29. Depois que você substitui os certificados por certificados usando algoritmos de assinatura compatíveis, ou a versão 1.28 chega ao fim da vida útil, o GKE retoma os upgrades automáticos.

Se você não substituir os certificados incompatíveis antes de fazer upgrade para a versão 1.29, poderá ter os seguintes problemas com os clusters:

Os back-ends de webhook do GKE que usam certificados TLS assinados com o algoritmo SHA-1 deixarão de funcionar devido a uma falha de autenticação. As chamadas de webhook falharão quando o plano de controle do Kubernetes se comunicar com os webhooks com certificados incompatíveis. Dependendo da configuração, especialmente se você usar webhooks de admissão, a falha em contatar um webhook poderá bloquear a criação de recursos no cluster, como a criação de pods, o que pode ser muito prejudicial.
As chamadas para APIs atendidas pelos servidores da API de extensão falharão.

Por que o Kubernetes está removendo esse recurso

O GKE opera o Kubernetes de código aberto, que usa o componente kube-apiserver para entrar em contato com os back-ends de servidor da API de extensão e webhook usando TLS. O componente kube-apiserver é escrito na Linguagem de programação Go.

Na versão 1.18 do Go, o Go começou a rejeitar certificados TLS assinados com o algoritmo SHA-1, mas deixou uma chave de depuração x509sha1=1 para ativar o comportamento antigo e facilitar o processo de migração. A versão 1.24 do GKE foi a primeira criada usando o Go versão 1.18. Os builds do GKE do Kubernetes tinham essa chave de depuração ativada até a versão 1.29. A chave será removida no Go 1.24 (link em inglês). O GKE 1.29 cria o Kubernetes com a chave desativada para se preparar para a futura remoção da chave de depuração pelo Go. Depois que o GKE fizer upgrade dos clusters para a versão 1.29, as chamadas do plano de controle do cluster para webhooks ou servidores de API de extensão no cluster que fornecerem um certificado TLS assinado com o algoritmo SHA-1 falharão.

Identificar os clusters afetados

O GKE monitora seus clusters e usa o serviço do Recomendador para fornecer orientação por meio de insights e recomendações que identificam clusters que têm back-ends de servidor de API de extensão ou webhook usando certificados TLS assinados com o algoritmo SHA-1. Ou é possível usar registros para identificar chamadas para back-ends afetados do seu cluster.

Como receber insights e recomendações

Para clusters com a versão 1.24 ou mais recente, siga as instruções para ver insights e recomendações. É possível receber insights usando a gcloud CLI ou a API Recommender, filtrando com o subtipo DEPRECATION_K8S_SHA_1_CERTIFICATE.

Como conseguir registros

Para clusters em execução na versão 1.24 ou posterior com o Cloud Logging ativado, o GKE fornece um registro dos Registros de auditoria do Cloud para identificar chamadas para os back-ends afetados do cluster. Use o filtro a seguir para pesquisar os registros:

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

Os registros de auditoria incluem o nome do host do back-end afetado. Para saber mais sobre como interpretar os resultados, consulte a próxima seção.

Interpretar as orientações dos insights e recomendações

Uma recomendação inclui o nome do host do back-end afetado e se é o webhook ou o servidor da API de extensão. Os nomes de host que se referem a Serviços no cluster seguem o formato <service-name>.<namespace>.svc.

Se o certificado de back-end afetado for de um servidor de webhook, o nome do host poderá ser um Serviço no cluster ou um URL. Para saber mais, consulte Como entrar em contato com o webhook.

Se o certificado afetado for de um servidor de API de extensão, o nome do host será um Serviço no cluster. Para saber mais, consulte Como entrar em contato com o apiserver da extensão.

Depois de identificar o back-end afetado, siga as instruções para inspecionar o certificado de um Serviço ou inspecionar o certificado de um back-end de URL, dependendo do tipo.

Se os clusters não tiverem chamado servidores com certificados afetados nos últimos 30 dias, nenhuma recomendação será exibida.

Exemplos de recomendação

Confira a seguinte lista de exemplos de recomendações:

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 ver detalhes do cluster e do Serviço, descreva a recomendação. A saída de um Serviço chamado example-webhook no namespace default é semelhante a esta:

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>

Inspecionar o certificado de um Serviço

Tanto os webhooks quanto os servidores de API de extensão podem ser apoiados pelos Serviços.

Depois de identificar os Serviços de back-end relevantes para inspeção, use as instruções a seguir para inspecionar o certificado de cada Serviço e verificar quais certificados usam o algoritmo SHA-1 e precisam ser atualizados.

Encontre o seletor e a porta de destino do Serviço:
```
kubectl describe service --namespace=NAMESPACE SERVICE_NAME
```
Substitua NAMESPACE e SERVICE_NAME pelos valores de targetValue.

O resultado será assim:
```
Name: example-service
Namespace: default
Labels: run=nginx
Selector: run=nginx
Type: ClusterIP
IP: 172.21.xxx.xxx
Port: 443
TargetPort: 444
```
Essa saída indica que example-service tem o seletor run=nginx e a porta de destino 444.

Observação: quando TargetPort não está incluído, ele tem o mesmo valor que o campo Port.

Encontre um pod que corresponda ao seletor:

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

O resultado será assim:

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

Essa saída indica que o pod correspondente é example-pod.

Configure um encaminhamento de portas do localhost kubectl para o pod:

Observação: estes comandos a seguir usam a porta 8888, mas é possível escolher uma porta diferente, já que ela é escolhida arbitrariamente.
```
kubectl port-forward --namespace=NAMESPACE pods/example-pod 8888:SERVICE_TARGET_PORT &
```
Substitua SERVICE_TARGET_PORT pelo valor TargetPort do Serviço. Se TargetPort não estiver incluído, use o valor Port.
Use openssl para mostrar o certificado que o Serviço usa:
```
openssl s_client -connect localhost:8888 </dev/null | openssl x509 -noout -text
```
Este exemplo de saída mostra um certificado válido assinado com o algoritmo SHA-256:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha256WithRSAEncryption
...
    Signature Algorithm: sha256WithRSAEncryption
```
Este exemplo de saída mostra um certificado inválido assinado com o algoritmo SHA-1:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
Se a saída do certificado for semelhante, será necessário atualizá-lo para usar um algoritmo de assinatura compatível. Por exemplo, se você usar a API certificate.k8s.io para gerenciar certificados TLS no cluster, siga as instruções para criar uma solicitação de assinatura de certificado.

Limpar o encaminhamento da porta

Para limpar o encaminhamento de portas em execução em segundo plano, encontre e encerre o processo.

Execute o comando a seguir para listar os processos em execução:
```
jobs
```
Confira a saída para saber o ID do processo a ser encerrado:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
O exemplo de saída indica que o ID do processo é 1.
Encerre o processo substituindo PROCESS_ID:
```
kill %PROCESS_ID
```
Confira a saída a seguir:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
O exemplo de saída mostra que o processo foi encerrado.

Como inspecionar o certificado de um back-end de URL

Se o webhook usar um back-end url, conecte-se diretamente ao nome do host especificado no URL. Por exemplo, se o URL for https://example.com:123/foo/bar, use o seguinte comando openssl para mostrar o certificado usado pelo back-end:

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

Este exemplo de saída mostra um certificado válido assinado com o algoritmo SHA-256:

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

Este exemplo de saída mostra um certificado inválido assinado com o algoritmo SHA-1:

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

Se a saída do certificado for semelhante, será necessário atualizá-lo para usar um algoritmo de assinatura compatível. Por exemplo, se você usar a API certificate.k8s.io para gerenciar certificados TLS no cluster, siga as instruções para criar uma solicitação de assinatura de certificado.

Reduza o risco de fazer upgrade para a versão 1.29

Depois de identificar os clusters afetados e os Serviços de back-end deles usando certificados assinados com o algoritmo SHA-1, atualize os Serviços para usar certificados com algoritmos de assinatura compatíveis antes de fazer upgrade dos clusters para a versão 1.29.

Os clusters afetados são detectados automaticamente pelo GKE e não receberão upgrade automático para a versão 1.29 até que os certificados incompatíveis não sejam mais usados ou a versão 1.28 chegue ao fim da vida útil. Quando a versão 1.28 chegar ao fim da vida útil, os clusters terão o upgrade feito automaticamente para a versão 1.29.

Algoritmos de assinatura compatíveis

A versão 1.29 do GKE é compatível com algoritmos compatíveis no pacote Go x509. Isso inclui os seguintes algoritmos:

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

Para encontrar algoritmos disponíveis, consulte o arquivo de origem x509.go e procure UnknownSignatureAlgorithm SignatureAlgorithm = iota. Os algoritmos compatíveis com o pacote Go x509 são listados no bloco const com essa linha. Para encontrar algoritmos de assinatura não seguros sem suporte, pesquise os usos de InsecureAlgorithmError no arquivo.

Recursos

Consulte os seguintes recursos para mais informações sobre essa alteração:

Notas de lançamento do Go 1.18
Remoção da chave de depuração x509sha1 do Go 1.24
Algoritmos compatíveis do Go x509