Structuring Vault data
This documentation is about vault.sikt.no (also available under its old name vault.uninett.no). vault.unit.no will be merget into vault.sikt.no.
This describes the current broad layout of our Vault data. It will need to evolve and possibly be restructured as Vault gets increased use from different teams and services.
Layout
Vault data has a tree/directory structure, where the leaf nodes contain (one or more) key/value pairs. At the moment the layout is primarily service oriented, but a lot of services are found under a top-level department node. There are a few top-level paths that have special purposes:
gitlab: This tree reflects the structure in GitLab. Projects in GitLab have read access to its own path.productareas: Every product area has its own subtree here.service: Service/Application-specific secrets. For services/applications that need separate restrictions, has cross-productarea secrets, or other custom permissions.
The other top-level paths came from Uninett Vault and need to be there, because systems depend on it.
An example of this, is the secrets stored under /secret/system. They are for internal services and services which dont need access to be limited to a strict subset of the Uninett system department.
In addition root passwords are stored under /secret/system/machines for now.
Access to data
Access to Vault data is controlled by policies, which can then be
mapped to users and groups in the auth backend (LDAP). A policy grants
a combination of read, create, update, delete and admin rights on a
subtree. They are attached to a token at creation time. We maintain
our policies in the vault-policies repo found here:
https://gitlab.sikt.no/platon/vault
More information on how these policies work can be found here: