Aceda a registos privados com certificados de AC privada

Esta página mostra como permitir que as cargas de trabalho executadas no Google Kubernetes Engine (GKE) acedam a registos de imagens privados através da chave pública da autoridade de certificação (AC) que emitiu o certificado para o registo.

Esta página destina-se a especialistas de segurança que gerem o acesso às cargas de trabalho da respetiva organização. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Antes de ler esta página, certifique-se de que conhece o Secret Manager.

Como funciona o acesso a registos privados

Armazena a chave pública da AC usada para emitir certificados para os seus registos privados no Secret Manager e configura que nomes de domínio totalmente qualificados (FQDNs) de registo usam essa chave pública para validação de certificados. O GKE obtém automaticamente a chave e atualiza a configuração do registo do tempo de execução do contentor durante o arranque do nó. Quando implementa uma carga de trabalho que usa uma imagem de contentor do seu registo privado, ocorrem os seguintes passos:

  1. O kubelet no nó tenta extrair a imagem do registo privado.
  2. O registo apresenta um certificado TLS do lado do servidor.
  3. O tempo de execução do contentor valida o certificado do registo criptograficamente e para garantir que o FQDN corresponde ao que especificou.
  4. Se a validação for aprovada, o GKE extrai a imagem e agenda a sua carga de trabalho.

Vantagens

Este método de acesso a registos privados oferece vantagens como as seguintes:

  1. Melhore a fiabilidade da configuração do tempo de execução do contentor: a utilização de métodos como DaemonSets para definir a configuração do containerd adiciona um risco de ocorrência de uma condição de corrida, em que outros DaemonSets podem ser executados antes do seu DaemonSet de configuração.
  2. Reduz a vulnerabilidade a ataques de escalada de privilégios: remove a necessidade de executar DaemonSets privilegiados que modificam a configuração do tempo de execução do contentor.
  3. Reduza os custos gerais de gestão: o Secret Manager permite-lhe armazenar chaves públicas de AC numa localização central; gerir o acesso às chaves através do IAM; e implementar o controlo de versões e as anotações. Para mais informações, consulte a vista geral do produto Secret Manager.
  4. Melhore a capacidade de auditoria: o Cloud Logging já recolhe registos, incluindo quando os certificados são adicionados a um cluster e quando os nós do GKE extraem imagens.

Preços

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

  • GKE
  • Secret Manager
  • Registo: o GKE gera registos de auditoria da atividade do administrador e, se ativados, registos de auditoria de acesso aos dados para esta funcionalidade. Para obter informações sobre os diferentes tipos de registos de auditoria, consulte o artigo Registo de auditoria do GKE.

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

  • Enable the Secret Manager API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  • Já tem de ter um registo privado e certificados de AC privada para aceder ao registo. Este guia não aborda a configuração de um registo privado nem a criação de certificados.

Requisitos

Para usar chaves públicas de AC privada para aceder a registos privados, tem de cumprir os seguintes requisitos:

  • Os seus clusters têm de usar a versão 1.27.3-gke.1700 ou posterior do GKE.
  • Tem de usar uma imagem de nó do SO otimizado para contentores com o containerd, que é a predefinição para todos os clusters do GKE, ou imagens de nó do Ubuntu com o containerd que sejam da versão 1.33.0 ou posterior. As imagens de nós do Windows Server não são suportadas.
  • Os seus pools de nós têm de ter o âmbito de acesso cloud-platform para que os nós transfiram os certificados. Para mais informações, consulte o artigo Âmbitos de acesso predefinidos no GKE. Este documento inclui instruções para definir o âmbito de acesso quando cria um cluster ou um conjunto de nós.

Limitações

Considere as seguintes limitações:

  • Não pode usar certificados de CA privados em imagens de nós do Ubuntu com uma versão anterior a 1.33.0.
  • Não pode usar certificados de AC privados em nós do Windows Server.
  • Cada cluster suporta até cinco certificados de AC privada para registos privados.
  • Cada certificado pode ter até 25 nomes de domínio totalmente qualificados (FQDNs).
  • Cada domínio só pode ser usado num único ficheiro de certificado. No entanto, os pacotes de certificados são suportados.
  • Os certificados têm de estar codificados em PEM.
  • O servidor não roda automaticamente os certificados. Para mais informações, consulte o artigo Rode os certificados da AC privada neste documento.
  • Os FQDNs têm as seguintes limitações:
    • O comprimento máximo do FQDN é de 255 carateres, incluindo carateres especiais.
    • Os NFDQs só podem usar letras, números e travessões (-).
    • O Punycode não é suportado.
    • Os carateres universais não são suportados.

