O que e um Kubernetes Secret? Lidando com dados sensiveis
Um Kubernetes Secret armazena dados sensiveis - senhas, tokens, chaves - que os pods consomem como env vars ou arquivos, mantidos separados da configuracao comum.
Um Secret e como um ConfigMap, mas destinado a valores sensiveis. Separar os secrets permite que o Kubernetes os trate com cuidado extra: controle de acesso mais rigido, criptografia opcional em repouso e evitar logging acidental. Mas um Secret padrao e apenas codificado em base64, nao criptografado - um ponto que confunde muita gente.
Como os pods consomem secrets
Como os ConfigMaps, os Secrets aparecem como variaveis de ambiente ou arquivos montados. Uma senha de banco de dados, por exemplo, pode ser montada como arquivo ou injetada como env var no continer que precisa dela.
Base64 nao e criptografia
Por padrao os valores de Secret sao codificados em base64, o que e codificacao, nao criptografia - qualquer um que possa ler o Secret pode decodifica-lo. Habilite a criptografia em repouso no etcd e restrinja o RBAC para tornar os Secrets genuinamente secretos.
Protegendo secrets corretamente
- Restrinja quem pode ler Secrets via RBAC.
- Habilite a criptografia em repouso no etcd.
- Considere stores externos (Vault, secret managers de nuvem) com operators.
Secret vs ConfigMap
Funcionalmente parecidos; a diferenca e a intencao e o tratamento. Coloque valores sensiveis em Secrets para que recebam o tratamento mais rigoroso, e config nao sensivel em ConfigMaps.
Secrets na CI/CD
Pipelines nunca devem deixar secrets hardcoded nos manifests. Injete-os do secret store do provedor de CI ou de um secret manager de nuvem no momento do deploy, idealmente via credenciais OIDC de curta duracao em vez de chaves estaticas de longa duracao.
Principais conclusões
- Um Secret guarda dados sensiveis para pods, separado dos ConfigMaps.
- Secrets padrao sao codificados em base64, nao criptografados - habilite criptografia e RBAC.
- A CI/CD deve injetar secrets de um secret store, nunca deixa-los hardcoded.