Como ConfigMaps e Secrets funcionam para injetar configuração nos workloads?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** e **Secrets** desacoplam a configuração das imagens de container, de modo que a mesma imagem roda em dev, staging e produção com configurações diferentes. ConfigMaps guardam config **não sensível**; Secrets guardam dados **sensíveis** (senhas, tokens, keys) e são tratados com mais cuidado.

## A ideia: config fora da imagem

```text
Imagem = código (imutável, construído uma vez).  Config = valores por ambiente.
Embutir config na imagem é um anti-pattern (rebuild por ambiente, vazamento de secrets).
→ Guarde config em ConfigMaps/Secrets, injete em runtime como env vars ou arquivos.
```

## ConfigMap: configurações não sensíveis

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  FEATURE_X: "true"
  app.properties: |
    timeout=30
    retries=3
```

## Secret: valores sensíveis

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # texto puro aqui; armazenado codificado em base64 no etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Normalmente criado de forma imperativa para evitar commitar secrets no git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Injetando num Pod: como env vars ou como arquivos

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # uma única key de um ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # uma única key de um Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importa TODAS as keys como env vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # monta a config como arquivos
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Ressalvas importantes sobre Secrets

```text
⚠ Os dados de Secret são CODIFICADOS em base64, não criptografados, por padrão.
  → Habilite ENCRYPTION AT REST para o etcd (EncryptionConfiguration).
  → Restrinja o acesso com RBAC (quem pode 'get secrets').
  → Prefira gerenciadores externos (Vault, Secrets Manager da cloud) ou sealed secrets.
  → Nunca commite manifests de Secret reais no git.
Config via env var é lida UMA VEZ no início do container; arquivos montados podem atualizar ao vivo.
```

## Por que isso importa

Separar configuração de código é uma prática operacional central, e ConfigMaps e Secrets são como o Kubernetes a implementa, então entendê-los é conhecimento essencial de nível pleno. Embutir configurações específicas de ambiente numa imagem é um anti-pattern — força um rebuild por ambiente e arrisca vazar secrets — então o Kubernetes permite que você mantenha uma única imagem imutável e injete a configuração em runtime: **ConfigMaps** para valores não sensíveis (log levels, feature flags, arquivos de config) e **Secrets** para dados sensíveis (senhas, tokens, keys). Conhecer as duas formas de consumi-los — como **environment variables** (keys individuais via `configMapKeyRef`/`secretKeyRef`, ou todas as keys via `envFrom`) e como **arquivos montados** (com a nuance de que env vars são lidas uma vez no início enquanto arquivos montados podem atualizar ao vivo) — é conhecimento prático do dia a dia para fazer deploy de aplicações reais. Igualmente importante é entender as ressalvas de segurança que pegam muitos engenheiros de surpresa: os dados de Secret são apenas **codificados em base64, não criptografados**, por padrão, então protegê-los de verdade requer habilitar **encryption at rest** para o etcd, restringir o acesso com **RBAC**, evitar commitar manifests de Secret no controle de versão, e frequentemente integrar um gerenciador de secrets externo. Como praticamente todo workload precisa de configuração por ambiente e credenciais, e como lidar mal com Secrets é uma falha de segurança comum e séria, um domínio sólido de ConfigMaps e Secrets é fundamental para rodar aplicações de forma segura e correta no Kubernetes.

A ideia: config fora da imagem

ConfigMap: configurações não sensíveis

Secret: valores sensíveis

Injetando num Pod: como env vars ou como arquivos

Ressalvas importantes sobre Secrets

Por que isso importa

Perguntas relacionadas