APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um token autoriza pedidos ao Vault; uma credencial dinâmica pode ter o seu próprio lease. Os ciclos relacionam-se, mas não devem ser tratados como um único temporizador. Service tokens suportam renovação, accessors e revogação individual. Batch tokens são mais leves, mas não oferecem essas mesmas funções. Um accessor referencia um token para operações limitadas; não permite autenticar como o titular. O chamador continua a precisar de autorização de gestão. Na hierarquia normal, revogar um pai revoga filhos não orphan e leases associados. Criar orphan muda essa dependência, sem eliminar TTL ou policies. A decisão precisa de refletir quem deve controlar o ciclo de vida do workload.
Aplicação guiada
Num batch fictício de 90 minutos com lease inicial de 30, copiar a password para disco não prolonga validade. Renova quando permitido e trata substituição quando o máximo é atingido. O increment pedido numa renovação é tempo a partir de agora e pode ser limitado pelo backend: se a resposta devolve 900 segundos, usa 15 minutos, não a soma com o TTL anterior. Tokens periódicos renovados a tempo podem manter validade, mas um explicit max TTL continua a impor fim de vida. Root deve ficar reservado a bootstrap ou emergência e ser revogado quando deixa de ser necessário. Uma password arbitrária guardada em KV não passa a credencial dinâmica: expirar o token de leitura não altera automaticamente a password no sistema externo.
TTL pedido 1800, TTL devolvido 900: o consumidor planeia com 900 segundos.
Armadilhas comuns
Accessor como token; orphan como imortal; renovação como soma; token renovado como todos os leases renovados.
Tópicos relacionados: Autenticação e identidade · Policies, paths e capabilities · Segredos KV, database e wrapping
Usa a validade devolvida e ensaia renovação, substituição e revogação.
Referência: Lease renewal and revocation · Vault Associate (003); product version tested: Vault 1.19