Capability
An operation such as read, create, update, delete, list, sudo, or patch.
Chapter 5 of 16 · Human user · Priya
Turn permission denied into a precise capability diagnosis without broadening access blindly.
Chapter 4 complete; know the exact operation and redacted API path being tested.
Priya can diagnose an expected 403 from path and capability evidence instead of requesting broad access.
| Owner | Consumer-facing responsibility |
|---|---|
| You own | Defines consumption, validation, reload, and stop-using behavior. |
| Platform team owns | Provides trusted runtime identity, protected delivery, network, and telemetry. |
| Vault owns | Operates auth mounts, policies, engines, audit, and recovery. |
An operation such as read, create, update, delete, list, sudo, or patch.
A policy stanza matching API paths, not CLI wording.
Anything not explicitly allowed is denied.
Matching a client failure to server audit metadata by time and request context.
source learn-vault/.runtime/learner.env
vault token capabilities lockbox-kv/data/orders-api
vault token capabilities lockbox-kv/metadata/orders-api
vault kv metadata get -format=json lockbox-kv/orders-api | jq '.data.current_version'| Symptom | 403 permission denied on a KV read. |
|---|---|
| Likely causes | Policy covers the friendly path instead of KV v2 data, role mapping is wrong, or list targets the wrong route. |
| Inspect safely | Query capabilities for the exact API path and capture status plus timestamp. |
| Do not print | Token, request payload, secret response, or raw audit record. |
Break it: Attempt the intentionally denied KV delete.
Fix it: Query capabilities for the exact API path; retain the narrow read policy.
Escalate with time, endpoint, auth path, role, mount, namespace when relevant, status code, request ID, and sanitized error class. Never attach a credential or response body.
labs/bootstrap owns the disposable server, auth mounts, policies, roles, and engines; learner actions begin after setup.
$0; local containers only
Run labs/bootstrap/setup.sh and source .runtime/learner.env unless the chapter lab says AppRole alone is sufficient.
Prove an allowed metadata operation and a denied delete, then inspect the bootstrap policy source.
source learn-vault/.runtime/learner.env
test "$(vault token capabilities lockbox-kv/metadata/orders-api)" = read
if vault kv delete lockbox-kv/orders-api >/dev/null 2>&1; then
echo "unexpected delete permission"; exit 1
else
echo "delete denied as expected"
fi
sed -n '/lockbox-kv\/metadata/,/}/p' learn-vault/labs/bootstrap/policies/lockbox-learner.hcl
Complete every item in the Verify section using metadata-only evidence; no secret value appears in terminal output or tracked files.
Use the Failure drill and Break it / fix it evidence fields. Stop before broadening policy, weakening identity or TLS checks, or copying secret-bearing diagnostics.
No Vault data changed. Unset VAULT_TOKEN if the shell will be shared.
The Lockbox access request names exact API paths and capabilities, making review and diagnosis reproducible.
Deny.
KV v2 operations include data or metadata path segments.
On the metadata path.
Identity role, exact redacted API path, capability, and reason.
A good 403 investigation narrows the contract; it does not widen policy until the error disappears.