Use o suplemento Secret Manager com o Google Kubernetes Engine

A integração entre o Secret Manager e o Google Kubernetes Engine (GKE) permite-lhe armazenar dados confidenciais, como palavras-passe e certificados usados por clusters do GKE como segredos no Secret Manager.

Esta página explica como pode usar o suplemento Secret Manager para aceder aos segredos armazenados no Secret Manager como volumes montados em Kubernetes Pods.

Este processo envolve os seguintes passos:

1. Ative o suplemento Secret Manager num cluster do GKE novo ou existente.
2. Configure as aplicações para autenticação na API Secret Manager.
3. Defina que segredos montar em pods do Kubernetes através de um ficheiro YAML SecretProviderClass. O suplemento Secret Manager suporta secrets globais e regionais.
4. Crie um volume onde os segredos vão ser montados. Depois de o volume ser anexado, as aplicações no contentor podem aceder aos dados no sistema de ficheiros do contentor.

O suplemento Secret Manager é derivado do Kubernetes Secrets Store CSI Driver de código aberto e do fornecedor do Google Secret Manager. Se estiver a usar o controlador CSI da loja de segredos de código aberto para aceder a segredos, pode migrar para o suplemento Secret Manager. Para mais informações, consulte o artigo Migre do controlador CSI da Secrets Store existente.

Importante: este documento usa o termo segredo para se referir a dados confidenciais armazenados no Secret Manager e não ao objeto secreto na API GKE.

Vantagens

O suplemento Secret Manager oferece as seguintes vantagens:

• Pode usar uma solução totalmente gerida e suportada para aceder a segredos do Gestor Secreto a partir do GKE sem custos operacionais.
• Não tem de escrever código personalizado para aceder a segredos armazenados no Secret Manager.
• Pode armazenar e gerir todos os seus Secrets de forma centralizada no Secret Manager e aceder seletivamente aos Secrets a partir de pods do GKE através do suplemento Secret Manager. Ao fazê-lo, pode usar funcionalidades oferecidas pelo Secret Manager, como a encriptação CMEK, o controlo de acesso detalhado, a rotação gerida, a gestão do ciclo de vida e os registos de auditoria, juntamente com a utilização de funcionalidades do Kubernetes, como a transmissão de segredos para contentores sob a forma de volumes montados.
• O suplemento Secret Manager é suportado em clusters padrão e clusters do Autopilot.
• O suplemento Secret Manager suporta nós que usam imagens de nós do SO otimizado para contentores ou do Ubuntu.

Limitações

O suplemento Secret Manager tem as seguintes limitações:

• O suplemento Secret Manager não suporta a seguinte funcionalidade que está disponível no controlador CSI da Secrets Store de código aberto:

  • Sincronize como segredo do Kubernetes

• O suplemento Secret Manager não é compatível com nós do Windows Server.

Antes de começar

• Enable the Secret Manager and Google Kubernetes Engine APIs.

  Enable the APIs

• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se tiver instalado anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente.

  Não pode configurar manualmente o suplemento Secret Manager através do SDK Google Cloud nem da Google Cloud consola.

  Nota: para instalações existentes da CLI gcloud, certifique-se de que define as compute/region e compute/zone propriedades. Ao definir localizações predefinidas, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region, --location] must be supplied: Please specify location.

• Certifique-se de que o cluster executa a versão 1.27.14-gke.1042001 do GKE ou posterior com uma imagem de nó do Linux.

• Se usar um cluster padrão do GKE, certifique-se de que o cluster tem a Workload Identity Federation para o GKE ativada. A Workload Identity Federation para o GKE está ativada por predefinição num cluster do Autopilot. Os pods do Kubernetes usam a Workload Identity Federation para o GKE para autenticar na API Secret Manager.

Ative o suplemento Secret Manager

Pode ativar o suplemento Secret Manager em clusters padrão e clusters do Autopilot.

Ative o suplemento Secret Manager num novo cluster do GKE

Para ativar o suplemento do Gestor Secreto na criação do cluster, faça o seguinte:

Consola

1. Na Google Cloud consola, aceda à página Google Kubernetes Engine.

   Aceda ao Google Kubernetes Engine

2. Clique em Criar.

3. Na caixa de diálogo Criar cluster, clique em Configurar.

4. No menu de navegação, na secção Cluster, clique em Segurança.

5. Selecione a caixa de verificação Ativar o Secret Manager.

6. Selecione a caixa de verificação Ativar Workload Identity.

7. Continue a configurar o cluster e, de seguida, clique em Criar.

gcloud

{ Standard cluster}

Para ativar o suplemento Secret Manager num novo cluster padrão, execute o seguinte comando:

Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

• CLUSTER_NAME: o nome do cluster.
• LOCATION: a região do Compute Engine para o cluster, como us-central1.
• VERSION: a versão específica do GKE que quer usar. Certifique-se de que o cluster executa a versão 1.27.14-gke.1042001 ou posterior do GKE. Se o canal de lançamento predefinido não incluir esta versão, use a flag --release-channel para escolher um canal de lançamento que a inclua.
• PROJECT_ID: o ID do seu projeto Google Cloud .

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters create CLUSTER_NAME \
    --enable-secret-manager \
    --location=LOCATION \
    --cluster-version=VERSION \
    --workload-pool=PROJECT_ID.svc.id.goog

Windows (PowerShell)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters create CLUSTER_NAME `
    --enable-secret-manager `
    --location=LOCATION `
    --cluster-version=VERSION `
    --workload-pool=PROJECT_ID.svc.id.goog

Windows (cmd.exe)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters create CLUSTER_NAME ^
    --enable-secret-manager ^
    --location=LOCATION ^
    --cluster-version=VERSION ^
    --workload-pool=PROJECT_ID.svc.id.goog

{ Autopilot cluster}

Para ativar o suplemento Secret Manager num novo cluster do Autopilot, execute o seguinte comando:

Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

• CLUSTER_NAME: o nome do cluster.
• VERSION: a versão específica do GKE que quer usar. Certifique-se de que o cluster executa a versão 1.27.14-gke.1042001 ou posterior do GKE. Para definir uma versão específica, consulte o artigo Defina a versão e o canal de lançamento de um novo cluster do Autopilot.
• LOCATION: a região do Compute Engine para o cluster, como us-central1.

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters create-auto CLUSTER_NAME \
    --enable-secret-manager \
    --cluster-version=VERSION \
    --location=LOCATION

Windows (PowerShell)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters create-auto CLUSTER_NAME `
    --enable-secret-manager `
    --cluster-version=VERSION `
    --location=LOCATION

Windows (cmd.exe)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters create-auto CLUSTER_NAME ^
    --enable-secret-manager ^
    --cluster-version=VERSION ^
    --location=LOCATION

Depois de ativar o suplemento Secret Manager, pode usar o controlador CSI Secrets Store em volumes do Kubernetes com o nome do controlador e do aprovisionador: secrets-store-gke.csi.k8s.io.

Ative o suplemento Secret Manager num cluster do GKE existente

Para ativar o suplemento Secret Manager num cluster existente, faça o seguinte:

Consola

1. Na Google Cloud consola, aceda à página Google Kubernetes Engine.

   Aceda ao Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que quer modificar.

3. Na página de detalhes do cluster, na secção Segurança, clique em Secret Manager.

4. Na caixa de diálogo Editar Secret Manager, selecione a caixa de verificação Ativar Secret Manager.

5. Clique em Guardar alterações.

gcloud

Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

• CLUSTER_NAME: o nome do seu cluster
• LOCATION: a região do Compute Engine para o cluster, como us-central1

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters update CLUSTER_NAME \
    --enable-secret-manager \
    --location=LOCATION \

Windows (PowerShell)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters update CLUSTER_NAME `
    --enable-secret-manager `
    --location=LOCATION `

Windows (cmd.exe)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters update CLUSTER_NAME ^
    --enable-secret-manager ^
    --location=LOCATION ^

Configure a rotação automática de segredos

Pré-visualização

Este produto ou funcionalidade está sujeito aos "Termos de Ofertas de Pré-GA" na secção Termos Gerais do Serviço dos Termos Específicos do Serviço. Os produtos e as funcionalidades pré-GA estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Pode configurar o suplemento Secret Manager para rodar automaticamente os segredos, de modo que os segredos atualizados no Secret Manager após a implementação inicial do pod sejam enviados automaticamente e periodicamente para o pod. A rotação automática de segredos montados permite que as aplicações recebam automaticamente segredos atualizados sem necessitarem de um reinício ou de intervenção manual. Esta funcionalidade garante que as aplicações usam sempre os segredos mais atualizados.

Tenha em atenção o seguinte acerca da configuração da rotação automática de segredos:

