APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
As policies Vault descrevem operações permitidas ou negadas em paths. A ausência de uma concessão não equivale a acesso livre. Usa o endpoint efetivo para escolher capabilities, e não apenas o verbo de negócio: obter credenciais dinâmicas por GET pode criar uma conta externa, mas exige read no endpoint Vault apropriado. No KV v2, o path de dados inclui data, enquanto metadata tem operações próprias. Um comando CLI pode esconder parte dessa estrutura; a policy precisa de corresponder à API. O wildcard + representa um segmento, e o glob * não é uma expressão regular completa. A prioridade entre padrões deve ser analisada antes de somar permissões indiscriminadamente.
Aplicação guiada
Num exemplo fictício, a aplicação migrou para KV v2 e pede apps/data/funds, mas a regra continua em apps/funds. A correção é alinhar o path e testar acesso permitido e negado com o token real da aplicação. Dar root faria o serviço arrancar sem demonstrar a policy correta. Quando o mesmo padrão aparece em várias policies, as capabilities combinam-se, mas deny prevalece, incluindo sobre sudo. Sudo permite operações protegidas que também exigem a capability relevante; não é uma forma universal de ignorar regras. List merece atenção própria: pode revelar nomes de chaves mesmo quando os respetivos valores não são legíveis. Evita dados sensíveis nos nomes e não confundas listagem com autorização de leitura do segredo.
GET database/creds/reporting pode emitir credenciais, mas a capability a analisar é read.
Armadilhas comuns
CRUD pelo efeito externo; policy KV v1 num mount v2; glob como regex; list como filtro de nomes por read.
Tópicos relacionados: Autenticação e identidade · Tokens, leases e renovação · Segredos KV, database e wrapping
Valida path, padrão e capability com a identidade que fará o pedido.
Referência: Vault policies and path matching · Vault Associate (003); product version tested: Vault 1.19