Migre de DaemonSets de configuração

Nos clusters padrão do GKE, pode implementar DaemonSets privilegiados para modificar a configuração do tempo de execução do contentor. Este método modifica diretamente a configuração do containerd em cada nó.

Se usar DaemonSets privilegiados para configurar o acesso a registos privados, considere o seguinte antes de usar este documento:

  • O armazenamento de chaves públicas de ACs privadas no Gestor Secreto apenas configura o acesso a registos privados. Não é suportada outra configuração relacionada com o registo.

  • A ativação desta funcionalidade faz com que o cluster use o modelo de configuração hostpath do CRI do containerd, que é incompatível com o modelo de configuração anterior. Se tiver quaisquer DaemonSets que modifiquem a configuração do anfitrião do containerd, como para registos privados não seguros, espelhos ou proxies, atualize os DaemonSets para usar o modelo hostpath da CRI.

    Para os campos disponíveis no modelo hostpath da CRI, consulte a configuração do registo no repositório do GitHub do containerd.

Quando ativa esta funcionalidade, o GKE aplica o modelo de configuração hostpath da CRI aos nós novos no cluster. Os nós existentes continuam a usar o modelo de configuração anterior até serem recriados durante eventos como atualizações.

Atualize os DaemonSets para suportarem ambos os modelos de configuração

Para reduzir o risco de os seus DaemonSets não funcionarem em nós que suportam um modelo de configuração específico, certifique-se de que os seus DaemonSets usam condicionalmente um modelo de configuração específico, consoante os ficheiros de configuração do containerd no nó. Para ver um exemplo de um DaemonSet que implementa esta lógica condicional, no repositório do GitHub, consulte o manifesto insecure-registry-config.yaml.GoogleCloudPlatform/k8s-node-tools

Armazene as chaves públicas da AC no Secret Manager

Armazene as chaves públicas das suas ACs privadas que emitem os certificados do registo privado como segredos no Secret Manager. Para ver instruções, na documentação do Secret Manager, consulte o artigo Crie um segredo.

Configure o acesso ao Secret Manager a partir do GKE

Para garantir que a conta de serviço do IAM do cluster tem as autorizações necessárias para extrair segredos do Secret Manager, peça ao seu administrador para conceder à conta de serviço do IAM do cluster as seguintes funções do IAM no segredo:

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Estas funções predefinidas contêm as autorizações necessárias para obter segredos do Secret Manager. Para ver as autorizações exatas que são necessárias, expanda a secção Autorizações necessárias:

Autorizações necessárias

São necessárias as seguintes autorizações para obter segredos do Secret Manager:

  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • secretmanager.secrets.get
  • secretmanager.secrets.list
  • secretmanager.versions.get
  • secretmanager.versions.list
  • secretmanager.versions.access

O administrador também pode conceder estas autorizações à conta de serviço do IAM do cluster com funções personalizadas ou outras funções predefinidas.

Se não associou uma conta de serviço do IAM personalizada ao cluster ou ao conjunto de nós, que é a nossa abordagem recomendada, o cluster usa a conta de serviço predefinida do Compute Engine.

Se possível, recomendamos que configure os seus clusters e conjuntos de nós com uma conta de serviço da IAM com privilégios mínimos. Para obter instruções, consulte o artigo Use contas de serviço com o menor número possível de privilégios.

Crie um ficheiro de configuração de tempo de execução

