ConfigMaps, Secrets e volumes no Kubernetes: configuração e estado
Entenda como separar configuração, dados sensíveis e persistência no Kubernetes, quais limites existem em ConfigMaps e Secrets e por que o filesystem do container não deve ser tratado como armazenamento durável.
No Kubernetes, um Pod pode desaparecer e ser substituído por outro. Isso é uma vantagem enquanto a aplicação consegue renascer em uma nova instância sem depender de ajustes manuais escondidos naquela réplica anterior.
Mas essa substituição força três perguntas que aplicações simples muitas vezes adiam:
- onde fica a configuração que muda entre ambientes?
- como dados sensíveis chegam ao workload sem serem embutidos na imagem?
- quais dados podem desaparecer com a instância e quais precisam sobreviver?
ConfigMaps, Secrets e volumes existem em regiões diferentes desse problema. Colocá-los no mesmo saco cria confusão: configuração não é segredo, segredo não é automaticamente um cofre seguro e volume não significa necessariamente persistência durável.
O objetivo aqui é separar essas responsabilidades antes de pensar em manifests.
O problema: a imagem da aplicação não deve carregar toda a configuração
Uma imagem de container funciona melhor quando representa um artefato reproduzível da aplicação, não uma cópia diferente para cada ambiente.
Imagine uma API que usa a mesma versão de código em desenvolvimento, homologação e produção. O endereço de um serviço interno, o nível de log ou um feature flag podem variar entre ambientes sem que o binário da aplicação precise mudar.
Se cada alteração desse tipo exigir reconstruir a imagem, configuração e artefato ficam acoplados.
imagem da aplicação
+ configuração de produção
+ credencial
+ endereço de dependência
= artefato específico demais
Uma separação melhor é:
imagem
→ código + runtime + dependências
configuração
→ valores do ambiente
segredos
→ credenciais e material sensível
storage
→ dados que precisam existir fora do filesystem descartável
Essa separação não é exclusiva de Kubernetes. Ela já é uma boa prática em deploys tradicionais. Kubernetes apenas oferece objetos próprios para expressar parte desse contrato.
ConfigMap: configuração não sensível fora da imagem
ConfigMap é um objeto da API pensado para dados de configuração não confidenciais.
Ele permite que uma aplicação receba valores que mudam entre ambientes sem exigir uma nova imagem. Esses dados podem chegar ao workload de diferentes formas, como variáveis de ambiente, argumentos ou arquivos montados.
O ponto conceitual é mais importante que a forma de consumo:
a mesma imagem pode ser executada em contextos diferentes porque o ambiente fornece a configuração separadamente.
Exemplos adequados para ConfigMap incluem:
- nome lógico de uma dependência interna;
- nível de log;
- flags não sensíveis;
- parâmetros funcionais do ambiente;
- fragmentos de configuração que não carregam segredo.
Isso também melhora rastreabilidade. Quando código e configuração estão separados, fica mais claro se uma mudança de comportamento veio de uma nova versão da aplicação ou de uma alteração no ambiente.
Mas ConfigMap tem um limite fundamental: ele não fornece confidencialidade nem criptografia. Colocar uma senha em ConfigMap porque “é mais fácil” não transforma aquele dado em algo protegido.
Para dados sensíveis existe outra abstração.
Secret: uma categoria própria para dados sensíveis
Secret é um objeto Kubernetes destinado a pequenas quantidades de informação confidencial, como senha, token ou chave.
A principal melhoria de modelagem é simples: dados sensíveis deixam de ficar misturados no código, na imagem ou na definição comum de configuração.
Isso permite aplicar controles diferentes sobre quem pode ler ou manipular aquele objeto e reduz algumas formas de exposição acidental.
Mas o nome Secret pode induzir a uma conclusão perigosa: imaginar que qualquer valor colocado ali virou automaticamente um segredo fortemente protegido.
Não virou.
Secret representa intenção de confidencialidade e fornece mecanismos específicos do Kubernetes para trabalhar com esses dados. A segurança final depende também de configuração do cluster, RBAC, criptografia em repouso, acesso aos namespaces, modo de consumo e práticas da aplicação.
Base64 não é criptografia
Valores no campo data de um Secret são representados em Base64. Isso atende à necessidade de representar bytes em um formato textual compatível com a API.
Base64 não oferece segredo.
Ele é uma codificação reversível sem chave. Qualquer pessoa que consiga ler o valor codificado consegue decodificá-lo.
texto sensível
↓
Base64
↓
representação textual reversível
≠
criptografia
A própria documentação do Kubernetes ressalta que dados codificados em Base64 ficam apenas obscurecidos, não protegidos por confidencialidade.
Essa diferença é essencial porque copiar um Secret para um repositório Git continua sendo uma exposição, mesmo que o conteúdo pareça uma sequência ilegível de caracteres.
O mesmo vale para logs, tickets e chats: Base64 não transforma material sensível em informação segura para compartilhamento.
Secret Kubernetes não é um cofre completo
Por padrão, Secrets podem ser armazenados sem criptografia no datastore usado pelo API server, tipicamente etcd, caso encryption at rest não tenha sido configurada.
Além disso, autorização importa muito. Quem possui capacidade de ler Secrets pela API pode acessar seu conteúdo. Em determinados cenários, permissões para criar workloads dentro de um namespace também podem abrir caminhos indiretos para consumir Secrets daquele namespace.
Por isso, operar Secrets com segurança exige um conjunto de controles, por exemplo:
- criptografia em repouso corretamente configurada;
- RBAC com privilégio mínimo;
- separação adequada de namespaces e responsabilidades;
- redução de cópias desnecessárias de credenciais;
- rotação de material sensível;
- cuidado com variáveis de ambiente, dumps, logs e ferramentas de diagnóstico;
- auditoria de acesso quando o risco exigir.
Chamar Kubernetes Secret de “cofre” sem essas qualificações cria uma falsa sensação de proteção.
Em ambientes com requisitos maiores, é comum integrar o cluster a sistemas externos de gestão de segredos ou mecanismos que fornecem credenciais dinamicamente. Esses sistemas podem oferecer recursos como rotação centralizada, políticas especializadas, HSM/KMS ou emissão temporária de credenciais.
Esse aprofundamento fica para uma camada posterior. O fundamento aqui é: Secret melhora a modelagem do dado sensível dentro do Kubernetes, mas não substitui sozinho uma estratégia completa de secrets management.
Como configuração e segredo chegam ao workload
ConfigMaps e Secrets podem ser expostos à aplicação de formas diferentes. Dois modelos comuns são valores no ambiente do processo e arquivos disponibilizados por volumes.
Não existe uma escolha universalmente melhor. O desenho depende de como a aplicação lê configuração e de como atualizações devem ser propagadas.
O importante é evitar um erro conceitual: o workload não deveria precisar de intervenção humana dentro do container para “ficar pronto”.
Uma nova réplica deve conseguir nascer e obter sua configuração por um caminho reproduzível.
nova réplica
↓
recebe configuração declarada
↓
recebe acesso autorizado a dados sensíveis
↓
inicia sem edição manual no filesystem
Se alguém precisa entrar em cada Pod para editar arquivos, copiar .env ou ajustar credenciais, a aplicação continua acoplada à identidade daquela instância, contrariando o modelo de substituição que vimos no artigo sobre Pods, ReplicaSets e Deployments.
O filesystem do container é efêmero
Outro erro comum aparece quando a aplicação grava dados importantes diretamente no filesystem gravável do container e passa a tratá-los como duráveis.
A documentação do Kubernetes é clara: arquivos gravados no filesystem do container são efêmeros. Quando aquele container é substituído, seu estado local não acompanha automaticamente a nova instância.
Pense em exemplos:
- cache temporário pode ser descartável;
- arquivo gerado para processamento intermediário talvez seja descartável;
- upload único de um cliente provavelmente não pode desaparecer;
- dados de banco obviamente não deveriam depender do filesystem de um container de aplicação;
- relatório temporário pode ser regenerável ou pode precisar sobreviver, conforme o contrato do produto.
A pergunta correta é menos técnica do que parece:
se este Pod desaparecer agora, esse dado pode desaparecer junto sem violar o comportamento esperado do sistema?
Se a resposta for “não”, você precisa de uma estratégia de persistência fora daquele filesystem efêmero.
Volumes: desacoplar dados do filesystem do container
A abstração de volume permite disponibilizar armazenamento em caminhos acessíveis aos containers de um Pod.
Isso resolve dois grupos de problemas importantes:
- preservar ou compartilhar dados além do filesystem gravável de um container específico;
- fornecer arquivos vindos de outras fontes, como ConfigMaps e Secrets.
Mas a palavra “volume” ainda não significa automaticamente “dados sobreviverão para sempre”. Kubernetes possui tipos de volume com lifecycles diferentes.
Alguns volumes são efêmeros e acompanham o ciclo de vida do Pod. Outros são respaldados por armazenamento persistente cujo ciclo de vida pode ultrapassar o de qualquer Pod individual.
Portanto:
volume
≠ necessariamente persistência durável
O que determina o comportamento é o tipo de volume e o storage que existe por trás dele.
Reinício de container, substituição de Pod e persistência não são a mesma coisa
Essa distinção ajuda a evitar muitos bugs.
Um volume associado ao Pod pode preservar dados entre reinícios de containers dentro daquele mesmo Pod, mas um volume efêmero pode ser destruído quando o Pod deixa de existir.
Já um volume persistente é desenhado para ter lifecycle independente do Pod que o consome.
Temos, portanto, três eventos diferentes:
container reinicia
→ o Pod pode continuar existindo
Pod é substituído
→ recursos efêmeros ligados ao Pod podem desaparecer
storage persistente
→ deve ter lifecycle independente do Pod
Quando uma arquitetura ignora essas diferenças, a aplicação costuma parecer funcionar em testes simples e falhar justamente em rollout, rescheduling ou recuperação de nó — momentos em que Kubernetes exerce o comportamento para o qual foi criado.
O que pode desaparecer e o que precisa sobreviver
Antes de escolher qualquer tecnologia de storage, classifique os dados pelo contrato de negócio.
Dados descartáveis podem ser reconstruídos ou perdidos sem impacto relevante. Caches são o exemplo clássico, embora até um cache possa ter custo de reconstrução que precisa ser considerado.
Dados regeneráveis podem desaparecer tecnicamente, mas sua reconstrução exige uma fonte confiável e tempo aceitável.
Dados duráveis representam estado que o produto promete preservar: arquivos de clientes, registros de negócio, bancos de dados, evidências, artefatos que não podem ser simplesmente recalculados.
Essa classificação vem antes de NFS, block storage, object storage, CSI ou qualquer solução específica.
Kubernetes não decide por você o que é importante. Ele fornece abstrações para conectar workloads a formas de armazenamento. A responsabilidade de definir durabilidade, backup, restauração, replicação e consistência continua sendo da arquitetura.
PersistentVolume e PersistentVolumeClaim como modelo mental
Para armazenamento persistente, Kubernetes separa a ideia de capacidade de storage da solicitação feita pelo workload.
Um PersistentVolume representa uma unidade de armazenamento disponível no cluster, provisionada previamente ou dinamicamente por mecanismos de storage.
Um PersistentVolumeClaim representa uma solicitação de armazenamento feita pelo consumidor.
A relação pode ser vista assim:
aplicação / Pod
↓ solicita
PersistentVolumeClaim
↓ vincula
PersistentVolume
↓ respaldado por
storage real
Essa separação evita que a aplicação precise conhecer todos os detalhes físicos de como o storage é oferecido.
Em clusters reais entram também StorageClasses, provisionamento dinâmico, modos de acesso, políticas de retenção e drivers CSI. Esses temas pertencem à prática de plataforma e storage, não precisam ser memorizados agora para compreender o fundamento.
O conceito central é: o lifecycle do dado persistente não deve depender da existência daquele Pod específico.
Persistência não substitui backup
Um disco que sobrevive ao Pod não é automaticamente um backup.
PersistentVolume resolve uma dimensão de lifecycle e acesso ao storage. Ele não garante, sozinho:
- cópias históricas recuperáveis;
- proteção contra exclusão lógica;
- recuperação de corrupção;
- consistência de aplicação durante snapshot;
- replicação entre regiões;
- objetivo de tempo de recuperação;
- objetivo de perda aceitável de dados.
Essa distinção é importante porque Kubernetes pode tornar workloads substituíveis enquanto os dados continuam sendo o ponto mais sensível da arquitetura.
Quanto mais crítica a informação, mais a estratégia precisa incluir backup, restauração testada e requisitos explícitos de durabilidade fora da simples existência de um volume.
External secret managers: próximo aprofundamento, não requisito básico
Quando a organização precisa de rotação centralizada, credenciais temporárias, integração com KMS/HSM, políticas mais avançadas ou uma única fonte de segredos para várias plataformas, sistemas externos de gestão de segredos passam a fazer sentido.
A integração com Kubernetes pode ocorrer por diferentes mecanismos e projetos do ecossistema. Não existe razão para transformar este artigo em comparação de ferramentas.
O que deve ficar claro é a fronteira:
Kubernetes Secret
→ objeto da plataforma para dados sensíveis
secret manager externo
→ sistema especializado de gestão, emissão, rotação e políticas de segredos
Um pode participar da entrega do outro. Eles não são conceitos equivalentes.
Um mapa prático de responsabilidade
Quando uma aplicação entra no Kubernetes, vale perguntar onde cada informação pertence:
| Informação | Responsabilidade conceitual |
|---|---|
| nível de log | configuração não sensível |
| hostname de um Service interno | configuração não sensível |
| token de API | dado sensível |
| certificado/chave privada | dado sensível com controles fortes |
| cache recriável | estado possivelmente efêmero |
| upload de cliente | estado durável |
| banco de dados | estado durável com estratégia própria de backup/recuperação |
| arquivo temporário de processamento | depende do custo e contrato de regeneração |
A tabela não prescreve um objeto Kubernetes para todos os casos. Ela força a pergunta certa antes da ferramenta.
O modelo mental que vale guardar
ConfigMaps, Secrets e volumes ficam mais claros quando você os associa a problemas distintos:
ConfigMap
→ configuração não confidencial fora da imagem
Secret
→ dado sensível tratado como categoria própria
mas que ainda exige controles de segurança
volume efêmero
→ dados/arquivos ligados ao lifecycle do Pod
PersistentVolume/PVC
→ armazenamento com lifecycle independente do Pod
A ideia comum entre todos eles é reduzir dependências ocultas da instância concreta.
Se um Deployment cria uma nova réplica, ela deve conseguir receber a configuração necessária, acessar os segredos autorizados e reencontrar o estado que precisa sobreviver — sem alguém reconstruir manualmente o ambiente daquele Pod.
Próximo passo: health, scaling e rollout
Com workloads substituíveis, descoberta estável, configuração separada e persistência compreendida, falta fechar uma pergunta operacional decisiva:
como Kubernetes sabe se uma nova instância iniciou, está pronta para receber tráfego e continua saudável enquanto o sistema escala ou troca versões?
É aí que entram startup, readiness e liveness probes, scaling horizontal, rollout, rollback e observabilidade.
Esse será o 2B-C. E ele precisa preservar uma distinção importante desde já:
workload existe
≠
workload está pronto
≠
serviço está saudável
≠
usuário está satisfeito
A plataforma consegue automatizar muita coisa, mas somente quando damos a ela sinais técnicos confiáveis — e mesmo esses sinais não substituem observabilidade do comportamento real da aplicação.