Vault Policy Generator

Vault policies are HCL (or JSON) documents that describe what paths in Vault a token can access and what capabilities it has. Policies follow the principle of least privilege — tokens get no permissions by default. Policies are attached to tokens via auth method roles. For example, a Kubernetes service account mapped to a Vault role can only access the secrets your policy allows.

create — POST/write new data. read — GET data. update — PUT/PATCH existing data. delete — DELETE data. list — enumerate keys at a path (does not read values). sudo — access root-protected paths (rare, use sparingly). deny — explicitly deny access, overriding any allows. For read-only access, use [read, list]. For full access, use [create, read, update, delete, list].

Vault paths support two wildcards: * matches any sequence of characters within a single path segment (e.g. secret/data/myapp/* matches secret/data/myapp/db-password but not secret/data/myapp/db/password). The + glob matches exactly one path segment. Prefix matching with a trailing * is the most common pattern — e.g. secret/data/prod/* grants access to all secrets under the prod namespace.

deny overrides all other capabilities, including those from other policies attached to the same token. It's used to explicitly block access to sensitive sub-paths when a parent wildcard would otherwise grant access. For example, you might grant secret/data/* with [read] but then add secret/data/admin/* with [deny] to carve out admin secrets.

Save the HCL to a file (e.g. policy.hcl), then run: vault policy write my-policy policy.hcl. To attach it to a role (e.g. Kubernetes auth): vault write auth/kubernetes/role/my-role bound_service_account_names=my-sa bound_service_account_namespaces=default policies=my-policy. To attach to AppRole: vault write auth/approle/role/my-role policies=my-policy.

No. All HCL generation runs entirely in your browser using JavaScript. Your policy configuration never leaves your machine.