Para ativar a capacidade de usar certificados de AC privada para registos privados no GKE, crie um ficheiro YAML para modificar a configuração do containerd.

  1. Obtenha o número do seu projeto Google Cloud :

    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    O resultado é o número do projeto numérico.

  2. Guarde a seguinte configuração como containerd-configuration.yaml:

    privateRegistryAccessConfig:
  certificateAuthorityDomainConfig:
  - gcpSecretManagerCertificateConfig:
      secretURI: "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION"
    fqdns:
      - "FQDN1"
      - "FQDN2"
  enabled: true

    Substitua o seguinte:

    • PROJECT_NUMBER: o número do projeto que recebeu no passo anterior.
    • SECRET_VERSION: o número da versão do seu segredo no Secret Manager. Opcionalmente, pode usar um alias de versão, mas recomendamos que use o número da versão para evitar a complexidade da gestão.
    • FQDN1, FQDN2: os nomes de domínio totalmente qualificados para os seus registos privados. Também pode usar um endereço IPv4 se tiver sido emitido um certificado para esse endereço, mas não o recomendamos.

Para uma descrição destes campos, consulte privateRegistryAccessConfig na tabela Opções de configuração do containerd disponíveis.

Aplique a configuração do containerd a novos clusters

Esta secção mostra como aplicar um ficheiro de configuração do containerd quando cria um novo cluster do GKE.

Execute o seguinte comando:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --scopes="cloud-platform" \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

Substitua o seguinte:

  • CLUSTER_NAME: o nome do novo cluster.
  • LOCATION: a localização do Compute Engine do seu novo cluster.
  • PATH_TO_CONFIG_FILE: o caminho para o ficheiro de configuração que criou, como ~/containerd-configuration.yaml.

Pode ativar a configuração do registo privado em novos clusters padrão executando o comando gcloud container clusters create com as mesmas opções.

Aplique a configuração do containerd a clusters existentes

Esta secção mostra como aplicar uma configuração do containerd a clusters e nós existentes.

Verifique os âmbitos de acesso

Os clusters existentes têm de ter o âmbito de acesso cloud-platform para usar esta funcionalidade. Esta secção mostra como verificar os âmbitos de acesso e atualizar um cluster existente com um ficheiro de configuração do registo privado novo ou modificado.

Para ver detalhes sobre os âmbitos de acesso predefinidos em novos clusters, consulte o artigo Âmbitos de acesso no GKE.

Verifique os âmbitos de acesso do Autopilot

Execute o seguinte comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=nodeConfig \
    --format='csv[delimiter="\\n",no-heading](oauthScopes)'

Se o seu cluster não tiver o âmbito de acesso https://www.googleapis.com/auth/cloud-platform, crie um novo cluster com este âmbito de acesso.

Verifique os âmbitos de acesso padrão

Para verificar os âmbitos de acesso do cluster Standard, verifique um conjunto de nós:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --flatten=nodeConfig \
    --format='csv[delimiter="\\n",no-heading](oauthScopes)'

Substitua NODE_POOL_NAME pelo nome do conjunto de nós.

Se o seu cluster não tiver o âmbito de acesso https://www.googleapis.com/auth/cloud-platform, crie um novo conjunto de nós com o âmbito de acesso cloud-platform e elimine o conjunto de nós existente.

Atualize o cluster para usar o ficheiro de configuração

Execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

Volte a criar nós em clusters padrão

Se o cluster Standard não usar atualizações automáticas, tem de recriar manualmente os conjuntos de nós para aplicar a nova configuração. Para acionar uma recriação manual do nó, atualize o cluster para a mesma versão do GKE que já usa.

gcloud container clusters upgrade CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION

Substitua VERSION pela mesma versão de patch do GKE que o cluster já usa.

Confirme se o cluster consegue aceder ao registo privado

Execute o seguinte comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten="nodePoolDefaults.nodeConfigDefaults.containerdConfig"

O resultado é semelhante ao seguinte:

    containerdConfig:
      privateRegistryAccessConfig:
        certificateAuthorityDomainConfig:
        - fqdns:
          - 203.0.113.105
          gcpSecretManagerCertificateConfig:
            secretUri: projects/123456789012/secrets/example-secret-name/versions/1
        enabled: true

Implemente uma carga de trabalho que aceda a uma imagem privada

Nesta secção, implementa um pod estático que faz referência a uma imagem do seu registo privado.

  1. Guarde o seguinte manifesto como private-registry-pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: private-registry-pod
