Usar o complemento Secret Manager com o Google Kubernetes Engine

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

A integração entre o Secret Manager e o Google Kubernetes Engine (GKE) permite armazenar dados sensíveis, como senhas e certificados usados pelos clusters do GKE como secrets no Secret Manager.

Nesta página, explicamos como usar o complemento Secret Manager para acessar os secrets armazenados no Secret Manager como volumes montados nos pods do Kubernetes.

Esse processo envolve as seguintes etapas:

1. Instale o complemento Secret Manager em um cluster novo ou atual do GKE.
2. Configure aplicativos para autenticação na API Secret Manager.
3. Defina quais secrets serão montados nos pods do Kubernetes usando um arquivo YAML SecretProviderClass.
4. Crie um volume em que os secrets serão montados. Depois que o volume é anexado, os aplicativos no contêiner podem acessar os dados no sistema de arquivos dele.

O complemento Secret Manager é derivado do driver CSI do Kubernetes Secrets Store de código aberto e do provedor do Google Secret Manager. Se você estiver usando o driver CSI de código aberto do Secrets Store para acessar secrets, será possível migrar para o complemento do Secret Manager. Para mais informações, consulte Migrar do driver CSI atual do Secrets Store (link em inglês).

Importante :neste documento, o termo secret é usado para se referir aos dados sensíveis armazenados no Secret Manager, e não ao objeto Secret na API GKE.

Benefícios

O complemento Secret Manager oferece os seguintes benefícios:

• É possível usar uma solução totalmente gerenciada e com suporte para acessar os secrets do Secret Manager no GKE sem qualquer sobrecarga operacional.
• Não é preciso escrever códigos personalizados para acessar secrets armazenados no Secret Manager.
• É possível armazenar e gerenciar todos os secrets centralmente no Secret Manager e acessá-los seletivamente dos pods do GKE usando o complemento do Secret Manager. Ao fazer isso, é possível usar recursos oferecidos pelo Secret Manager, como criptografia CMEK, controle de acesso detalhado, rotação gerenciada, gerenciamento de ciclo de vida e registros de auditoria, além de usar recursos do Kubernetes, como a transmissão de secrets para contêineres na forma de volumes montados.
• O complemento Secret Manager é compatível com clusters padrão e clusters do Autopilot.
• O complemento Secret Manager é compatível com implantações linux/arm64 e linux/amd64.

Limitações

Esta versão de pré-lançamento do complemento Secret Manager não oferece suporte aos seguintes recursos disponíveis no driver CSI de código aberto da Secrets Store:

• Rotação automática de secrets
• Sincronizar como secret do Kubernetes

Antes de começar

• Ative as APIs Secret Manager and Google Kubernetes Engine.

  Ative as APIs

• Se você quiser usar a Google Cloud CLI para esta tarefa, instale e initialize a CLI gcloud. Se você já instalou a CLI gcloud, execute o comando gcloud components update para conseguir a versão mais recente.

  Observação :para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud como os seguintes: One of [--zone, --region, --location] must be supplied: Please specify location.

• Verifique se o cluster executa o GKE versão 1.29 ou posterior com uma imagem de nó do Linux. O complemento Secret Manager não é compatível com nós do Windows Server.

Instalar o complemento do Secret Manager

É possível instalar o complemento Secret Manager nos clusters Standard e no Autopilot. Verifique se a federação de identidade da carga de trabalho para o GKE está ativada no cluster padrão. A federação de identidade da carga de trabalho para o GKE está ativada por padrão em um cluster do Autopilot. Os pods do Kubernetes usam a identidade da carga de trabalho para autenticação na API Secret Manager.

Instalar o complemento do Secret Manager em um novo cluster do GKE

Para instalar o complemento do Secret Manager na criação do cluster, siga estas etapas:

Cluster padrão

• Para ativar o complemento do Secret Manager em um novo cluster padrão, execute o seguinte comando:

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

  Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: a região ou zona do Compute Engine do cluster.
  • VERSION: a versão específica do GKE que você quer usar. Verifique se o cluster executa a versão 1.29 ou mais recente do GKE. Se o canal de lançamento padrão não incluir essa versão, use a flag --release-channel para escolher um canal que inclua essa versão.
  • PROJECT_ID: o ID do seu projeto do Google Cloud.

Cluster do Autopilot

