Vault — ESO e Estrutura de Secrets

Estrutura de paths

O padrão dominante é:

text secret/{ENV}/tenants/{namespace}/{app}/config

Exemplos:

• secret/HML/tenants/tre/auth-api/config
• secret/NOX/tenants/cmd-prd/is-core-api/config

Além disso, há paths system/... para secrets compartilhados e image pull secrets globais.

Integração com ESO

O fluxo operacional é:

1. Vault armazena o secret fonte
2. ClusterSecretStore aponta para o mount correto do ambiente
3. ExternalSecret de cada chart sincroniza o conteúdo
4. O Secret do Kubernetes é consumido pelo pod
5. O Reloader reinicia a workload se houver mudança

Padrões importantes

• maioria das apps usa tenants/{namespace}/{app}/config
• system/global-pull-secrets abastece imagePullSecrets
• apps como redeis-auth-api usam scope de sistema
• auth-api possui necessidade adicional de chaves codificadas em base64

Exemplo de template

yaml spec: secretStoreRef: kind: ClusterSecretStore name: vault-backend target: name: {{ .Release.Name }}-config dataFrom: - extract: key: tenants/{{ .Release.Namespace }}/{{ .Values.app.name }}/config

O que precisa existir antes do deploy da aplicação

• o mount do ambiente (secret/HML ou secret/NOX)
• o secret da app no path esperado
• o ClusterSecretStore funcional no cluster
• o secret global de pull de imagem

Sem isso, o chart pode até ser aplicado, mas a aplicação não sobe de forma saudável.