Usar o complemento Secret Manager com o Google Kubernetes Engine

A integração entre o Secret Manager e o Google Kubernetes Engine (GKE) permite armazenar dados sensíveis, como senhas e certificados usados pelo GKE clusters 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. Ativar o complemento Secret Manager em uma versão nova ou atual do cluster 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 for conectado, os aplicativos no contêiner podem acessar os dados no sistema de arquivos do contêiner.

O complemento Secret Manager é derivado do driver CSI do Kubernetes Secrets Store de código aberto e o provedor do Secret Manager do Google. 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 Migre do driver CSI atual do Secrets Store.

Vantagens

O complemento Secret Manager oferece os seguintes benefícios:

• É possível usar uma solução totalmente gerenciada e com suporte para acessar o Secret Manager de dentro do GKE sem sobrecarga operacional.
• Não é preciso escrever códigos personalizados para acessar secrets armazenados no Secret Manager.
• É possível armazenar e gerenciar todos os secrets de maneira centralizada no Secret Manager e acessar secrets de pods do GKE usando o como o complemento do Secret Manager. Ao fazer isso, você pode usar os recursos oferecidos pela o Secret Manager, como criptografia CMEK, controle de acesso refinado rotação gerenciada, gerenciamento de ciclo de vida e registros de auditoria, além de usar recursos do Kubernetes, como a passagem de secrets para contêineres na forma de em volumes montados.
• O complemento Secret Manager é compatível com clusters padrão e clusters do Autopilot.
• O complemento Secret Manager oferece suporte aos nós que usam o Container-Optimized OS ou imagens de nó do Ubuntu.

Limitações

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

• O complemento Secret Manager não é compatível com os seguintes recursos que estão disponíveis no driver CSI do Secrets Store de código aberto:

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

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

Antes de começar

• Enable the Secret Manager and Google Kubernetes Engine APIs.

  Enable the APIs

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

  Não é possível configurar manualmente o complemento do Secret Manager usando o SDK Google Cloud ou console do Google Cloud.

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

• Se você usa um cluster do GKE Standard, verifique se cluster tem a federação de identidade da carga de trabalho para o GKE ativada. A federação de identidade da carga de trabalho para GKE é ativada por padrão em um cluster do Autopilot. Os pods do Kubernetes usam a federação de identidade da carga de trabalho para o GKE para se autenticarem a API Secret Manager.

Ativar o complemento Secret Manager

É possível ativar o complemento Secret Manager nos dois clusters padrão bem como clusters do Autopilot.

Ativar o complemento Secret Manager em um novo cluster do GKE

Para ativar o complemento do Secret Manager na criação do cluster, faça o seguinte:

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

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

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

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

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

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

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

Ativar o complemento do Secret Manager em um cluster atual do GKE

Para ativar o complemento do Secret Manager em um cluster atual, faça o seguinte:

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

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

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

Verifique a instalação do complemento do Secret Manager

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

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

Substitua:

• CLUSTER_NAME: o nome do cluster.
• LOCATION: o local 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 é montado durante a autenticação no a API Secret Manager. Para permitir que seus aplicativos autentiquem no API Secret Manager usando a federação de identidade da carga de trabalho para GKE, siga estas etapas:

• Crie uma nova conta de serviço do Kubernetes. ou usar uma conta de serviço do Kubernetes no mesmo namespace que o no qual você quer montar o secret.

• 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 se autenticam automaticamente como o identificador principal do IAM que corresponde à ServiceAccount 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. Criar uma política de permissão do IAM que faça referência ao novo Kubernetes ServiceAccount 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.

Usar uma conta de serviço atual do Kubernetes

Criar uma política de permissão do IAM que faça referência ao Kubernetes atual ServiceAccount 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 lista os secrets a serem montados e o nome do arquivo a ser ativado montá-las. 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: o 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á montado. É possível criar vários arquivos usando resourceName e path. variáveis.

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: 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:

   • POD_NAME: o nome do pod do Kubernetes em que o secret é montado
   • NAMESPACE: o nome do namespace do Kubernetes para a conta de serviço.
   • KSA_NAME: a conta de serviço do Kubernetes que você configurou. Na etapa Configurar aplicativos para autenticação na API Secret Manager
   • IMAGE_NAME: nome da imagem do contêiner.
   • SECRET_PROVIDER_CLASS_NAME: o nome do objeto SecretProviderClass.

2. Somente em clusters padrão, adicione o seguinte ao campo template.spec para colocar os pods em pools de nós que usam a federação de identidade da carga de trabalho para o GKE.

   Pule esta etapa nos clusters do Autopilot, que rejeitam esse nodeSeletor porque todos os nós usam a federação de identidade da carga de trabalho para o GKE.

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

3. 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). Este volume faz referência ao objeto SecretProviderClass que atua como provedor.

Migrar do driver CSI atual do Secrets Store

Se você estiver migrando para o complemento Secret Manager do instalação do driver CSI do Secrets Store (link em inglês); atualize o manifesto do pod desta forma:

1. Atualize o nome do SecretProviderClass e da 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 driver e secretProviderClass no 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 Secret Manager cluster Standard ou em um cluster do Autopilot, execute o seguinte comando:

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

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

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