Esta página foi traduzida pela API Cloud Translation.

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

Autopilot Padrão

Os clusters do GKE com a versão 1.29 ou posterior não suportam certificados do Transport Layer Security (TLS) assinados com o algoritmo SHA-1. Para evitar o impacto nos seus clusters, tem de substituir os certificados incompatíveis dos back-ends do servidor da API de extensão e do webhook por certificados que usem algoritmos de assinatura compatíveis antes de atualizar os seus clusters para a versão 1.29.

Impacto nos clusters desta remoção

O GKE pausa as atualizações automáticas quando deteta que um cluster está a usar certificados incompatíveis com a versão 1.29. Depois de substituir os certificados por certificados que usam algoritmos de assinatura compatíveis ou a versão 1.28 atingir o fim do apoio técnico, o GKE retoma as atualizações automáticas.

Se não substituir os certificados incompatíveis antes da atualização para a versão 1.29, pode ter os seguintes problemas com os seus clusters:

Os back-ends de webhook do GKE que usam certificados TLS assinados com o algoritmo SHA-1 vão deixar de funcionar devido a uma falha de autenticação. As chamadas de webhook falham para o plano de controlo do Kubernetes que comunica com os seus webhooks com certificados incompatíveis. Consoante a sua configuração, especialmente se usar webhooks de admissão, a falha ao contactar um webhook pode bloquear a criação de recursos no seu cluster, como a criação de pods, o que pode ser muito prejudicial.
As chamadas para APIs servidas pelos servidores de APIs de extensões vão falhar.

Por que motivo o Kubernetes está a remover esta capacidade

O GKE opera o Kubernetes de código aberto, que usa o componente kube-apiserver para contactar os back-ends do servidor da API de extensão e webhook através de TLS. O componente kube-apiserver está escrito na linguagem de programação Go.

A partir da versão 1.18, o Go começou a rejeitar certificados TLS assinados com o algoritmo SHA-1, mas deixou um comutador de depuração x509sha1=1 para ativar o comportamento antigo para facilitar o processo de migração. A versão 1.24 do GKE foi a primeira versão criada com a versão 1.18 do Go. As compilações do GKE do Kubernetes tinham ativado este interruptor de depuração até à versão 1.29. O comutador vai ser removido no Go 1.24. O GKE 1.29 cria o Kubernetes com a opção desativada para se preparar para a futura remoção do Go da opção de depuração. Depois de o GKE atualizar os seus clusters para a versão 1.29, as chamadas do plano de controlo do cluster para webhooks ou servidores de API de extensão no cluster que fornecem um certificado TLS assinado com o algoritmo SHA-1 vão falhar.

Identifique os clusters afetados

O GKE monitoriza os seus clusters e usa o serviço Recommender para fornecer orientações através de estatísticas e recomendações que identificam clusters com back-ends de servidor de API de extensões ou webhook que usam certificados TLS assinados com o algoritmo SHA-1. Em alternativa, pode usar registos para identificar chamadas para back-ends afetados a partir do seu cluster.

Como receber estatísticas e recomendações

Para clusters com a versão 1.24 ou posterior, siga as instruções para ver estatísticas e recomendações. Pode obter estatísticas através da CLI gcloud ou da API Recommender, filtrando com o subtipo DEPRECATION_K8S_SHA_1_CERTIFICATE.

Como obter registos

Para clusters com a versão 1.24 ou posterior com o Cloud Logging ativado, o GKE fornece um registo de registos de auditoria da nuvem para identificar chamadas para back-ends afetados a partir do seu cluster. Pode usar o seguinte filtro para pesquisar os registos:

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

Os registos de auditoria incluem o nome do anfitrião do back-end afetado. Para saber mais sobre como interpretar os resultados, consulte a secção seguinte.

Interprete as orientações das estatísticas e recomendações

Uma recomendação inclui o nome de anfitrião do back-end afetado e se é um servidor de API de extensão ou webhook. Os nomes de anfitrião que fazem referência 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 anfitrião pode ser um serviço no cluster ou um URL. Para saber mais, consulte o artigo Contactar o webhook.

Se o certificado afetado for de um servidor de API de extensão, o nome de anfitrião é um serviço no cluster. Para saber mais, consulte o artigo Contactar o servidor de API de 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, consoante o tipo.

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

Exemplos de recomendações

