Quico/vault-config
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

fix(docs): Correctly explain periodic tokens (#5)

Browse Source
This commit is contained in:
hygienic-books 2024-10-05 23:17:24 +02:00
parent 78dd48319c
commit 1980dceb73
2 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored Normal file
View File

@ -0,0 +1 @@
.idea

12
README.md
View File

@ -189,15 +189,15 @@ https://f.q.d.n/ui/vault/secrets/kv/list/for_rbacgroup_zabbix
The next example will explain orphan tokens. If you've followed examples above your Vault instance will have an `administrators` group with an `administrator` policy assigned to it. Users in that group will already have `write` access to `auth/token/create-orphan` so you can just use one of your `administrators` entities to follow along.
### Periodic and orphan tokens
### Periodic orphan tokens
As an alternative to the Zabbix example above you may want a token that auto-renews itself as long as it gets regularly used and that can outlive its parent entity.
As an alternative to the Zabbix example above you may want a token you can renew indefinitely which implies that it can outlive its parent entity.
By default a token is associated with the entity that created it, as a consequence a token cannot outlive the maximum time to live configured for its parent entity. In order to decouple a token from its parent entity and for a token to live longer than its parent entity you can make it an _orphan_ token.
A token created with a `period` - a time value indicating its maximum time to live - is considered a _periodic_ token. Unless a token is also orphaned its time to live still remains limited to that of its parent entity.
A token created with a `period` on the other hand - a time value indicating its maximum time to live - is considered a _periodic_ token. Unless a token is also orphaned its time to live still remains limited to that of its parent entity.
The first few prep steps will sound familiar from the Zabbix paragraph above. For example's sake let's assume we want the `remco` file generator (see [github.com/HeavyHorst/remco](https://github.com/HeavyHorst/remco)) to have Vault access:
For services that cannot handle renewal natively you will want both at the same time: a periodic orphan token. The first few prep steps will sound familiar from the Zabbix paragraph above. For example's sake let's assume we want the `remco` file generator (see [github.com/HeavyHorst/remco](https://github.com/HeavyHorst/remco)) to have Vault access:
* Create an entity `remco` without a policy
* Add an alias of type `userpass` also named `remco` to the entity
@ -214,11 +214,11 @@ Log in to Vault with `userpass` and an account that has `write` access to `auth/
```
curl --silent --location --header 'X-Vault-Token: <token>' \
--request POST \
--data '{"policies":["remco"],"renewable":true,"ttl":"768h","display_name":"remco populates config files with secrets"}' \
--data '{"policies":["remco"],"period":"768h","display_name":"remco populates config files with secrets"}' \
'https://f.q.d.n/v1/auth/token/create-orphan'
```
We're choosing our `ttl` of 768 hours on purpose. This equals 32 days which is the default server setting in `max_lease_ttl` that any token created by a non-`root` user can have. Feel free to reconfigure this server-side on your end and to pick a longer `ttl` value as needed. For our use case 32 days is plenty of time.
Note that we do not specify `"renewable":true` as periodic tokens are implicitly renewable. We also don't specify `"ttl":"768h"` or similar values as the period in our periodic token will override a time-to-live value anyway rendering the time-to-live irrelevant. We can get our desired token by simply specifying for example `"period":"768h"`.
Write down the generated `client_token`.