Gerenciamento de configurações e segredos

Gerenciamento de configurações e segredos

1) Por que é necessário

• Previsíveis (esquemas, validação, versões).
• Seguro (criptografia, direitos mínimos, rotação).
• Gerenciáveis (GitOps, auditoria, reversões).
• Dinâmicas onde isso for justificado (função flags, configuração de limites).

2) Classificação de artefatos

Configs públicos: fichas, liminares, timeouts, função flags (sem segredos).
Configs sensíveis: parâmetros que alteram o comportamento de caminhos críticos (como limites de pagamento).
Segredos: senhas/chaves/tokens/certificados/materiais de encriptação.
Artefatos de confiança: certificados de raiz/intermediário, políticas PKI, chaves KMS.

O princípio da separação de direitos é segredos públicos ≠ sensíveis ≠.

3) Hierarquia de configurações

1. Global defaults (org-wide).

2. Environment (`prod/stage/dev`).

3. Region (`eu-central-1`, `us-east-1`).

4. Tenant/Brand (para multi-tenentes).

5. Serviço (microsserviço específico).

6. Override - alternadores de tempo.

Regras de fusão: «Abaixo vence», conflito somente por MR/approval.

Exemplo (YAML)

yaml defaults:
http:
timeout_ms: 800 retry: 2 prod:
http:
timeout_ms: 1200 service: payments-api overrides:
eu-central-1:
http:
timeout_ms: 1500

4) Esquemas e validação

Cada config é um contrato com o esquema (JSON Schema/OPA/validadores em CI).

Tipos, faixas, campos obrigatórios, valores padrão.
Regras Guard (não é possível colocar 'retry> 5', 'p95 _ target <50ms').
Verificação automática na CI e na aplicação (admision-webhook/KRM).

Fatia do JSON Schema

json
{
"type":"object",
"properties":{
"http":{"type":"object","properties":{"timeout_ms":{"type":"integer","minimum":100,"maximum":10000},"retry":{"type":"integer","minimum":0,"maximum":5}},"required":["timeout_ms"]},
"feature_flags":{"type":"object","additionalProperties":{"type":"boolean"}}
},
"required":["http"]
}

5) Modelos de entrega de configs

Static (imagem-baked): confiável, mas requer restartes.
Push/Watch: agentes/sidecar recebem atualizações (stream/poll) e sinalizam para o aplicativo.
Pull on startup: Recebemos um snapshot quando começamos (simplificar hot-path).
Edge cachê/proxy para cargas geo-distribuídas.

Principal: atômica e versionização de snapshots, controle de compatibilidade e reversão rápida.

6) Ferramentas e papéis

Armazéns de configs: Git + GitOps (Argo/Flux), Parameter Store/Config Service.
Armazéns de segredos: Vault, AWS Secret Management/SSM, GCP Secret, Azure KV.
Criptografia: KMS/HSM, SOPS (age/GPG/KMS), Sealed Secret, Criptografia Transit (Vault).
Entrega: CSI Secrets Store, Vault Agente Injector/Sidecar, contêineres init.
Bandeiras/dinâmicas: plataforma de bandeiras de fich (colar kill-switch de emergência).

7) Criptografia: modelos e práticas

At rest: chaves KMS projeto/ambiente, criptografia envelope.
In transit: TLS/mTLS com autenticação mútua.
At use: decodificação o mais tarde possível, preferencialmente na memória de processo/sidecar (sem gravação em disco).
Hierarquia chave: root (HSM) → KMS CMK → data keys (DEK).
Rotação: calendário (90/180 dias) + por evento (comprometimento/saída do funcionário).

8) Gerenciamento de segredos: pattern

8. 1 GitOps + SOPS (esmalte estático)

O Git só armazena a cifra.
Criptografia em CI/CD ou em cluster (KMS/age).
Aplicar através do controlador (Flux/Argo) → Kubernetes Secret.

yaml apiVersion: v1 kind: Secret metadata: { name: psp-keys, namespace: payments }
type: Opaque data:
apiKey: ENC[AES256_GCM,data:...,sops]

8. 2 Vault Agente Injector (emissão dinâmica)

A conta de serviço (JWT/SA) é autenticada no Vault.
Sidecar coloca os créditos em tmpfs e atualiza por TTL.
Suporte de crédito dinâmico (DB, cloud - isolamento e curta duração).

yaml annotations:
vault. hashicorp. com/agent-inject: "true"
vault. hashicorp. com/role: "payments-api"
vault. hashicorp. com/agent-inject-secret-db: "database/creds/payments"

8. 3 CSI Secrets Store

Personalizar o segredo como volume, a rotação é transparente.
Para PKI - Atualização automática de certificados/chaves.

9) Kubernetes: aspectos práticos

ConfigMap são apenas dados públicos/insensíveis.
Secret - sensível (com base64 - não criptografia; inclua Encrypition at Rest para etcd).
Anotações Checksum: Restart Deployment quando o config é alterado.
Controle Advision: Proibir a montagem de segredos não da lista branca, proibir senhas plain em manifestos.
NetworkPolicy: limitar o acesso aos provedores de segredos (Vault/CSI).

Checksum exemplo (Helm)

yaml annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}

10) Políticas de acesso (RBAC/ABAC)

