Introduction
This article will provide instructions for writing a policy which will limit the creation of namespace within a namespace as well as within admin namespace. However the policy will allow the capabilities for creation of other mounts(auth methods, secret engines etc).
Prerequisites
- HCP Vault cluster
- Access to admin token
Steps
-
Access your HCP Vault cluster via CLI. Please ensure to export the VAULT_ADDR, VAULT_NAMESPACE variable in order to ensure that the commands will work with HCP Vault.
- export VAULT_ADDR="<YOURVAULTCLUSTER>";
- export VAULT_NAMESPACE=admin
-
vault login <YOURADMINTOKEN>
-
Create a namespace - namespaceA within admin namespace :
vault namespace create namespaceA
The path where namespaceA is created is “admin/namespaceA”. This is because HCP Vault starts with the admin namespace.
The hcp-root policy is only available in the admin namespace and it provides full access to the admin namespace and any additional namespaces, secret engines, and auth methods created in HCP Vault. Its usage should be limited.
The default policy is by default attached to all authentical resources and provides some basic access to allow resources to perform token lookups or access to cubbyhole secrets engine for any individual.
-
Create a custom policy say my-policy
# Allows ability to only read and list namespaces within Admin Namespace
path "sys/namespaces/*" {
capabilities = ["read", "list"]
}
# Allows all access to specific Namespace
path "namespaceA/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
# Restricts creation of namespace under namespaceA
path "namespaceA/sys/namespaces/*" {
capabilities = ["deny"]
}
Please Note : The deny capability will always take precedence regardless of any other defined capabilities, including sudo. Here, despite of providing create capability to “namespaceA”, deny capability will not allow creation of any child capability under namespaceA.S