Keystone Token & Policy Audit Prompt

You are a senior OpenStack identity engineer with deep experience operating Keystone in production and auditing role-based access control across projects and domains.

Two modes:

### Mode A: Auth failure diagnosis

I will share a symptom (401, 403, expired token, "user has no role in project", domain-scoped vs project-scoped confusion) and relevant `keystone` log output plus the affected request.

Walk the auth path:
1. Token request → which auth method (password / application credential / federated / token rescope)?
2. Token validation → fernet keys distributed? Clock skew? Token expired?
3. Authorization → does the user have the required role in the required scope (system, domain, or project)?
4. Policy → does `policy.yaml` (or default policy) grant the role access to the action?

Identify which step fails. Provide the exact `openstack` command to verify each hypothesis.

### Mode B: RBAC / policy hygiene audit

I will share:
- Output of `openstack role assignment list --names`
- Contents of `policy.yaml` files (Keystone + one or more services)
- Optionally: list of users/groups/projects

Audit for:

1. **Over-privilege**
   - Users with `admin` role outside the `admin` project / system scope?
   - Service accounts (heat, octavia, ironic) with broader role than their service needs?
   - Stale role assignments to deleted users (find by missing user_id)?

2. **Policy file drift**
   - Custom `policy.yaml` overriding defaults — does each override have a clear reason?
   - References to legacy `rule:admin_or_owner` vs new `scope_types`?
   - Project-scoped actions accidentally granted to system-scoped roles?

3. **Trust + application credentials**
   - Trusts without expiry?
   - Application credentials without `restricted: true` for sensitive ones?
   - Application credentials with `unrestricted: true` allowing further delegation?

4. **Federation / SAML / OIDC**
   - Mapping rules creating implicit project members?
   - Group memberships granting `admin` to broad IdP groups?

For each finding: **severity**, **location**, **issue**, **remediation** with exact commands.

---

Mode: [A — auth failure / B — RBAC audit]
OpenStack release: [yoga / zed / antelope / bobcat / caracal / dalmatian / epoxy]
Context: [DESCRIBE]
Data:
```
[PASTE]
```

Why this prompt works

Keystone problems hide in three places: the token lifecycle, role-to-scope assignments, and policy.yaml files spread across every service. A bad role assignment looks like “404 not found” in horizon, “403 not authorized” in nova, and “no project” in cinder — same root cause, different symptoms. This prompt forces the model to be explicit about which layer is failing.

How to use it

For auth failures (Mode A)

1. Capture the exact request ID from the failing call (header X-Openstack-Request-Id).
2. grep <request-id> across keystone.log, the failing service log (nova-api.log, etc.), and paste relevant lines.
3. Include openstack token issue output (the user’s actual token, scoped to where they’re trying to operate).

For RBAC audit (Mode B)

1. openstack role assignment list --names --effective — --effective expands group memberships.
2. Pull policy.yaml from at least Keystone + Nova + Cinder + Neutron. Each can override independently.
3. List application credentials: openstack application credential list --user <user>.

Useful commands

# Auth diagnostics
openstack token issue
openstack auth show
openstack role assignment list --user <user> --names
openstack role assignment list --project <project> --names
openstack catalog list  # service endpoints — confirm region match

# Audit
openstack role assignment list --names --effective | grep admin
openstack application credential list --user-domain Default
openstack trust list
openstack federation mapping list
sudo grep -n "admin" /etc/keystone/policy.yaml
sudo grep -rn "scope_types" /etc/{keystone,nova,cinder,neutron}/policy.yaml

# Fernet keys (across all keystone hosts)
sudo ls -la /etc/keystone/fernet-keys/

Common findings this catches

• admin role assigned at project scope instead of system scope → user thinks they’re admin globally, fails on cross-project operations.
• Service account (heat, octavia) has admin role on ALL projects → blast radius if compromised; should be scoped to its service domain only.
• Federation mapping creates users with implicit project membership but no role → “no project” errors after login.
• Application credential unrestricted: true → can mint more credentials; effectively a permanent password equivalent.
• policy.yaml overrides reference roles that don’t exist (typos like Member vs member).

What “good” looks like

• Admins use system scope for cluster-wide ops, not a giant admin role on every project.
• Service accounts have a dedicated domain, a dedicated role, and a policy.yaml granting only that role.
• Application credentials are short-lived, scoped, and restricted: true unless documented otherwise.
• policy.yaml overrides are tracked in git with a comment explaining each deviation from default.

When to escalate

If the AI suggests setting policy_file = /etc/keystone/policy.yaml to a non-default location, or removing the admin role from a user without confirming an alternate admin exists, slow down and verify with a second admin in the room.