web/lukegbcom: add a diagram to illustrate the token hierarchy
This commit is contained in:
parent
675b65b5da
commit
a3ef78701e
2 changed files with 32 additions and 0 deletions
|
@ -140,6 +140,37 @@ to `kv/server/$HOSTNAME`, and to issue ACME certificates, and the Nix binary
|
|||
cache credentials. They also have the power to issue subtokens with
|
||||
lesser-power than themselves.
|
||||
|
||||
### ...how about as a diagram?
|
||||
|
||||
The description of the above might be a little confusing in terms of the Vault
|
||||
policy hierarchy, so here's an example:
|
||||
|
||||
![Diagram illustrating token hierarchy](token-hierarchy.svg)
|
||||
|
||||
1. Vault issues the Vault Agent on `clouvider-lon01` a token. This token
|
||||
includes the Vault policies `default`, `server`, `server-user`,
|
||||
`server/clouvider-lon01`, `server/clouvider-lon01/app/gitlab-runner`, and
|
||||
`app/deployer`. The app policies (`server/clouvider-lon01/app/gitlab-runner`
|
||||
and `app/deployer`) are attached because the server configuration in the
|
||||
repository states that those two applications are intended to be deployed on
|
||||
that server.
|
||||
2. `secretsmgr` on `clouvider-lon01` uses the token held by the Vault Agent
|
||||
directly to refresh any TLS or SSH certificates needed by the server.
|
||||
3. `tokend` on `clouvider-lon01` has no token of its own, but uses the one held
|
||||
by the Vault Agent to issue app- or user-specific sub-tokens, with a subset
|
||||
of the policies attached to the initial token.
|
||||
4. `gitlab-runner` on `clouvider-lon01` talks to `tokend`, which issues it a
|
||||
subtoken with **just** the `default` and
|
||||
`server/clouvider-lon01/app/gitlab-runner` policies.
|
||||
5. `deployer` on `clouvider-lon01` also talks to `tokend`, but it gets a
|
||||
different subtoken which instead has the `default` and `app/deployer`
|
||||
policies.
|
||||
6. My own personal user account, `lukegb`, can also talk to `tokend` to get a
|
||||
subtoken with the `default` and `server-user` policies. This token is very
|
||||
limited compared to a standard `user`-policy token, which needs to be issued
|
||||
by using the Vault API directly to authenticate as a user based on some
|
||||
OpenID Connect credentials.
|
||||
|
||||
## Vault App ID credentials
|
||||
|
||||
I use the "App ID" mode in Vault to provision secrets to servers; when setting
|
||||
|
|
File diff suppressed because one or more lines are too long
After Width: | Height: | Size: 276 KiB |
Loading…
Reference in a new issue