Veja a seguinte lista de recomendações de exemplo:

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 obter detalhes do cluster e do serviço, descreva a recomendação. O resultado de um serviço denominado example-webhook no espaço de nomes default é semelhante ao seguinte:

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>

Inspeção do certificado de um serviço

Os servidores de API de extensões e webhooks podem ser suportados por serviços.

Depois de identificar os serviços de back-end relevantes para inspeção, use as seguintes instruções para inspecionar o certificado de cada serviço e verificar que certificados usam o algoritmo SHA-1 e precisam de 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 é semelhante ao seguinte:
```
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 tem o seletor run=nginx e a porta de destino 444.

Nota: quando o elemento TargetPort não está incluído, é o mesmo valor que o campo Port.

Encontre um Pod correspondente ao seletor:

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

O resultado é semelhante ao seguinte:

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

Este resultado indica que o agrupamento correspondente é example-pod.

Configure um encaminhamento de portas do seu kubectlanfitrião local para o pod:

Nota: estes comandos seguintes usam a porta 8888. No entanto, pode escolher uma porta diferente, uma vez que esta porta é 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 resultado mostra um certificado inválido assinado com o algoritmo SHA-1:
```
Certificate:
    Data:
        ...
        Signature Algorithm: sha1WithRSAEncryption
...
    Signature Algorithm: sha1WithRSAEncryption
```
Se o resultado do certificado for semelhante, tem de atualizar o certificado para usar um algoritmo de assinatura compatível. Por exemplo, se usar a API certificate.k8s.io para gerir certificados TLS no seu cluster, pode seguir as instruções para criar um pedido de assinatura de certificado.

Limpe o encaminhamento de porta

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

Execute o seguinte comando para apresentar uma lista dos processos em execução:
```
jobs
```
Consulte o resultado para obter o ID do processo a terminar:
```
[1]+  Running                 kubectl port-forward pods/example-pod 8888:444 &
```
Este exemplo de resultado indica que o ID do processo é 1.
Termine o processo, substituindo PROCESS_ID:
```
kill %PROCESS_ID
```
Veja o seguinte resultado:
```
[1]+  Terminated              kubectl port-forward pods/example 8888:444
```
Este exemplo de saída mostra que o processo foi terminado.

Inspeção do certificado de um back-end de URL

Se o webhook usar um backend url, estabeleça ligação diretamente ao nome de anfitrião especificado no URL. Por exemplo, se o URL for https://example.com:123/foo/bar, use o seguinte comando openssl para mostrar o certificado que o back-end usa:

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 resultado mostra um certificado inválido assinado com o algoritmo SHA-1:

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

Se o resultado do certificado for semelhante, tem de atualizar o certificado para usar um algoritmo de assinatura compatível. Por exemplo, se usar a API certificate.k8s.io para gerir certificados TLS no seu cluster, pode seguir as instruções para criar um pedido de assinatura de certificado.

Mitigue o risco de atualização para a versão 1.29

Depois de identificar os clusters afetados e os respetivos serviços de back-end através de certificados assinados com o algoritmo SHA-1, tem de atualizar os serviços para usar certificados com algoritmos de assinatura compatíveis antes de atualizar os clusters para a versão 1.29.

Os clusters afetados são detetados automaticamente pelo GKE e não vão ser atualizados automaticamente para a versão 1.29 até que os certificados incompatíveis deixem de ser usados ou a versão 1.28 atinja o fim do apoio técnico. Quando a versão 1.28 atingir o fim do apoio técnico, os clusters são atualizados automaticamente para a versão 1.29.

Algoritmos de assinatura compatíveis

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

SHA256WithRSA
SHA384WithRSA
SHA512WithRSA
ECDSAWithSHA256
ECDSAWithSHA384
ECDSAWithSHA512
SHA256WithRSAPSS
SHA384WithRSAPSS
SHA512WithRSAPSS
PureEd25519

Para encontrar algoritmos disponíveis, consulte o ficheiro de origem x509.go e pesquise UnknownSignatureAlgorithm SignatureAlgorithm = iota. Os algoritmos suportados pelo pacote Go x509 estão listados no bloco const com esta linha. Para encontrar algoritmos de assinatura inseguros não suportados, pesquise utilizações de InsecureAlgorithmError no ficheiro.

Recursos

Consulte os seguintes recursos para ver informações adicionais sobre esta alteração:

Notas de lançamento do Go 1.18
Go 1.24 x509sha1 debug switch remoção
Algoritmos compatíveis com Go x509