secure k8 s

Policies

Summary: Policies are how authorization works in OpenBao — declarative HCL grants on paths and operations. Deny by default, attached to tokens via auth-method role/group mappings.

Sources: raw/docs/concepts/policies.md.

Last updated: 2026-05-19

Core idea

Everything in OpenBao is path-based, and policies grant capabilities (read, create, update, delete, list, sudo, deny) on those paths. An empty policy grants nothing — there is no implicit allow (source: raw/docs/concepts/policies.md).

Workflow

  1. Operator configures an auth method (e.g. LDAP).
  2. Operator writes a policy in HCL and uploads it by name.
  3. Operator maps auth-method identities to policies — e.g. LDAP group dev → policy readonly-dev.
  4. When a user authenticates, OpenBao mints a token with the resulting policies attached.
  5. Every subsequent request is checked against the token’s policies (source: raw/docs/concepts/policies.md).

A token’s effective policy set is the union of all policies attached to it. Capabilities on a given path are also unioned — except deny, which always wins.

Special policies

  • root — implicit allow on everything. Only attached to root tokens.
  • default — attached to every non-orphan token unless explicitly excluded. Grants minimal self-service paths.

Relation to identity

Policies can be attached not just to tokens but to identity entities and groups. Group policies are inherited transitively, so granting a policy to an LDAP group’s mirrored identity group flows down to all members (source: raw/docs/concepts/policies.md, raw/docs/concepts/identity.md).

  • auth — auth methods produce the role/group strings policies bind to
  • tokens — tokens carry the policy set at request time
  • identity — entities/groups can hold policies of their own
  • namespaces — policies are namespace-scoped