APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Vault verifica uma identidade através de um auth method e normalmente emite um token usado nas operações seguintes. O método pode responder a pessoas ou workloads; a escolha deve considerar a identidade já disponível, o ambiente e a entrega inicial de credenciais. Um login válido não concede acesso a todos os segredos. As políticas associadas continuam a decidir operações em paths concretos. Também não confundas o nome do tipo com o path onde foi montado: userpass pode estar em auth/ops-login. O cliente deve usar esse endpoint configurado. CLI, API e UI são interfaces para as mesmas responsabilidades de autenticar, autorizar e proteger credenciais.
Aplicação guiada
Num batch fictício sem identidade cloud integrada, AppRole pode usar RoleID e SecretID. RoleID seleciona a role; SecretID é uma credencial que deve chegar apenas ao workload autorizado. A exigência de SecretID depende da configuração, por isso os exercícios indicam bind_secret_id ativo. Para pessoas autenticadas por origens diferentes, entities e aliases permitem relacionar identidades. O alias inclui o contexto do mount, pelo que nomes iguais não provam a mesma pessoa. Quem altera aliases, entities ou pertença a grupos pode influenciar privilégios. Uma tarefa de suporte aparentemente administrativa merece âmbito delimitado e evidência. Ao diagnosticar uma recusa depois do login, verifica token, entity, políticas e path antes de trocar o método ou distribuir credenciais de privilégio amplo.
Login bem-sucedido e read negado podem coexistir: são decisões diferentes.
Armadilhas comuns
Método como autorização; nome visível como identidade; SecretID como configuração pública; escrita em aliases como tarefa sem privilégios.
Tópicos relacionados: Policies, paths e capabilities · Tokens, leases e renovação · Segredos KV, database e wrapping
Identifica quem atua, como prova identidade e que operações recebe.
Referência: Vault authentication · Vault Associate (003); product version tested: Vault 1.19