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 do Secret Manager para acessar os secrets armazenados no Secret Manager como volumes montados nos pods do Kubernetes.
Esse processo envolve as seguintes etapas:
- Instale o complemento do Secret Manager em um cluster novo ou atual do GKE.
- Configure aplicativos para autenticação na API Secret Manager.
- Defina quais secrets ativar nos pods do Kubernetes usando um arquivo YAML
SecretProviderClass
. - 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 do contêiner.
O complemento do Secret Manager é derivado do driver CSI do Kubernetes Secrets Store de código aberto e do provedor Google Secret Manager. Se você estiver usando o driver CSI do Secrets Store de código aberto para acessar secrets, poderá migrar para o complemento do Secret Manager. Para mais informações, consulte Migrar do driver CSI do armazenamento de Secrets.
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ódigo personalizado para acessar os secrets armazenados no Secret Manager.
- É possível armazenar e gerenciar todos os secrets centralmente no Secret Manager e acessar secrets de maneira seletiva 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 refinado, rotação gerenciada, gerenciamento de ciclo de vida e registros de auditoria, além do uso de recursos do Kubernetes, como a transmissão de secrets para contêineres na forma de volumes ativados.
- O complemento Secret Manager oferece suporte aos clusters padrão e do Autopilot.
- O complemento Secret Manager oferece suporte a implantações
linux/arm64
elinux/amd64
.
Limitações
Esta versão de pré-lançamento do complemento do Secret Manager não é compatível com os seguintes recursos disponíveis no driver CSI de código aberto do Secrets Store:
Antes de começar
-
Ative as APIs Secret Manager and Google Kubernetes Engine.
Se você quiser usar a Google Cloud CLI para esta tarefa, instale e initialize a CLI gcloud. Se você já instalou a CLI gcloud, consiga a versão mais recente executando o comando
gcloud components update
.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 oferece suporte a nós do Windows Server.
Instalar o complemento do Secret Manager
É possível instalar o complemento do Secret Manager nos clusters padrão e no Autopilot. Verifique se a federação de identidade da carga de trabalho para GKE está ativada no cluster padrão. 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 identidade da carga de trabalho para se autenticar 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 de clusters, 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 para o cluster.VERSION
: a versão específica do GKE que você quer usar. Verifique se o cluster executa o GKE versão 1.29 ou posterior. Se o canal de lançamento padrão não incluir essa versão, use a sinalização--release-channel
para escolher um canal de lançamento que inclua essa versão.PROJECT_ID
: o ID do seu projeto do Google Cloud.
Cluster do Autopilot
Para ativar o complemento do 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 clusterVERSION
: a versão específica do GKE que você quer usar. Verifique se o cluster executa o GKE versão 1.29 ou posterior. Se o canal de lançamento padrão não incluir essa versão, use a sinalização--release-channel
para escolher um canal de lançamento que inclua essa versão.LOCATION
: a região do cluster, comous-central1
.
Depois de ativar o complemento do Secret Manager, é
possível usar 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 atual 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 atualLOCATION
: a região do cluster, comous-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 na 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 GKE, siga estas etapas:
- Use uma política do Identity and Access Management (IAM) para vincular uma conta de serviço do IAM a uma conta de serviço do Kubernetes. É possível criar uma nova conta de serviço do Kubernetes ou usar uma atual em qualquer namespace, incluindo a conta de serviço padrão do Kubernetes.
- Use vinculações do IAM para conceder à conta de serviço do IAM acesso aos secrets no Secret Manager.
Os pods que usam a conta de serviço do Kubernetes configurada são autenticados automaticamente como a conta de serviço do IAM ao acessar a API Secret Manager.
Vincular a conta de serviço do Kubernetes à conta de serviço do IAM
Permita que a conta de serviço do Kubernetes represente a conta de serviço do IAM adicionando uma vinculação de política do IAM entre as duas contas de serviço.
Usar uma nova conta de serviço do Kubernetes
Salve o seguinte manifesto como
service-account.yaml
:apiVersion: v1 kind: ServiceAccount metadata: name: KSA_NAME namespace: NAMESPACE annotations: iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
Substitua:
KSA_NAME
: o nome da nova conta de serviço do KubernetesNAMESPACE
: o nome do namespace do Kubernetes para a ServiceAccountGSA_NAME
: o nome da conta de serviço do IAMPROJECT_ID
: o ID do projeto do Google Cloud para sua conta de serviço do IAM
Aplique o manifesto:
kubectl apply -f service-account.yaml
Para vincular a conta de serviço do IAM a uma nova conta de serviço do Kubernetes, execute o seguinte comando:
gcloud iam service-accounts add-iam-policy-binding \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \ GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
Usar uma conta de serviço do Kubernetes
Para vincular a conta de serviço do IAM a uma ServiceAccount atual do Kubernetes, execute o seguinte comando:
gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \
GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
Substitua:
KSA_NAME
: o nome da sua conta de serviço do Kubernetes atualNAMESPACE
: o nome do namespace do Kubernetes para a ServiceAccountGSA_NAME
: o nome da conta de serviço do IAMPROJECT_ID
: o ID do projeto do Google Cloud para sua conta de serviço do IAM
Conceda permissão à conta de serviço do IAM para acessar o secret
Para conceder à conta de serviço permissão para acessar o secret, execute o seguinte comando:
gcloud secrets add-iam-policy-binding SECRET_NAME \
--member=serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
--role=roles/secretmanager.secretAccessor
Substitua:
SECRET_NAME
: o nome do secret no Secret ManagerGSA_NAME
: o nome da conta de serviço do IAMPROJECT_ID
: o ID do projeto do Google Cloud para sua conta de serviço do IAM
Definir quais secrets ativar
Para especificar quais secrets serão ativados como arquivos no pod do Kubernetes, crie um
manifesto YAML SecretProviderClass
e liste os secrets a serem ativados e o nome do arquivo para
montá-los. Siga estas etapas:
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 objetoSecretProviderClass
.PROJECT_ID
: ID do projeto;SECRET_NAME
: o nome do secretSECRET_VERSION
: a versão do secretFILENAME.txt
: o nome do arquivo em que o valor do secret será ativado. É possível criar vários arquivos usando as variáveisresourceName
epath
.
Aplique o manifesto:
kubectl apply -f app-secrets.yaml
Verifique se o objeto
SecretProviderClass
foi criado:kubectl get SecretProviderClasses
Configurar o volume em que os secrets serão montados
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 está 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 objetoSecretProviderClass
.
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 do Secrets Store
Se você estiver migrando para o complemento do Secret Manager da instalação atual do driver CSI do Secrets Store, atualize o manifesto do pod da seguinte maneira:
Atualize o nome do
SecretProviderClass
e doprovider
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"
Atualize o
driver
e osecretProviderClass
do 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 clusterREGION
: a região do cluster, comous-central1
.