Manter secrets seguros é essencial em qualquer deploy no Kubernetes. Tradicionalmente, gerenciar secrets no GKE significava injetá-los nos pods como variáveis de ambiente ou volumes. A abordagem funciona, mas é trabalhosa e levanta preocupações de segurança. Felizmente, o Google Cloud tem uma solução poderosa para isso: o add-on do Secret Manager para GKE.
Neste post, vou mostrar como usar o add-on do Secret Manager para GKE para acessar os secrets armazenados no Secret Manager como volumes montados nos Pods do GKE.
:: Em maio/2024, esse recurso ainda está em preview , então use com cautela.
O que é o Secret Manager?
O Secret Manager é um serviço gerenciado do Google Cloud Platform (GCP) feito para armazenar e recuperar informações sensíveis, como API keys, senhas e certificados. Ele oferece várias vantagens:
- Gerenciamento centralizado: os secrets ficam em um único lugar, o que simplifica o controle de acesso e a auditoria.
- Mais segurança: os secrets são criptografados em repouso e em trânsito, reduzindo o risco de exposição.
- Workload Identity simplificado: os workloads acessam secrets de forma segura via workload identity, sem precisar de credenciais adicionais.
Conheça o add-on do Secret Manager
O add-on do Secret Manager para o Google Kubernetes Engine (GKE) simplifica a forma como você acessa e gerencia secrets nos seus pods. Veja as vantagens:
- Acesso fácil: sem precisar escrever código sob medida, você acessa diretamente os secrets do Secret Manager a partir dos pods do GKE.
- Gerenciamento centralizado: armazene e controle todos os seus secrets em um único lugar (Secret Manager) e libere o acesso a secrets específicos para os pods do GKE.
- Segurança reforçada: aproveite recursos do Secret Manager, como criptografia, controle de acesso, rotação e logs de auditoria, junto com recursos do Kubernetes, como volume mounts para secrets.
- Ampla compatibilidade: funciona tanto em clusters GKE Standard quanto Autopilot, com suporte a deploys nas arquiteturas AMD e ARM.
O Add-on é derivado dos projetos open source Kubernetes Secrets Store CSI Driver e Google Secret Manager provider. Se você já usa o Secrets Store CSI Driver open source para acessar secrets, dá para migrar para o add-on do Secret Manager. Para mais detalhes, consulte Migrate from the existing Secrets Store CSI Driver.
Como o add-on ainda está em preview, hoje ele não traz os seguintes recursos:
Não seria melhor usar o External Secrets Operator?
Resumindo: se você precisa atender a alguma exigência de compliance e não pode ter secrets nativos do Kubernetes no cluster, o caminho é usar o Secrets Store CSI driver com o GKE Secrets Add-On, montando os secrets do Secret Manager direto como volumes nos pods. Se isso não for um requisito, vale a pena testar o ESO.
Existe uma comparação interessante entre o External Secrets Operator e o Secrets Store CSI driver feita por um usuário do GitHub chamado Lucas neste comentário, que vou incluir aqui no artigo:
O ESO sincroniza secrets de um cloud provider para secrets no k8s, então você pode continuar usando os secrets do k8s, se já estiver acostumado.
O SSCSID monta o secret externo direto como um volume no pod, e ter um secret do k8s no cluster é opcional.
O ESO foca em manter a configuração no CRD; o que você cria no secret store do provider é só o valor do secret em si.
O SSCSID exige que toda a configuração/secret esteja armazenada direto no provider, já que é de lá que a aplicação vai consumir. Isso pode ser complicado em configurações maiores que tenham alguns secrets embutidos.
Os secrets do ESO podem ser usados nativamente com qualquer recurso do k8s, o que é óbvio, mas 👇
O SSCSID precisa de um pod webhook para funcionar bem de verdade. Não dá para usar facilmente os secrets do SSCSID para referenciá-los em ingress, ou em dockerconfig para fazer pull de imagens, já que o objetivo dele é só montar em um pod. Mesmo se quiser habilitar a sincronização de k8s secrets, primeiro você precisa montar o secret em um pod para sincronizá-lo.
No ESO, como sincronizamos os secrets com secrets nativos do k8s, se você tiver problemas de conectividade, ainda consegue acessar o secret que está no cluster; quando reconectar, ele simplesmente continua o re-sync.
Com o SSCSID, se a conectividade cair, os mounts do csi driver param de funcionar caso ocorra algum restart, etc. Estão pensando em uma solução, mas não sei como anda o progresso: doc. Vale conferir com eles.
O ESO será apenas um deployment de operator no seu cluster.
O SSCSID terá um daemonset privilegiado de provider responsável por fazer os mounts nos seus pods.
Existem outras opções?
Se você procura uma alternativa segura para buscar secrets de serviços de gerenciamento de secrets diretamente para um volume, sem usar o Kubernetes Secrets Store CSI Driver, vale a pena dar uma olhada nisso.
Além disso, em 2001, Abdellfetah SGHIOUAR, Dev Advocate do Google, escreveu um artigo interessante que aborda algumas outras opções para armazenar secrets no GKE. Confira aqui.
**Primeiros passos com** o add-on do Secret Manager para GKE
Para começar, precisamos habilitar o add-on do Secret Manager no cluster. Também dá para criar um cluster novo já com essa flag. Lembre-se de substituir os campos CLUSTER_NAME e REGION/ZONE.
gcloud beta container clusters update <CLUSTER_NAME> \
--enable-secret-manager \
--location=<ZONE/REGION>
Confirme também se o Workload Identity Federation está habilitado no seu cluster.
Depois de habilitar o Secret Manager Add On, você deve ver duas novas APIs disponíveis com a versão de api secrets-store.csi.x-k8s.io/v1
$ kubectl api-resources | grep secrets-store
secretproviderclasses secrets-store.csi.x-k8s.io/v1 true SecretProviderClass
secretproviderclasspodstatuses secrets-store.csi.x-k8s.io/v1 true SecretProviderClassPodStatus
Para se comunicar com o Secret Manager, precisamos conceder as permissões necessárias à service account do Kubernetes que vamos usar.
Vamos primeiro criar o namespace e a service account do k8s para usar no cluster.
kubectl create ns secret-manager-access
kubectl create sa secret-manager-access-sa
Em seguida, vamos usar o Workload Identity Federation para conceder as permissões corretas à nossa service account do K8s. Lembre-se de substituir o Project ID e o Project Number nas variáveis.
PROJECT_NUMBER=<ADD_YOUR_PROJECT_NUMBER>
PROJECT_ID=<ADD_YOUR_PROJECT_ID>
NAMESPACE=secret-manager-access
gcloud projects add-iam-policy-binding projects/star-sorceress \
--role=roles/secretmanager.secretAccessor \
--member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/${NAMESPACE}/sa/secret-manager-access-sa \
--condition=None
PS: a forma de configurar o Workload Identity Federation mudou recentemente. Se quiser saber mais, dê uma olhada neste blog post, em que um colega da DoiT explica tudo em detalhes.
Abaixo, criamos nosso super secret no Google Secret Manager e também a primeira versão dele:
echo "This is my awesome secret, please don't share!" > super-secret.txt
gcloud secrets create super-secret --replication-policy="automatic" --data-file="super-secret.txt"
Agora precisamos criar o Custom Resource SecretProviderClass, que será vinculado ao secret do GCP criado anteriormente. Não esqueça de incluir o seu Project ID.
kubectl apply -f - <<EOF
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: super-secret
spec:
provider: gke
parameters:
secrets: |
- resourceName: "projects/<PROJECT_ID>/secrets/super-secret/versions/1"
path: "super-secret.txt"
EOF
Configure o volume do Pod
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: secret-manager-access
spec:
serviceAccountName: secret-manager-access-sa
containers:
- name: test-pod
image: google/cloud-sdk:slim
command: ["sleep","infinity"]
volumeMounts:
- mountPath: "/var/secrets"
name: super-secret
volumes:
- name: super-secret
csi:
driver: secrets-store-gke.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: super-secret
EOF
Vamos conferir se o secret está lá:
kubectl exec -it test-pod -- cat /var/secrets/super-secret.txt
This is my awesome secret, please don't share
Vantagens do Secret Manager CSI Driver:
- Segurança reforçada: os secrets nunca ficam armazenados dentro dos pods, o que reduz a superfície de ataque.
- Gerenciamento de workload simplificado: o workload identity elimina a necessidade de gerenciar credenciais dentro dos pods.
- Configuração mais flexível: o controle granular sobre o acesso aos secrets permite permissões refinadas.
- Logs de auditoria centralizados: todas as tentativas de acesso a secrets são registradas no Secret Manager, o que facilita a auditoria.
Conclusão
Ao adotar o Secret Manager Add On para GKE, você passa a contar com um Secret Manager CSI Driver totalmente gerenciado, fortalecendo bastante a postura de segurança do seu GKE e simplificando o gerenciamento de secrets nas suas aplicações. Com controle centralizado, montagem automatizada e controle de acesso robusto, o CSI Driver te dá liberdade para focar no que importa: construir e implantar suas aplicações com confiança.
Referências:
https://github.com/kubernetes-sigs/secrets-store-csi-driver
https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp
https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component#migrate
https://github.com/external-secrets/external-secrets/issues/478#issuecomment-964413129
https://medium.com/google-cloud/consuming-google-secret-manager-secrets-in-gke-911523207a79
https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity
https://github.com/doitintl/kube-secrets-init
Espero que este post tenha sido útil! Se tiver qualquer dúvida, fique à vontade para deixar um comentário aí embaixo.
Se você ainda não conhece a DoiT International, vale muito a pena dar uma olhada. Por aqui, nosso time está pronto para entender melhor você e suas necessidades em cloud engineering. Formado exclusivamente por engenheiros sêniores, somos especializados em consultoria avançada em cloud, design de arquitetura e suporte em debugging. Entre em contato e vamos conversar!