Skip to content
Latchkey

Vault "* permission denied" on a specific path in CI

CI can read some Vault paths but one specific path returns "* permission denied". The token is valid; its policy simply does not grant the needed capability on that path, or the glob does not reach it.

What this error means

Reads from secret/data/ci/shared work, but secret/data/ci/prod fails with "Code: 403" and "* permission denied" in the errors list.

vault
Error making API request.

URL: GET https://vault.example.com/v1/secret/data/ci/prod/db
Code: 403. Errors:

* permission denied

Common causes

The policy glob does not extend to this subpath

A policy on secret/data/ci/shared/* does not match secret/data/ci/prod/*. Vault matches paths literally with + and * semantics, not as arbitrary prefixes.

Only create/update is granted, not read

A pipeline that writes secrets may have create/update but not read on the path, so the read step is denied.

How to fix it

Widen or add the missing path rule

  1. Identify the exact denied path from the URL in the error.
  2. Add a policy rule that matches it, using + for a single segment or * for the tail.
  3. Reattach and re-run.
ci-db.hcl
path "secret/data/ci/+/db" {
  capabilities = ["read"]
}

Check effective capabilities on the path

Ask Vault what the token can actually do on the path to see the gap.

Terminal
vault token capabilities secret/data/ci/prod/db

How to prevent it

  • Prefer explicit per-environment path rules over one broad glob.
  • Separate read policies from write policies so a writer role is not accidentally a reader.
  • Validate new paths with vault token capabilities in a dry run.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →