Introduction
This article demonstrates a sample vault policy which can be used for administrative purpose by mapping the policy to administrative login methodologies.
Synopsis
Administrators usually need access to manage auth methods, policies, namespaces and secret engines; which can be achieved with below:
# Manage namespaces at root namespace level
path "sys/namespaces/*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
# List namespaces at root namespace level
path "sys/namespaces" {
capabilities = ["list"]
}
# Manage policies at root namespace level
path "sys/policies/acl/*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
# List policies at root namespace level
path "sys/policies/acl" {
capabilities = ["list"]
}
# Enable and manage secrets engines at root namespace level
path "sys/mounts/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
# List available secrets engines at root namespace level
path "sys/mounts" {
capabilities = [ "read" ]
}
# Enable and manage auth methods at root namespace level
path "sys/auth/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
# List available auth methods at root namespace level
path "sys/auth" {
capabilities = [ "read" ]
}
# Manage namespaces at child namespace level
path "+/sys/namespaces/*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
# List namespaces at child namespace level
path "+/sys/namespaces" {
capabilities = ["list"]
}
# Manage policies at child namespace level
path "+/sys/policies/acl/*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
# List policies at child namespace level
path "+/sys/policies/acl" {
capabilities = ["list"]
}
# Enable and manage secrets engines at child namespace level
path "+/sys/mounts/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
# List available secrets engines at child namespace level
path "+/sys/mounts" {
capabilities = [ "read" ]
}
# Enable and manage auth methods at child namespace level
path "+/sys/auth/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
# List available auth methods at child namespace level
path "+/sys/auth" {
capabilities = [ "read" ]
} If administrators are required to be allowed access to a certain secret engine or auth method as well, below is policy with sample name of auth method/secret engine.
#Manage secrets at engine named 'test-secret' in root namespace
path "test-secret/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
#Manage roles and users at auth named 'test-auth' in root namespace
path "auth/test-auth/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
#Manage secrets at engine named 'test-secret' in child namespace
path "+/test-secret/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
#Manage roles and users at auth named 'test-auth' in child namespace
path "+/auth/test-auth/*" {
capabilities = ["create", "read", "update", "delete", "list"]
} Disclaimer: The policy contents shared above are for demonstrative purpose with explanation of path structure and their interpretation in vault. This should only be referred as an example for curating the policy as per organisation's requirement.
Additional notes:
- Attach
defaultpolicy along with this policy to the administrative login methodologies. - Add additional paths with
+/+if there is one level of nesting namespaces. Similarly, if there are two levels of nesting of namespaces, add paths with+/+/+at start. Example you can create a namespace named ns2 within an existing namespace named ns1. In this case the policy to list available secrets engines at namespace level ns2 would be :
path "+/+/sys/mounts" {
capabilities = [ "read" ]
}Similar paths for activity would be required individually. You can replace + with specific name of the namespace, but in that case you will need to modify the policy every time a new namespace is added in your environment.
References: