ConfigMap x Secret (e por que Secret não é 'seguro' por padrão)
Pergunta
Qual a diferença entre ConfigMap e Secret no Kubernetes, e por que um Secret sozinho não protege muito?
Resposta esperada
ConfigMap: config não sensível (feature flags, URLs, arquivos de config), injetada como variável de ambiente ou arquivo montado no Pod. Secret: mesma ideia, pra dados sensíveis (senha, token, chave TLS) — a API trata com um pouco mais de cuidado (não loga o valor, pode restringir por RBAC). MAS, por padrão, Secrets são só codificados em base64 no etcd, NÃO criptografados — quem lê o etcd ou tem permissão de `get secret` vê o valor. Pra ser de fato seguro: habilitar encryption-at-rest do etcd, RBAC restrito, e/ou um gerenciador externo (Vault, AWS/GCP Secret Manager via CSI driver ou External Secrets Operator) com rotação. Também: montar Secret como arquivo em vez de env var (env vaza mais fácil em logs/crash dumps/`/proc`), e nunca commitar o YAML do Secret com o valor.
Por que perguntam isso
Pergunta pleno/sênior de K8s. O 'base64 não é criptografia' é o ponto que separa. Sinal bom: montar como arquivo, External Secrets Operator.