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 em pods do Kubernetes.
Esse processo envolve as seguintes etapas:
- Ative o complemento Secret Manager em um cluster do GKE novo ou atual.
- Configure os aplicativos para autenticação na API Secret Manager.
- Defina quais secrets serão montados em pods do Kubernetes usando um arquivo YAML
SecretProviderClass. O complemento do Secret Manager é compatível com secrets globais e regionais. - 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 do 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 da Secrets Store de código aberto para acessar secrets, migre para o complemento do Secret Manager. Para mais informações, consulte Migrar do driver CSI da Secrets Store atual.
Vantagens
O complemento Secret Manager oferece os seguintes benefícios:
- É possível usar uma solução totalmente gerenciada e compatível para acessar secrets do Secret Manager no GKE sem sobrecarga operacional.
- Não é necessário escrever código personalizado para acessar os secrets armazenados no Secret Manager.
- É possível armazenar e gerenciar todos os seus secrets de forma centralizada no Secret Manager e acessar seletivamente os secrets dos pods do GKE usando o complemento do Secret Manager. Ao fazer isso, você pode 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 de usar recursos do Kubernetes, como transmissão de secrets para contêineres na forma de volumes montados.
- O complemento Secret Manager é compatível com clusters Standard e do Autopilot.
- O complemento Secret Manager é compatível com nós que usam imagens de nó do Container-Optimized OS ou do Ubuntu.
Limitações
O complemento Secret Manager tem as seguintes limitações:
O complemento Secret Manager não é compatível com o recurso Sincronizar como Secret do Kubernetes, disponível no driver CSI da Secrets Store de código aberto. Se você quiser sincronizar secrets armazenados no Secret Manager com secrets do Kubernetes, use o recurso integrado de sincronização de secrets do Secret Manager. Para mais informações, consulte Sincronizar secrets com secrets do Kubernetes.
O complemento do Secret Manager não é compatível com nós do Windows Server.
Antes de começar
-
Ative as APIs Secret Manager e Google Kubernetes Engine.
Funções necessárias para ativar APIs
Para ativar APIs, você precisa da permissão
serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão com o papel de Proprietário (roles/owner). Caso contrário, é possível receber essa permissão com o papel de Administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis. Se você quiser usar a Google Cloud CLI para essa tarefa, instale e inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando
gcloud components update.Não é possível configurar manualmente o complemento do Secret Manager usando o SDK Google Cloud ou o console Google Cloud .
Verifique se o cluster executa o GKE versão 1.27.14-gke.1042001 ou posterior com uma imagem de nó do Linux.
Se você usa um cluster do GKE Standard, verifique se ele tem a Federação de Identidade da Carga de Trabalho para 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 GKE para autenticar a API Secret Manager.
Ativar o complemento Secret Manager
É possível ativar o complemento do Secret Manager em clusters Standard e Autopilot.
Ativar o complemento do Secret Manager em um novo cluster do GKE
Para ativar o complemento do Secret Manager na criação do cluster, faça o seguinte:
Console
-
No console do Google Cloud , acesse a página Google Kubernetes Engine.
Clique em add_boxCriar.
Na caixa de diálogo Criar cluster, clique em Configurar.
No menu de navegação, na seção Cluster, clique em Segurança.
Marque a caixa de seleção Ativar o Secret Manager.
Marque a caixa de seleção Ativar identidade de carga de trabalho.
Continue configurando o cluster e clique em Criar.
gcloud
{ Standard cluster}
Para ativar o complemento do Secret Manager em um novo cluster Standard, execute o seguinte comando:
Antes de usar os dados do comando abaixo, faça estas substituições:
- CLUSTER_NAME: o nome do cluster.
- LOCATION: a região do Compute Engine para o cluster, como
us-central1. - VERSION: a versão específica do GKE que
você quer usar. Verifique se o cluster executa o GKE versão
1.27.14-gke.1042001 ou posterior. Se o canal de lançamento padrão não incluir essa versão, use a flag
--release-channelpara escolher um canal de lançamento que inclua. - PROJECT_ID: o ID do seu projeto do Google Cloud .
Execute o seguinte comando:
Linux, macOS ou Cloud Shell
gcloud container clusters create CLUSTER_NAME \ --enable-secret-manager \ --location=LOCATION \ --cluster-version=VERSION \ --workload-pool=PROJECT_ID.svc.id.goog
Windows (PowerShell)
gcloud container clusters create CLUSTER_NAME ` --enable-secret-manager ` --location=LOCATION ` --cluster-version=VERSION ` --workload-pool=PROJECT_ID.svc.id.goog
Windows (cmd.exe)
gcloud container clusters create CLUSTER_NAME ^ --enable-secret-manager ^ --location=LOCATION ^ --cluster-version=VERSION ^ --workload-pool=PROJECT_ID.svc.id.goog
{ Autopilot cluster}
Para ativar o complemento do Secret Manager em um novo cluster do Autopilot, execute o seguinte comando:
Antes de usar os dados do comando abaixo, faça estas substituições:
- CLUSTER_NAME: o nome do cluster.
- VERSION: a versão específica do GKE que você quer usar. Verifique se o cluster executa o GKE versão 1.27.14-gke.1042001 ou posterior. Para definir uma versão específica, consulte Definir a versão e o canal de lançamento de um novo cluster do Autopilot.
- LOCATION: a região do Compute Engine para o cluster, como
us-central1.
Execute o seguinte comando:
Linux, macOS ou Cloud Shell
gcloud container clusters create-auto CLUSTER_NAME \ --enable-secret-manager \ --cluster-version=VERSION \ --location=LOCATION
Windows (PowerShell)
gcloud container clusters create-auto CLUSTER_NAME ` --enable-secret-manager ` --cluster-version=VERSION ` --location=LOCATION
Windows (cmd.exe)
gcloud container clusters create-auto CLUSTER_NAME ^ --enable-secret-manager ^ --cluster-version=VERSION ^ --location=LOCATION
Depois de ativar o complemento do Secret Manager, você
poderá usar o driver CSI do Secrets Store em volumes do Kubernetes usando o nome do driver
e do provisionador: secrets-store-gke.csi.k8s.io.
Ativar o complemento do Secret Manager em um cluster do GKE
Para ativar o complemento do Secret Manager em um cluster atual, faça o seguinte:
Console
-
No console do Google Cloud , acesse a página Google Kubernetes Engine.
Na lista de clusters, clique no nome do cluster que você quer modificar.
Na página de detalhes do cluster, na seção Segurança, clique em Secret Manager.
Na caixa de diálogo Editar o Secret Manager, marque a caixa de seleção Ativar o Secret Manager.
Clique em Salvar alterações.
gcloud
Antes de usar os dados do comando abaixo, faça estas substituições:
- CLUSTER_NAME: o nome do cluster.
- LOCATION: a região do Compute Engine para o cluster, como
us-central1
Execute o seguinte comando:
Linux, macOS ou Cloud Shell
gcloud container clusters update CLUSTER_NAME \ --enable-secret-manager \ --location=LOCATION \
Windows (PowerShell)
gcloud container clusters update CLUSTER_NAME ` --enable-secret-manager ` --location=LOCATION `
Windows (cmd.exe)
gcloud container clusters update CLUSTER_NAME ^ --enable-secret-manager ^ --location=LOCATION ^
Verificar a instalação do complemento do Secret Manager
Para verificar se o complemento do Secret Manager está instalado no cluster do Kubernetes, execute o seguinte comando:
gcloud container clusters describe CLUSTER_NAME --location LOCATION | grep secretManagerConfig -A 4
Substitua:
CLUSTER_NAME: o nome do cluster.LOCATION: o local do cluster, comous-central1.
Configurar a rotação automática de secrets
É possível configurar o complemento do Secret Manager para fazer a rotação automática de secrets. Assim, os secrets atualizados no Secret Manager após a implantação inicial do pod são enviados automaticamente e periodicamente para o pod. A rotação automática de secrets montados permite que os aplicativos recebam secrets atualizados automaticamente sem exigir uma reinicialização ou intervenção manual. Esse recurso garante que os aplicativos sempre usem os segredos mais atualizados.
Observe o seguinte sobre a configuração da rotação automática de secrets:
- A rotação automática de secrets é uma configuração opcional.
- É possível configurar esse recurso ao criar um cluster ou atualizar um cluster existente.
- É possível configurar a frequência de rotação automática especificando o intervalo e a unidade de intervalo de rotação.
- A rotação automática de secrets é compatível com a versão 1.32.2-gke.1059000 ou mais recente do GKE.
Para configurar a rotação automática de secrets, ative o recurso
enable-secret-manager-rotation e configure o intervalo de rotação definindo
secret-manager-rotation-interval.
Configurar a rotação automática de secrets em um novo cluster do GKE
Para configurar a rotação automática de secrets na criação do cluster, faça o seguinte:
Console
{ Autopilot cluster}
-
No console do Google Cloud , acesse a página Criar um cluster do Autopilot.
No menu de navegação, na seção Configurações avançadas, clique em Segurança.
Marque a caixa de seleção Ativar o Secret Manager.
Marque a caixa de seleção Configurar rotação automática.
Especifique o Intervalo de rotação e a Unidade do intervalo de rotação.
Continue configurando o cluster e clique em Criar.
{ Standard cluster}
-
No console do Google Cloud , acesse a página Criar um cluster do Kubernetes.
No menu de navegação, na seção Cluster, clique em Segurança.
Marque a caixa de seleção Ativar o Secret Manager.
Marque a caixa de seleção Configurar rotação automática.
Especifique o Intervalo de rotação e a Unidade do intervalo de rotação.
Continue configurando o cluster e clique em Criar.
gcloud
{ Autopilot cluster}
Antes de usar os dados do comando abaixo, faça estas substituições:
- CLUSTER_NAME: o nome do cluster.
- VERSION: a versão específica do GKE que
você quer usar. Verifique se o cluster executa o GKE versão
1.27.14-gke.1042001 ou posterior. Se o canal de lançamento padrão não incluir essa versão, use a flag
--release-channelpara escolher um canal de lançamento que inclua. - LOCATION: o local do cluster, como
us-central1. - ROTATION_INTERVAL: o intervalo de rotação em segundos. O valor precisa ser um número inteiro positivo seguido pelo sufixo
s. O valor mínimo permitido é120s. Por exemplo, para definir o intervalo como 5 minutos, use300s.
Execute o seguinte comando:
Linux, macOS ou Cloud Shell
gcloud container clusters create CLUSTER_NAME \ --cluster-version=VERSION \ --location=LOCATION \ --enable-secret-manager \ --enable-secret-manager-rotation \ --secret-manager-rotation-interval=ROTATION_INTERVAL
Windows (PowerShell)
gcloud container clusters create CLUSTER_NAME ` --cluster-version=VERSION ` --location=LOCATION ` --enable-secret-manager ` --enable-secret-manager-rotation ` --secret-manager-rotation-interval=ROTATION_INTERVAL
Windows (cmd.exe)
gcloud container clusters create CLUSTER_NAME ^ --cluster-version=VERSION ^ --location=LOCATION ^ --enable-secret-manager ^ --enable-secret-manager-rotation ^ --secret-manager-rotation-interval=ROTATION_INTERVAL
{ Standard cluster}
Antes de usar os dados do comando abaixo, faça estas substituições:
- CLUSTER_NAME: o nome do cluster.
- LOCATION: o local do cluster, como
us-central1. - VERSION: a versão específica do GKE que
você quer usar. Verifique se o cluster executa o GKE versão
1.27.14-gke.1042001 ou posterior. Se o canal de lançamento padrão não incluir essa versão, use a flag
--release-channelpara escolher um canal de lançamento que inclua. - PROJECT_ID: ID do projeto Google Cloud
- ROTATION_INTERVAL: o intervalo de rotação em segundos. O valor precisa ser um número inteiro positivo seguido pelo sufixo
s. O valor mínimo permitido é120s. Por exemplo, para definir o intervalo como 5 minutos, use300s.
Execute o seguinte comando:
Linux, macOS ou Cloud Shell
gcloud container clusters create CLUSTER_NAME \ --location=LOCATION \ --cluster-version=VERSION \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-secret-manager \ --enable-secret-manager-rotation \ --secret-manager-rotation-interval=ROTATION_INTERVAL
Windows (PowerShell)
gcloud container clusters create CLUSTER_NAME ` --location=LOCATION ` --cluster-version=VERSION ` --workload-pool=PROJECT_ID.svc.id.goog ` --enable-secret-manager ` --enable-secret-manager-rotation ` --secret-manager-rotation-interval=ROTATION_INTERVAL
Windows (cmd.exe)
gcloud container clusters create CLUSTER_NAME ^ --location=LOCATION ^ --cluster-version=VERSION ^ --workload-pool=PROJECT_ID.svc.id.goog ^ --enable-secret-manager ^ --enable-secret-manager-rotation ^ --secret-manager-rotation-interval=ROTATION_INTERVAL
Configurar a rotação automática de secrets em um cluster do GKE
Para configurar a rotação automática de secrets em um cluster do GKE, faça o seguinte:
Console
-
No console do Google Cloud , acesse a página de clusters do Kubernetes.
Na lista de clusters, clique no nome do cluster que você quer modificar.
Na página de detalhes do cluster, clique em Editar.
Na seção Segurança, clique em Secret Manager.
Na caixa de diálogo Editar o Secret Manager, marque a caixa de seleção Ativar o Secret Manager.
Marque a caixa de seleção Configurar rotação automática.
Especifique o Intervalo de rotação e a Unidade do intervalo de rotação.
Clique em Salvar alterações.
gcloud
Antes de usar os dados do comando abaixo, faça estas substituições:
- CLUSTER_NAME: o nome do cluster.
- LOCATION: o local
do cluster, como
us-central1 - ROTATION_INTERVAL: o intervalo de rotação em segundos. O valor precisa ser um número inteiro positivo seguido pelo sufixo
s. O valor mínimo permitido é120s. Por exemplo, para definir o intervalo como 5 minutos, use300s.
Execute o seguinte comando:
Linux, macOS ou Cloud Shell
gcloud container clusters update CLUSTER_NAME \ --enable-secret-manager \ --location=LOCATION \ --enable-secret-manager-rotation \ --secret-manager-rotation-interval=ROTATION_INTERVAL
Windows (PowerShell)
gcloud container clusters update CLUSTER_NAME ` --enable-secret-manager ` --location=LOCATION ` --enable-secret-manager-rotation ` --secret-manager-rotation-interval=ROTATION_INTERVAL
Windows (cmd.exe)
gcloud container clusters update CLUSTER_NAME ^ --enable-secret-manager ^ --location=LOCATION ^ --enable-secret-manager-rotation ^ --secret-manager-rotation-interval=ROTATION_INTERVAL
Configurar aplicativos para autenticação na API Secret Manager
O provedor do Google Secret Manager usa a identidade da carga de trabalho do pod em que um secret é montado ao fazer a autenticação na API Secret Manager. Para permitir que seus aplicativos se autentiquem na API Secret Manager usando a Federação de Identidade da Carga de Trabalho para GKE, siga estas etapas:
Crie uma conta de serviço do Kubernetes ou use uma conta de serviço do Kubernetes no mesmo namespace do pod em que você quer ativar o secret.
Crie uma política de permissão do Identity and Access Management (IAM) para o secret no Secret Manager.
Os pods que usam a ServiceAccount do Kubernetes configurada são autenticados automaticamente como o identificador principal do IAM correspondente à ServiceAccount do Kubernetes ao acessar a API Secret Manager.
Criar uma ServiceAccount do Kubernetes
Salve o seguinte manifesto como
service-account.yaml:apiVersion: v1 kind: ServiceAccount metadata: name: KSA_NAME namespace: NAMESPACESubstitua:
KSA_NAME: o nome da nova ServiceAccount do KubernetesNAMESPACE: o nome do namespace do Kubernetes da ServiceAccount
Aplique o manifesto:
kubectl apply -f service-account.yamlCrie uma política de permissão do IAM que faça referência à nova ServiceAccount 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_NAMESubstitua:
SECRET_NAME: o nome do secret no Secret ManagerPROJECT_NUMBER: o número numérico do projeto Google CloudPROJECT_ID: o ID do projeto do Google Cloud que contém seu cluster do GKENAMESPACE: o nome do namespace do Kubernetes da ServiceAccountKSA_NAME: o nome da sua ServiceAccount do Kubernetes
Usar uma ServiceAccount do Kubernetes
Crie uma política de permissão do IAM que faça referência à ServiceAccount 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 projeto Google CloudPROJECT_ID: o ID do projeto do Google Cloud que contém seu cluster do GKENAMESPACE: o nome do namespace do Kubernetes da ServiceAccountKSA_NAME: o nome da sua ServiceAccount do Kubernetes
Definir quais secrets serão montados
Para especificar quais secrets montar como arquivos no pod do Kubernetes, crie um
manifesto YAML SecretProviderClass e liste os secrets a serem montados 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: o ID do projeto.SECRET_NAME: o nome do secret.SECRET_VERSION: a versão do secret. A versão do secret precisa estar na mesma região que o cluster.FILENAME.txt: o nome do arquivo em que o valor do secret será montado. É possível criar vários arquivos usando as variáveisresourceNameepath.
Para um secret regional,
resourceNameé o caminho completo para o recurso de secret que inclui o local do secret regional. Por exemplo, "projects/PROJECT_ID/locations/LOCATION/secrets/SECRET_NAME/versions/SECRET_VERSION"Aplique o manifesto:
kubectl apply -f app-secrets.yaml -n NAMESPACESubstitua
NAMESPACEpelo nome do namespace do Kubernetes para a conta de serviço.Verifique se o objeto
SecretProviderClassfoi criado:kubectl get SecretProviderClasses -n NAMESPACE
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: 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_NAMESubstitua:
POD_NAME: o nome do pod do Kubernetes em que o secret está montadoNAMESPACE: o nome do namespace do Kubernetes da ServiceAccountKSA_NAME: a conta de serviço do Kubernetes que você configurou na etapa Configurar aplicativos para autenticar na API Secret ManagerIMAGE_NAME: nome da imagem do contêiner.SECRET_PROVIDER_CLASS_NAME: o nome do objetoSecretProviderClass
Somente em clusters padrão, adicione o seguinte ao campo
template.specpara 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"Aplique a configuração ao 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 provedor.
Migrar do driver CSI de armazenamento de secrets do Kubernetes de código aberto
Se você usa o driver CSI do Kubernetes Secrets Store de código aberto e o provedor do Google Secret Manager, é possível migrar suas cargas de trabalho para o complemento gerenciado do Secret Manager.
O complemento gerenciado e o driver de código aberto podem ser executados simultaneamente no mesmo cluster. Com esse recurso, é possível migrar aplicativos e namespaces individuais de forma incremental sem tempo de inatividade do cluster.
Para migrar para o complemento Secret Manager, siga estas etapas:
- Ative o complemento Secret Manager no seu cluster
- Criar manifestos
SecretProviderClass - Atualizar manifestos de carga de trabalho
- Verificar a migração
- Limpar recursos de código aberto antigos
Etapa 1: ativar o complemento Secret Manager no cluster
Ative o complemento Secret Manager no cluster do GKE atual:
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--enable-secret-manager \
[--enable-secret-manager-rotation \
--secret-manager-rotation-interval=ROTATION_INTERVAL]
Substitua:
- CLUSTER_NAME: o nome do cluster.
- LOCATION: o local
do cluster, como
us-central1. - (Opcional) ROTATION_INTERVAL: a frequência com que os secrets montados são atualizados automaticamente, como
120sou3600s. O valor mínimo permitido é60s, e o padrão é120s.
Etapa 2: criar manifestos SecretProviderClass
Crie um manifesto SecretProviderClass com provider: gke para cada
aplicativo. Recomendamos anexar -gke ao nome do recurso para que os recursos SecretProviderClass antigos e novos possam coexistir durante as atualizações rotativas.
Salve o seguinte manifesto como
secret-provider-class-gke.yaml:apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: SECRET_PROVIDER_CLASS_NAME-gke # Append -gke to coexist with existing SPC namespace: NAMESPACE spec: provider: gke # Changed from 'gcp' parameters: secrets: | - resourceName: "projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION" path: "FILENAME.txt"Substitua:
- SECRET_PROVIDER_CLASS_NAME-gke: o nome do novo
recurso
SecretProviderClass. - NAMESPACE: o namespace do Kubernetes em que sua carga de trabalho é executada
- PROJECT_ID: o ID do projeto do Google Cloud
- SECRET_NAME: o nome do secret no Secret Manager
- SECRET_VERSION: a versão do secret, como
latestou1 - FILENAME.txt: o nome do arquivo em que o valor do secret é montado
Para segredos regionais, especifique o caminho completo do recurso, incluindo o local:
"projects/PROJECT_ID/locations/LOCATION/secrets/SECRET_NAME/versions/SECRET_VERSION"- SECRET_PROVIDER_CLASS_NAME-gke: o nome do novo
recurso
Aplique o novo manifesto
SecretProviderClass:kubectl apply -f secret-provider-class-gke.yaml
Etapa 3: atualizar os manifestos de carga de trabalho
Atualize os manifestos do pod ou da implantação para usar o driver gerenciado (secrets-store-gke.csi.k8s.io) e referenciar o novo nome SecretProviderClass.
Atualize a seção
volumesdo manifesto da carga de trabalho (comodeployment.yaml):spec: containers: - name: CONTAINER_NAME image: IMAGE_NAME volumeMounts: - name: secrets-volume mountPath: "/var/secrets" readOnly: true volumes: - name: secrets-volume csi: driver: secrets-store-gke.csi.k8s.io # Changed from 'secrets-store.csi.k8s.io' readOnly: true volumeAttributes: secretProviderClass: SECRET_PROVIDER_CLASS_NAME-gke # Reference new SPC nameSubstitua:
- CONTAINER_NAME: o nome do contêiner na sua carga de trabalho
- IMAGE_NAME: o nome da imagem do contêiner
- SECRET_PROVIDER_CLASS_NAME-gke: o nome do novo
recurso
SecretProviderClass.
Aplique o manifesto de carga de trabalho atualizado para acionar uma implantação gradual:
kubectl apply -f deployment.yaml
Etapa 4: verificar a migração
Verifique se as cargas de trabalho estão usando o complemento gerenciado:
Verifique se os pods foram lançados e atingiram o estado
Running:kubectl get pods -n NAMESPACESubstitua NAMESPACE pelo namespace do Kubernetes em que sua carga de trabalho é executada.
Verifique se os secrets estão ativados e acessíveis corretamente no contêiner:
kubectl exec -it POD_NAME -n NAMESPACE -- cat /var/secrets/FILENAME.txtSubstitua:
- POD_NAME: o nome do seu pod do Kubernetes
- NAMESPACE: o namespace do Kubernetes em que sua carga de trabalho é executada
- FILENAME.txt: o nome do arquivo de secret montado configurado no
seu
SecretProviderClass
(Opcional) Se você ativou a rotação automática, verifique as atualizações de secrets:
- Adicione uma nova versão do secret no Secret Manager.
- Aguarde o intervalo de rotação configurado, como 120 segundos.
Inspecione o arquivo de secret montado novamente dentro do pod para verificar se o conteúdo foi atualizado sem reiniciar o pod:
kubectl exec -it POD_NAME -n NAMESPACE -- cat /var/secrets/FILENAME.txt
Etapa 5: limpar recursos de código aberto antigos
Exclua os recursos antigos do
SecretProviderClass:kubectl delete secretproviderclass OLD_SECRET_PROVIDER_CLASS_NAME -n NAMESPACESubstitua:
- OLD_SECRET_PROVIDER_CLASS_NAME: o nome do recurso
SecretProviderClasslegado, comomy-app-secrets - NAMESPACE: o namespace do Kubernetes em que sua carga de trabalho é executada
- OLD_SECRET_PROVIDER_CLASS_NAME: o nome do recurso
Se você implantou o plug-in de provedor do Google Secret Manager de código aberto usando um manifesto, exclua o DaemonSet:
kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp/main/deploy/provider-gcp-plugin.yamlSe você instalou o driver CSI do Secrets Store de código aberto usando o Helm, desinstale a versão do Helm:
helm uninstall csi-secrets-store -n kube-system
Desativar o complemento do Secret Manager
Para desativar o complemento do Secret Manager em um cluster padrão ou do Autopilot, execute o seguinte comando:
Console
-
No console do Google Cloud , acesse a página Google Kubernetes Engine.
Na lista de clusters, clique no nome do cluster que você quer modificar.
Na página de detalhes do cluster, na seção Segurança, clique em Secret Manager.
Na caixa de diálogo Editar o Secret Manager, desmarque a caixa de seleção Ativar o Secret Manager.
Clique em Salvar alterações.
gcloud
Antes de usar os dados do comando abaixo, faça estas substituições:
- CLUSTER_NAME: o nome do cluster.
- REGION: a região do Compute Engine para o cluster, como
us-central1.
Execute o seguinte comando:
Linux, macOS ou Cloud Shell
gcloud container clusters update CLUSTER_NAME \ --no-enable-secret-manager \ --region=REGION \
Windows (PowerShell)
gcloud container clusters update CLUSTER_NAME ` --no-enable-secret-manager ` --region=REGION `
Windows (cmd.exe)
gcloud container clusters update CLUSTER_NAME ^ --no-enable-secret-manager ^ --region=REGION ^