Make a second call to the auth/token/create-orphan endpoint specifying the desired vault policies and required other parameters, and presenting with the token obtained in the previous step for authorization.Authenticate against Vault to obtain a token which has permission to call the auth/token/create-orphan endpoint.The process for creating orphan tokens normally goes as follows: ![]() This may or may not be a behavior you want, and for many automated DevOps processes that need to create new tokens on behalf of long-lived processes which will renew those tokens on their own, orphan tokens are the way to go. The side effect of this token hierarchy that gets created is that when the token used to generate the new token (parent) itself expires/revoked, all child tokens created by it are also revoked. ![]() When tokens are created they are bound to one or more Vault policies which define what things they can access within Vault and by default are also children of the token that was used to generate the child token (the “parent”). To create a new token, the token creator must present their own token. Tokens are utilized by Vault clients to authz/authn themselves to access secrets stored in Vault. If you’ve used Vault you are likely familiar with its concept of tokens, but you may or may not be familiar with the concept of orphan tokens. If you have a need to store secrets in a secure manner there are numerous options out there one of the more popular and cloud agnostic ones out there is Hashicorp Vault.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |