Policies

Vault policies permit or deny access to certain paths or actions within vault (RBAC).
Provides granular control over who accesses what.
Policies are default deny (Implicit deny), which means no policy no access.
Policies are attached to tokens and tokens can have multiple policies attached.
Policies are cumulative and capabilities are additive.

Policy is written in declarative statement and can be written using JSON or HAL.
No one can read root policy, it can be listed but cant be read, it just provides the root permissions.

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

Managing Policies

Command	Effect
`vault policy` `list`	List all policies
`vault policy` `write POLICY_NAME` `POLICY_FILE_PATH`	Create a policy
`vault policy` `read POLICY_NAME`	Read a policy
`vault policy` `delete POLICY_NAME`	Delete a policy
`vault policy` `fmt POLICY_FILE_PATH`	Formats policy file according to syntax

Anatomy of Policy

Structure of policy looks like:

path "PATH" {
    capabilities = ["LIST_OF_CAPABILITIES"]
}
path "PATH" {
    capabilities = ["LIST_OF_CAPABILITIES"]
}
path "PATH" {
    capabilities = ["LIST_OF_CAPABILITIES"]
}
...

Example:

path "kv/data/apps/cicd" {
    capabilities = ["read", "update", "delete"]
}
path "sys/policies/*" {
    capabilities = ["create", "update", "list", "delete"]
}
path "aws/creds/webapp" {
    capabilities = ["read"]
}

Path

There are root protected paths which are available to only root user and must not be exposed to other users unless until required, some of them are here:
- auth/token/create-orphan
- pki/root/sign-self-issued
- sys/rotate
- sys/seal
- sys/step-down
This is how to provide access to users to protected paths:

path "PROTECTED_PATH" {
    capabilities = ["sudo"]
}

Customizing paths

`*`

* is a wildcard and can only be used at the end of at the end of a path. It can be used to signify anything “after” a path or as a pattern. Ex: /.../.../...* or /.../.../*.
It also matches all the sub paths and sections beyond it as well.

`+`

+ supports wildcard matching for single section in the path.
Can be used in between the path.
Can be used multiple times. Ex: /.../+/... or /.../+/+/.../+/....

ACL Templating

Use variable replacement in some policy strings with values available to the token.
Define policy paths using double curly brackets.

path ".../{{VARIABLE_REFERENCE}}/*" {
    capabilities = ["LIST_OF_CAPABILITIES"]
}

A list of some variables

Parameter	Description
`identity.entity` `.id`	The entity’s ID
`identity.entity` `.name`	The entity’s name
`identity.entity` `.metadata.<<metadata key>>`	Metadata associated with the entity for the given key
`identity.entity` `.aliases.<<mount accessor>>` `.id`	Entity alias ID for the given mount
`identity.entity` `.aliases.<<mount accessor>>` `.name`	Entity alias name for the given mount
`identity.entity` `.aliases.<<mount accessor>>` `.metadata.<<metadata key>>`	Metadata associated with the alias for the given mount and metadata key
`identity.groups` `.ids.<<group id>>.name`	The group name for the given group ID
`identity.groups` `.names.<<group name>>.id`	The group ID for the given group name
`identity.groups` `.ids.<<group id>>.metadata` `.<<metadata key>>`	Metadata associated with the group for the given key
`identity.groups` `.names.<<group name>>` `.metadata.<<metadata key>>`	Metadata associated with the group for the given key

Stay updated with these at 🌐

In case of there are N users and there is requirement to give them a storage of their own at particular secret engine.

path ".../{{identity.entity.id}}/*" {
    capabilities = ["LIST_OF_CAPABILITIES"]
}

Capabilities

create,list,read,update,delete are capabilities that work as per their names.
sudo capability allows access to protected paths.
deny disallows access irrespective of any other granted access and capabilities.