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:
- Instalar o complemento Secret Manager em um projeto novo ou atual do cluster 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 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 detalhado, 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 é compatível com implantações
linux/arm64
elinux/amd64
.
Limitações
Esta versão de pré-lançamento do Secret Manager não oferece suporte aos seguintes recursos disponíveis no código aberto Driver CSI 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 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
.Verifique se o cluster executa a versão 1.29 ou mais recente do GKE com uma imagem de nó do Linux. O complemento Secret Manager não oferece suporte ao Windows Nós de servidor.
Instalar o complemento do Secret Manager
É possível instalar o complemento Secret Manager nos dois clusters padrão bem como clusters do 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 é ativada por padrão no cluster do Autopilot. Os pods do Kubernetes usam a identidade da carga de trabalho para autenticar-se 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, faça o seguinte: siga estas etapas:
Cluster padrão
Para ativar o complemento Secret Manager em uma nova 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 que você quer usar. Verifique se o cluster executa a versão do GKE versão 1.29 ou mais recente. Se o padrão canal de lançamento não inclua essa versão, use a flag--release-channel
para escolher um de lançamento que tem.PROJECT_ID
: o ID do seu projeto do Google Cloud.
Cluster do Autopilot
Para ativar o complemento Secret Manager 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 que você quer usar. Verifique se o cluster executa a versão do GKE versão 1.29 ou mais recente. Se o canal de lançamento padrão não inclua essa versão, use a flag--release-channel
para escolher um de lançamento que tem.LOCATION
: a região do cluster, comous-central1
.
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
.
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 de 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 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 atual em qualquer namespace, incluindo o conta de serviço 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 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
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
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 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
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 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 lista os secrets a serem montados e o nome do arquivo a ser ativado
montá-las. 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á montado. É possível criar vários arquivos usandoresourceName
epath
. variáveis.
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 é montadoKSA_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). 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:
Atualize o nome da
SecretProviderClass
e daprovider
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"
Atualize
driver
esecretProviderClass
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 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, comous-central1