• A rotação automática de segredos é uma configuração opcional.
• Pode configurar esta funcionalidade no momento da criação de um novo cluster ou da atualização de um cluster existente.
• A rotação automática de segredos é suportada na versão 1.32.2-gke.1059000 ou posterior do GKE.

Para configurar a rotação automática de segredos, tem de ativar a funcionalidade enable-secret-manager-rotation e configurar o intervalo de rotação definindo secret-manager-rotation-interval.

Por exemplo, para configurar a rotação automática num cluster do GKE existente, use o seguinte comando:

  gcloud beta container clusters update CLUSTER_NAME \
      --enable-secret-manager \
      --location=LOCATION \
      --enable-secret-manager-rotation \
      --secret-manager-rotation-interval=ROTATION_INTERVAL

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster
• LOCATION: a localização do seu cluster, como us-central1
• ROTATION_INTERVAL: o intervalo de rotação em segundos. O intervalo de rotação predefinido é de 120 segundos.

Valide a instalação do suplemento Secret Manager

Para verificar se o suplemento Secret Manager está instalado no cluster do Kubernetes, execute o seguinte comando:

  gcloud container clusters describe CLUSTER_NAME --location LOCATION | grep secretManagerConfig -A 4

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster
• LOCATION: a localização do seu cluster, como us-central1

Configure as aplicações para autenticação na API Secret Manager

O fornecedor do Google Secret Manager usa a identidade da carga de trabalho do pod no qual um segredo é montado quando a autenticação é feita na API Secret Manager. Para permitir que as suas aplicações se autentiquem na API Secret Manager através da Workload Identity Federation para o GKE, siga estes passos:

• Crie uma nova Kubernetes ServiceAccount ou use uma Kubernetes ServiceAccount existente no mesmo espaço de nomes que o Pod no qual quer montar o segredo.

• Crie uma política de autorização da gestão de identidade e de acesso (IAM) para o segredo no Gestor Secreto.

Os pods que usam a ServiceAccount do Kubernetes configurada autenticam-se automaticamente como o identificador principal da IAM que corresponde à ServiceAccount do Kubernetes quando acedem à API Secret Manager.

Crie uma nova conta de serviço do Kubernetes

1. Guarde o seguinte manifesto como service-account.yaml:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: KSA_NAME
     namespace: NAMESPACE
   

   Substitua o seguinte:

   • KSA_NAME: o nome da sua nova ServiceAccount do Kubernetes
   • NAMESPACE: o nome do namespace do Kubernetes para a ServiceAccount

2. Aplique o manifesto:

   kubectl apply -f service-account.yaml
   

3. Crie uma política de autorização IAM que faça referência à nova conta de serviço do Kubernetes e conceda-lhe autorização para aceder ao segredo:

   gcloud secrets add-iam-policy-binding SECRET_NAME \
       --role=roles/secretmanager.secretAccessor \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
   

   Substitua o seguinte:

   • SECRET_NAME: o nome do segredo no Secret Manager
   • PROJECT_NUMBER: o seu Google Cloud número do projeto numérico
   • PROJECT_ID: o ID do projeto do Google Cloud projeto que contém o seu cluster do GKE
   • NAMESPACE: o nome do namespace do Kubernetes para a ServiceAccount
   • KSA_NAME: o nome da sua conta de serviço do Kubernetes existente

Use uma ServiceAccount do Kubernetes existente

Crie uma política de autorização da IAM que faça referência à conta de serviço do Kubernetes existente e conceda-lhe autorização para aceder ao segredo:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --role=roles/secretmanager.secretAccessor \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME

Substitua o seguinte:

• SECRET_NAME: o nome do segredo no Secret Manager
• PROJECT_NUMBER: o seu Google Cloud número do projeto numérico
• PROJECT_ID: o ID do projeto do Google Cloud projeto que contém o seu cluster do GKE
• NAMESPACE: o nome do namespace do Kubernetes para a ServiceAccount
• KSA_NAME: o nome da sua conta de serviço do Kubernetes existente

Defina os segredos a montar

Para especificar os segredos a montar como ficheiros no pod do Kubernetes, crie um manifesto YAML e liste os segredos a montar e o nome do ficheiro como os quer montar.SecretProviderClass Siga estes passos:

1. Guarde o seguinte manifesto como app-secrets.yaml:

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: SECRET_PROVIDER_CLASS_NAME
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION"
           path: "FILENAME.txt"
   

   Substitua o seguinte:

   • SECRET_PROVIDER_CLASS_NAME: o nome do objeto SecretProviderClass.
   • PROJECT_ID: o ID do seu projeto.
   • SECRET_NAME: o nome do segredo.
   • SECRET_VERSION: a versão do secret.
   • FILENAME.txt: o nome do ficheiro onde o valor secreto vai ser montado. Pode criar vários ficheiros através das variáveis resourceName e path.

   Para um segredo regional, resourceName é o caminho completo para o recurso do segredo que inclui a localização do segredo regional. Por exemplo, "projects/PROJECT_ID/locations/LOCATION/secrets/SECRET_NAME/versions/SECRET_VERSION"

2. Aplique o manifesto:

   kubectl apply -f app-secrets.yaml
   

3. Verifique se o objeto SecretProviderClass foi criado:

   kubectl get SecretProviderClasses
   

Configure um volume onde os segredos vão ser montados

1. Guarde a seguinte configuração como my-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
     namespace: NAMESPACE
   spec:
     serviceAccountName: KSA_NAME
     containers:
     - image: IMAGE_NAME
       imagePullPolicy: IfNotPresent
       name: POD_NAME
       resources:
         requests:
           cpu: 100m
       stdin: true
       stdinOnce: true
       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
       tty: true
       volumeMounts:
         - mountPath: "/var/secrets"
           name: mysecret
     volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: SECRET_PROVIDER_CLASS_NAME
   

   Substitua o seguinte:

   • POD_NAME: o nome do pod do Kubernetes onde o segredo está montado
   • NAMESPACE: o nome do namespace do Kubernetes para a ServiceAccount
   • KSA_NAME: a conta de serviço do Kubernetes que configurou no passo Configure as aplicações para autenticar na API Secret Manager
   • IMAGE_NAME: nome da imagem do contentor
   • SECRET_PROVIDER_CLASS_NAME: o nome do objeto SecretProviderClass

2. Apenas em clusters padrão, adicione o seguinte ao campo template.spec para colocar os pods em conjuntos de nós que usam a Workload Identity Federation para o GKE.

   Ignore este passo nos clusters do Autopilot, que rejeitam este nodeSelector, porque todos os nós usam a Workload Identity Federation para o GKE.

   spec:
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
   

3. Aplique a configuração ao cluster.

   kubectl apply -f my-pod.yaml
   

Este passo monta um volume mysecret em /var/secrets através do controlador CSI (secrets-store-gke.csi.k8s.io). Este volume refere-se ao objeto SecretProviderClass, que atua como fornecedor.

Migre a partir do controlador CSI da Secrets Store existente

Se estiver a migrar para o suplemento Secret Manager a partir da sua instalação existente do Secrets Store CSI Driver, atualize o manifesto do pod da seguinte forma:

1. Atualize o nome do SecretProviderClass e do provider, conforme descrito no seguinte manifesto:

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: app-secrets-gke
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/<project_id>/secrets/<secret_name>/versions/<secret_version>"
           path: "good1.txt"
   

2. Atualize o driver e o secretProviderClass para o seu volume do Kubernetes, conforme descrito no seguinte manifesto:

   volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: "app-secrets-gke"
   

Desative o suplemento Secret Manager

Para desativar o suplemento Secret Manager num cluster Standard existente ou num cluster Autopilot, execute o seguinte comando:

Consola

1. Na Google Cloud consola, aceda à página Google Kubernetes Engine.

   Aceda ao Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que quer modificar.

3. Na página de detalhes do cluster, na secção Segurança, clique em Secret Manager.

4. Na caixa de diálogo Editar Gestor de segredos, desmarque a caixa de verificação Ativar Gestor de segredos.

5. Clique em Guardar alterações.

gcloud

Antes de usar qualquer um dos dados de comandos abaixo, faça as seguintes substituições:

• CLUSTER_NAME: o nome do seu cluster
• REGION: a região do Compute Engine para o cluster, como us-central1

Execute o seguinte comando:

Linux, macOS ou Cloud Shell

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters update CLUSTER_NAME \
    --no-enable-secret-manager \
    --region=REGION \

Windows (PowerShell)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters update CLUSTER_NAME `
    --no-enable-secret-manager `
    --region=REGION `

Windows (cmd.exe)

Nota: Certifique-se de que inicializou a CLI Google Cloud com autenticação e um projeto executando gcloud init; ou gcloud auth login e gcloud config set project.

gcloud container clusters update CLUSTER_NAME ^
    --no-enable-secret-manager ^
    --region=REGION ^