Least privege: O serviço só vê seus segredos; acesso por namespace/label/prefix.
Split duties: criação de segredo ≠ leitura de conteúdo; uma auditoria de qualquer leitura.
Acertos de tempo: logins dinâmicos (DB, cloud) com TTL e rotação automática.
Segmentação: prod/estágio em diferentes projetos/contas/chaves KMS.

11) Auditoria, registro, observação

Logs de leitura/emissão de segredos: quem/quando/o que/de onde; correlação com lançamentos e incidentes.
Métricas: taxa de consulta, segredos vencidos, certificados vencidos, proporção de créditos dinâmicos.
Eventos de segurança: excesso de quotas, anomalias IP/tempo, múltiplas autenticações indevidas.

12) Rotação de segredos e certificados

Normalize os prazos: chaves API de 90 dias, senhas DB de 30 dias e sertões TLS de 60 a 90 dias.
Rotação: geração → teste → dupla publicação (grace) → alternação → revisão do antigo → de verificação.
Discernimento: dupla gravação de configs/segredos, compatibilidade de clientes (accept new + old).
PKI: seu próprio CA ou integração com o exterior; atualização automática de materiais MTLS por CSI/Vault.

13) Configs dinâmicos e função flags

As opções «quentes» (limites, temporizações) são tiradas de um serviço de config/plataforma-bandeira.
Dinheiro local e stickiness (cálculo da opção por hashtag), TTL curtos.
Guardas SLO para alteração de parâmetros sensíveis (auto-revezamento e kill-switch).

14) Integração com CI/CD e GitOps

Pré-commit/CI: Linterners de circuito, verificações SOPS, proibição de segredos «nus» (gitleaks/trufflehog).
Policy Gate: OPA/Conftest - a proibição de configurs sem padrão/sem anotações do proprietário/sem marcas do ambiente.
Progressive delivery: promoção de configs como artefatos (semver), canary para alteração de parâmetros.
Anotações de lançamento: quem/qual config/segredo mudou; correlação rápida com p95/5xx.

15) Exemplos

15. 1 Política OPA: proibição de SG abertos no config

rego package policy. config

deny[msg] {
input. kind == "SecurityGroupRule"
input. cidr == "0. 0. 0. 0/0"
input. port = = 5432 msg: = "Postgres open internet banned"
}

15. 2 Exemplo de «snapshot» config (versionável)

yaml version: 1. 12. 0 owner: payments-team appliesTo: [ "payments-api@prod" ]
http:
timeout_ms: 1200 retry: 2 withdraw:
limits:
per_txn_eur: 5000 per_day_eur: 20000 flags:
new_withdrawal_flow: false

15. 3 Vault - credos dinâmicos de BD

hcl path "database/creds/payments" {
capabilities = ["read"]
}
role issues user/password with TTL = 1h and auto-rollover

16) Anti-pattern

Segredos em Git em aberto/em variáveis Helm/Anxibe sem criptografia.
Um único «mega-segredo» para todos os serviços/ambientes.
Tokens de longa vida sem TTL/rotação; certificados «imortais».
Configs dinâmicos sem circuitos/validação e nenhuma auditoria de alterações.
Falta Encrypition at Rest para etcd/KMS e rede sem mTLS.
Edição manual de configs na venda (contornar GitOps).
Acesso dos desenvolvedores aos segredos de prod, por precaução.

17) Folha de cheque de implementação (0-60 dias)

0-15 dias

Incluir esquemas/validadores para configs; ter um repo «configs» e um fluxo de Ops GitOps.
Levantar KMS e criptografia: SOPS/Sealed Secret/Encrypition at Rest em etcd.
Proibir segredos plaintexto em CI (scanners), digitar owners/approvals.

16 a 30 dias

Separar armazéns: configs públicos vs segredos sensíveis vs.
Implantar o Vault/Secret Gerente e selecionar o caminho de entrega (Agente/CSI/SOPS).
Ajustar a rotação TLS/DB/PSP; dashboards de vida/vencimento.

31 a 60 dias

Configs dinâmicos e bandeiras com SLO-gating e auto-recuo.
Políticas OPA/Conftest; zero-trust (namespace/label-scoped).
Game-day: Simulação de fuga de segredo e rotatividade de força.

18) Métricas de maturidade

% dos segredos criptografados e sem acesso direto do Git = 100%.
A cobertura de configs com esquemas/validação ≥ 95%.
Tempo médio de rotação de segredos críticos (alvo: relógio, não dias).
A taxa de crédito dinâmico (DB/cloud) ≥ de 80%.
0 incidentes por «plain secret «/certificados vencidos.
MTTR com erro de config com retração <5 minutos.

19) Papéis de comando e processos

Config Owner: dono de domínio/esquema/política.
Segurança: políticas, hierarquia-chave, auditoria de acesso.
Plataforma/SRE: GitOps, fornecimento/injecção, telemetria.
App Teams: consumo de configs/segredos, testes de compatibilidade.

20) Conclusão

Um circuito confiável de configurações e segredos são esquemas + GitOps + criptografia + rotação + política. Divida o público e o secreto, criptografe tudo, aplique configs atômico e versionável, minimize os direitos e a vida dos créditos, automatize rotações e auditoria. As mudanças serão rápidas e seguras, e o risco de fugas e baixas será mínimo.