Vault administrator user

Vault
1

Hello,
I want to create an administrator user (we want to avoid root token) to perform administrative tasks in Vault. Based on your experience, what privileges should this user have? Is there any example in official documentation that you know?
Thanks

2

Hi @glisav - this is very much a “it depends” scenario. Should your Vault admins be able to perform all actions as if they were using the root token? If so you could simply copy the root policy into a new policy for your admins.

That policy can be a bit to permissive, so will then start to come down to what actions the admins should be able to perform. There could also be situations where there are different admins/responsibilities. Is there more than one admin group? Maybe one responsible for IAM, another for managing secret access/plugin access? That will be based on your plugin configuration, paths used, etc. It may be helpful still to start from the root policy and add/replace paths that match your environment.

1 Like
3

Hi @jonathanfrappier
Thank you for your reply!

The concept would be to have only one admin group that should have access to perform all the operations tasks: enabling/disabling/configuring authentication methods, enabling/disabling secret engine mounts and other than that having access on endpoints that are needed to troubleshoot or identify issues.
I am not sure if I was clear, but still don’t know what to include on that policy.

4

If they need to do literally everything, then something like this (essentially the root policy)

path "*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

Path being set to “*” means all paths, and sudo being present in the capabilities means any root protected endpoint is accessible.

I would highly recommend setting up MFA for all users, but definitely those with that policy.

As you get more comfortable with Vault, I would suggest creating more restrictive policies and have separate “root” accounts (e.g. glisav_root) that are more for advanced use cases and accounts with more restrictive policies that allow them to still manage things at the paths you use regularly.

For example, your glisav_root users has the policy above, but glisav has a policy that does not include sudo, and paths are specific to your Vault config, maybe something like

path "auth/*" {
  capabilities = ["create", "list", "read", "update", "delete"]
}

path "secrets/data/*" {
  capabilities = ["create", "list", "read", "update", "delete"]
}

path "sys/policy" {
  capabilities = [ "create", "read", "update", "delete", "list" ]
}

path "pki/*" {
  capabilities = ["deny"]
}

This policy, for more regular admin use cases allows access to most things in your mounted plugins, allows creating/updating policies, but denies access to critical or root protected paths (replace that with whatever paths are critical and do not require regular access). Vault is deny by default, so that last path isn’t technically needed, since the policy doesn’t otherwise allow access, but may make life easier during an audit to show users are not accessing things that are critical to Vault.

Other things to consider beyond MFA and separate users:

  • Update your security policy to discuss actions the root user can perform vs the lower level admin can perform
  • What scenarios are acceptable to log in as their root account
  • Set the token_bound_cidrs setting available in many auth methods to ensure your admins are only authenticating from trusted locations
  • Configure alerts so you know when the elevated root level users log in.

One trick to admin level policies is if they allow people to write policies, you also need to configure your alerts to ensure there are no attempts to alter their admin policies.

Vault policies definitely seem to me to allow you be very custom, but the trade-off is it’s hard to say some example policy will fit all your needs.