Policy

• Determine who should access secrets

• provide operators a way to permit or deny access to certain paths or actions within Vault (RBAC)

• written in declarative statements and can be written usin JSON or HCL

• Always follow the principal of least privilege when writing policies

• Policies are deny by default (implicit deny)

• no policy = no authorization

• Policies support an explicit deny that takes precedence over any other permission

• Policies are attached to a token. A token can have multiple policies

• Policies are cumulative and capabilities are additive

• Root policy is created by default - superuser with all permissions

  • cannot change nor delete root policy

  • attached to all root tokens

• default policy is created by default - provides common permissions

  • can change this policy but cannot delete it

  • attached to all non-root tokens by default (can be removed if needed)

• Permissions for Vault backend function live at the sys/ path

• Users/admins will need policies that define what they can do within Vault to administer Vault itself

  • Unsealing

  • Changing Policies

  • Adding Secret backends

  • Configuring database configurations

  # Configure License
  path "sys/license" {
    capabilities = ["read", "list", "create", "update", "delete"]
  }
  
  # Initilize Vault
  path "sys/init" {
    capabilities = ["read", "create", "update"]
  }
  
  # Configure UI in Vault
  path "sys/config/ui" {
    capabilities = ["read", "list", "update", "delete", "sudo"]
  }
  
  # Allow rekey of unseal keys for Vault
  path "sys/rekey/*" {
    capabilities = ["read", "list", "update", "delete"]
  }
  
  # Allow rotation of master key
  path "sys/rotate" {
    capabilities = ["update", "sudo"]
  }
  
  # Allow Vault Seal
  path "sys/seal" {
    capabilities = ["sudo"]
  }

Managing policies using CLI

• vault policy {list|fmt|read|write|delete}

• vault policy read default

• vault policy read root: this command is invalid although root policy exists

• vault policy write admin-policy /tmp/admin.hcl: Create policy from admin.hcl file

• vault token create -policy="web-app": associate policy to token

Managing policies using API

• curl --header "X-Vault-Token: $token" --request PUT --data @payload.json http://$host/v1/sys/policy/webapp: Create webapp policy

#payload.json file
{
    "policy": "path \"kv/apps/webapp\" { capabilities...}"
}

Examples of Policy Paths

Alt text

• Root-protected paths

  • many paths in Vault require a root token or sudo capability to use

  • these paths focus on important/critical paths for Vault or plugins

• Example of root-protected paths

  • auth/token/create-orphan (create an orphan token)

  • pki/root/sign-self-issued (sign a self-issued certificate)

  • sys/rotate (rotate the encryption key)

  • sys/seal (manually seal vault)

  • sys/step-down (force the leader to give up active status)

  path "sys/rotate" {
    capabilities = ["sudo"]
  }
  path "sys/seal" {
    capabilities = ["sudo"]
  }
  path "sys/step-down" {
    capabilities = ["sudo"]
  }

• The glob (*) is a wildcard and can only be used at the end of a path

• The plus (+) supports wildcard matching for a single directory in the path, can be used multiple time, e.g. /secret/+/+/db

  • secret/+/db: matches secret/db2/db or secret/app/db

• ACL templating: use variable replacement {{ }} in some policy strings with values available to the token

path "secret/data/{{identity.entity.id}}/*" {
    capabilities = ["create", "update", "read", "delete"]
}
path "secret/metadata/{{identity.entity.id}}/*" {
    capabilities = ["list"]
}

Vault Policy Capabilities

• Capabilities define what we can do

• A list of string even when it has only 1 item

Capability	HTTP Verb
Create	POST/PUT
read	GET
update	POST/PUT
delete	DELETE
list	LIST

• Note:

  • create: if the key does not exist

  • update: if the key exists and it needs to be replaced or updated

  • write is not a valid capability

Capability	Description
sudo	Allows access to path that are root-protected
deny	Disallows access regardless of any other defined capabilities

Example Policy 1

• Access to generate database credentials at database/creds/db01

• Create, Update, Read and Delete secrets stored at kv/apps/dev-app01

path "database/creds/db01" {
    capabilities = ["read"]
}
path "kv/apps/dev/app01" {
    capabilities = ["create", "read", "update", "delete"]
}

Example Policy 2

• Access to read credentials after the path kv/apps/webapp

• Deny access to kv/apps/webapp/super-secret

path "kv/apps/webapp/*" {
    capabilities = ["read"]
}
path "kv/apps/webapp/super_secret" {
    capabilities = ["deny"]
}

• Note:

  • this policy doesn't allow access to kv/app/webapp, just those under it

Example Policy 3

• Below policy doesn't permit to browse to kv/apps/webapp in the UI because the policy only permits list at the listed path, not the paths leading up to the desired path

path "kv/apps/webapp/*" {
    capabilities = ["read", "list"]
}

Testing Policies

• When creatin policies, ensure to test it to make sure it fulfills the requirements

• Requirement:

  • Clients must be able to request AWS credential granting read access to a S3 bucket

  • Read secrets from secret/apikey/Google

$ vault token create -policy="web-app"
 
# Authenticate with the newly generated token
$ vault login $token

# Make sure that the token can read
$ vault read secret/apikey/Google

# This should fail
$ vault write secret/apikey/Google key="ABCED12345"

# Request a new AWS credentials
$ vault read aws/creds/s3-readonly