• Para ativar o complemento Secret Manager em um novo cluster do Autopilot, execute o seguinte comando:

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

  Substitua:

  • CLUSTER_NAME: o nome do cluster
  • VERSION: a versão específica do GKE que você quer usar. Verifique se o cluster executa a versão 1.29 ou mais recente do GKE. Se o canal de lançamento padrão não incluir essa versão, use a flag --release-channel para escolher um canal que inclua essa versão.
  • LOCATION: a região do cluster, como us-central1.

Depois de ativar o complemento Secret Manager, use o driver CSI do Secrets Store nos volumes do Kubernetes usando o nome do provisionador e do driver: secrets-store-gke.csi.k8s.io.

Instalar o complemento do Secret Manager em um cluster do GKE

Para ativar o complemento do Secret Manager em um cluster atual, execute o seguinte comando:

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

Substitua:

• CLUSTER_NAME: o nome do cluster atual
• LOCATION: a região do cluster, como us-central1.

Configurar aplicativos para autenticação na API Secret Manager

O provedor do Secret Manager do Google usa a identidade da carga de trabalho do pod em que um secret está ativado ao autenticar para a API Secret Manager. Para permitir que seus aplicativos sejam autenticados na API Secret Manager usando a federação de identidade da carga de trabalho para o GKE, siga estas etapas:

• Crie uma nova Kubernetes ServiceAccount ou use uma atual do Kubernetes em qualquer namespace, incluindo a padrão do Kubernetes.

• Criar uma política de permissão do Identity and Access Management (IAM) para o secret no Secret Manager.

Os pods que usam a conta de serviço do Kubernetes configurada são autenticados automaticamente como o identificador principal do IAM que corresponde à conta de serviço do Kubernetes ao acessar a API Secret Manager.

Criar uma nova conta de serviço do Kubernetes

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

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

   Substitua:

   • KSA_NAME: o nome da nova conta de serviço do Kubernetes.
   • NAMESPACE: o nome do namespace do Kubernetes para a conta de serviço.

2. Aplique o manifesto:

   kubectl apply -f service-account.yaml
   

3. Crie uma política de permissão do IAM que faça referência ao novo ServiceAccount do Kubernetes e conceda a ele permissão para acessar o secret:

   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:

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

Usar uma conta de serviço atual do Kubernetes

Crie uma política de permissão do IAM que faça referência à conta de serviço atual do Kubernetes e conceda a ela permissão para acessar o secret:

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:

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

Definir quais secrets ativar

Para especificar quais secrets ativar como arquivos no pod do Kubernetes, crie um manifesto YAML SecretProviderClass e liste os secrets a serem ativados e o nome do arquivo para ativá-los. Siga estas etapas:

1. Salve 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:

   • SECRET_PROVIDER_CLASS_NAME: o nome do objeto SecretProviderClass.
   • PROJECT_ID: ID do projeto
   • SECRET_NAME: o nome do secret
   • SECRET_VERSION: a versão do secret.
   • FILENAME.txt: o nome do arquivo em que o valor do secret será ativado. É possível criar vários arquivos usando as variáveis resourceName e path.

2. Aplique o manifesto:

   kubectl apply -f app-secrets.yaml
   

3. Verifique se o objeto SecretProviderClass foi criado:

   kubectl get SecretProviderClasses
   

Configurar um volume em que os secrets serão montados

1. Salve a configuração a seguir como my-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
     namespace: default
   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:

   • POD_NAME: o nome do pod do Kubernetes em que o secret é ativado
   • KSA_NAME: a conta de serviço do Kubernetes que você configurou na etapa Configurar a conta de serviço de identidade da carga de trabalho
   • IMAGE_NAME: nome da imagem do contêiner.
   • SECRET_PROVIDER_CLASS_NAME: o nome do objeto SecretProviderClass.

2. Aplique a configuração a seu cluster.

   kubectl apply -f my-pod.yaml
   

Esta etapa monta um volume mysecret em /var/secrets usando o driver CSI (secrets-store-gke.csi.k8s.io). Esse volume faz referência ao objeto SecretProviderClass que atua como o provedor.

Migrar do driver CSI atual do Secrets Store

Se você estiver migrando para o complemento Secret Manager da instalação atual do driver CSI do Secrets Store (link em inglês), atualize o manifesto do pod da seguinte maneira:

1. Atualize o nome do SecretProviderClass e do provider conforme descrito no manifesto a seguir:

   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 driver e secretProviderClass para o volume do Kubernetes conforme descrito no manifesto a seguir:

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

Desativar o complemento Secret Manager

Para desativar o complemento do Secret Manager em um cluster padrão ou do Autopilot, execute o seguinte comando:

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

Substitua:

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