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:
- Instale o complemento Secret Manager em um cluster novo ou atual do GKE.
- Configure aplicativos para autenticação na API Secret Manager.
- Defina quais secrets serão montados 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 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).
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
elinux/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:
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, execute o comando
gcloud components update
para conseguir a versão mais recente.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 clusterVERSION
: 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, comous-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 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 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
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.
Aplique o manifesto:
kubectl apply -f service-account.yaml
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 ManagerPROJECT_NUMBER
: o número numérico do seu projeto do Google CloudPROJECT_ID
: o ID do projeto do Google Cloud que contém o cluster do GKENAMESPACE
: 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 ManagerPROJECT_NUMBER
: o número numérico do seu projeto do Google CloudPROJECT_ID
: o ID do projeto do Google Cloud que contém o cluster do GKENAMESPACE
: 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:
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 projetoSECRET_NAME
: o nome do secretSECRET_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áveisresourceName
epath
.
Aplique o manifesto:
kubectl apply -f app-secrets.yaml
Verifique se o objeto
SecretProviderClass
foi criado:kubectl get SecretProviderClasses
Configurar um 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 é ativadoKSA_NAME
: a conta de serviço do Kubernetes que você configurou na etapa Configurar a conta de serviço de identidade da carga de trabalhoIMAGE_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 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:
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
driver
esecretProviderClass
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 clusterREGION
: a região do seu cluster, comous-central1