Only admins can create new policies (Check EWC Secret Manager - User Roles and Permissions) |
Policies define what a client is allowed to do inside OpenBao. Every token issued by an authentication method (OIDC, AppRole, Kubernetes, etc.) has one or more policies attached. These policies determine the exact capabilities a client has on specific paths within the tenancy namespace.
Policies are written in HCL and are the core mechanism for authorization in OpenBao.
A policy controls access by specifying:
Paths (e.g., kv/data/app/config)
Capabilities (e.g., read, list, update, delete)
Constraints (TTL, max TTL, etc.)
Policies do not authenticate users — they only define permissions. Authentication methods issue tokens, and tokens carry policies.
A typical policy contains one or more path blocks:
Codice
path "kv/data/app/*" {
capabilities = ["read", "list"]
}
path "kv/data/app/config" {
capabilities = ["create", "update"]
}
Key elements:
path — the secret engine path the rule applies to
capabilities — allowed operations
wildcards — * for multiple items, + for recursive matching
fine‑grained rules — different capabilities for different paths
read — retrieve a secret
list — list keys
create — write a new secret
update — modify an existing secret
delete — remove a secret
sudo — administrative operations
Policies are stored inside the tenancy namespace under:
Codice
sys/policies/acl/<policy-name>
They are managed using the CLI or API.
By default, every tenancy is provided with two policies for Kubernetes External Secret Operator (ESO): 


You can find these policies in the Policies section:
![]()
Create a file named my-policy.hcl:
Codice
path "kv/data/myapp/*" {
capabilities = ["read", "list"]
}
path "kv/data/myapp/config" {
capabilities = ["create", "update"]
}
Use the CLI:
bao policy write my-policy my-policy.hcl
This creates (or updates) the policy named my-policy.
bao policy read my-policy
For example, attach it to an AppRole:
bao auth approle role write my-role policies="my-policy"