spec:
  containers:
  - name: private-image
    image: IMAGE_NAME

    Substitua IMAGE_NAME pelo nome da sua imagem privada.

  2. Implemente o agrupamento:

    kubectl create -f private-registry-pod.yaml

Rode os seus certificados da AC privada

O Secret Manager e o GKE não podem rodar automaticamente os certificados da AC privada no Secret Manager. Para fazer uma rotação de certificado, siga estes passos. Estes passos requerem que recrie os nós existentes duas vezes. Recomendamos que faça rotações de certificados durante o tempo de inatividade agendado para minimizar o impacto das interrupções de cargas de trabalho.

  1. Crie um pacote de certificados com codificação PEM que contenha os certificados antigos e novos.
  2. Adicione o pacote como uma nova versão secreta no Secret Manager.
  3. Atualize o campo secretURI do ficheiro de configuração de tempo de execução com o novo número da versão secreta.
  4. Atualize o cluster para usar a nova versão secreta.

  5. Obtenha a data/hora da operação de atualização:

    gcloud container operations list \
    --filter="operationType ~ UPDATE_CLUSTER AND targetLink ~ CLUSTER_NAME" \
    --sort-by=startTime \
    --limit=1 \
    --format='value(endTime)'

    O resultado é semelhante ao seguinte:

    2024-01-31T09:27:30.864308964Z

  6. Procure nós que foram criados antes de a operação de atualização terminar:

    kubectl get nodes -o json | jq ".items[] |
select(.metadata.creationTimestamp | fromdateiso8601 < $(date -d
CLUSTER_UPDATE_TIMESTAMP +%s)) | .metadata.name"

    Substitua CLUSTER_UPDATE_TIMESTAMP pela data/hora do passo anterior.

    O resultado é uma lista de nomes de nós que não foram recriados com a configuração atualizada. Quando o resultado estiver em branco, avance para o passo seguinte.

  7. Crie uma nova versão do seu segredo no Secret Manager com apenas o novo certificado.

  8. Repita os passos anteriores para atualizar o cluster, obter a data/hora da operação e verificar se os nós usam a nova versão do segredo.

  9. Elimine a versão antiga do segredo do Secret Manager.

Veja registos de auditoria no registo

Esta secção mostra-lhe como usar o registo para verificar se o GKE instalou a versão secreta nos seus nós.

  1. Aceda à página Explorador de registos na Google Cloud consola:

    Aceda ao Explorador de registos

  2. Especifique a seguinte consulta:

    resource.type="gce_instance"
textPayload:"Installed certificate \\\"projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION\\\""

    Se a instalação do certificado for bem-sucedida, o resultado é semelhante ao seguinte:

    "Installed certificate "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION""

    Se a instalação do certificado falhar, o resultado é semelhante ao seguinte:

    "Failed to install certificate "projects/PROJECT_NUMBER/secrets/SECRET_NAME/versions/SECRET_VERSION""

Práticas recomendadas

Recomendamos que use as seguintes práticas recomendadas quando usar esta funcionalidade:

  • Não use aliases para versões do Secret do Secret Manager. Use o número de versão gerado automaticamente para cada versão secreta. Um alias pode apontar para uma versão de certificado diferente ao longo do tempo, o que pode causar complexidades na monitorização das versões específicas que as suas cargas de trabalho usam.
  • Use janelas de manutenção e exclusões para controlar quando o GKE pode recriar os seus nós para aplicar as configurações do containerd atualizadas.
  • Forneça acesso a segredos ao nível do segredo e não ao nível do projeto.

Desative as opções de configuração do containerd

Para remover a configuração personalizada, faça o seguinte:

  1. Atualize o ficheiro de configuração para especificar enabled: false no item de configuração que quer desativar e elimine todos os outros campos no item, como no seguinte exemplo:

    privateRegistryAccessConfig:
  enabled: false
  2. Aplique o ficheiro de configuração atualizado ao cluster. Para obter instruções, consulte o artigo Aplique a configuração do containerd a clusters existentes.

Resolver problemas

Para ver os passos de resolução de problemas, consulte o artigo Resolução de problemas do tempo de execução do contentor.