☁️ OpenStack Error: 'You are not authorized to perform the requested action' (403 Policy/RBAC)

Exact Error Message

$ openstack server list --all-projects
You are not authorized to perform the requested action: identity:list_projects.
(HTTP 403) (Request-ID: req-9c1f2b7a-4e2d-4c8a-9b1e-6f0a2d3c4e5f)

You may also see the shorter Nova/Neutron variant when a policy check fails on a specific API:

Policy doesn't allow os_compute_api:servers:index:get_all_tenants to be performed.
(HTTP 403)

Both are HTTP 403 (Forbidden) responses generated by Keystone-backed policy enforcement (oslo.policy), not authentication failures.

What It Means

A 403 means you authenticated successfully — Keystone accepted your credentials and issued a token — but the token does not carry the roles or scope required by the target API’s policy rule. Every OpenStack service ships a policy.yaml (formerly policy.json) that maps API actions to rules such as role:admin or role:reader. When the rule evaluates to false for your token, the service returns 403.

This is distinct from a 401 (“The request you have made requires authentication”), which means the token itself is missing, expired, or invalid. A 403 says “we know who you are, you just are not allowed to do this.”

Common Causes

• Your token is project-scoped but the action requires a system-scoped or admin-role token (e.g. --all-projects, listing all users).
• The user is missing the required role assignment on the project or domain.
• A custom policy.yaml was deployed that is stricter than the default rules.
• Scope mismatch: you have admin on project A but are operating against project B.
• Secure RBAC (the reader/member/admin model with system scope) is enabled and your token lacks the correct scope.
• The service catalog endpoint points at a different region/project than where your role is assigned.

Diagnostic Commands

Confirm which roles your current token actually carries and its scope:

openstack token issue -f yaml

List the role assignments for your user across projects and domains:

openstack role assignment list --user "$OS_USERNAME" --names

Check whether the role you expect exists on the project you are targeting:

openstack role assignment list --project my-project --names

Inspect the offending policy rule on the API node (Keystone shown; each service has its own file):

grep -R "identity:list_projects" /etc/keystone/policy.yaml
oslopolicy-policy-generator --namespace keystone   # dump effective defaults

Confirm what the server actually logged for the denial:

sudo journalctl -u devstack@keystone --no-pager | grep -i "403\|not authorized"
# package installs: /var/log/keystone/keystone.log

Step-by-Step Resolution

1. Verify the exact action name in the error (identity:list_projects, os_compute_api:servers:index:get_all_tenants, etc.). The prefix tells you which service’s policy file to inspect.

2. Check whether your token has the needed role. If openstack token issue shows only member but the rule needs admin, that is the problem.

3. Grant the missing role. For a project-scoped admin action:

openstack role add --project my-project --user alice admin

4. If the API requires system scope under secure RBAC (common for cross-project reads on recent releases), grant and use a system-scoped token:

openstack role add --system all --user alice admin
openstack --os-system-scope all --os-username alice token issue

5. Re-authenticate so a fresh token picks up the new assignment (existing tokens are not retroactively upgraded):

unset OS_TOKEN
openstack server list --all-projects

6. If policy itself is wrong, edit the service’s policy.yaml to a correct rule and restart the API. For example, to allow the reader role to list all tenants’ servers:

"os_compute_api:servers:index:get_all_tenants": "role:reader and system_scope:all"

sudo systemctl restart devstack@n-api    # or nova-api on package installs

7. Confirm the action now succeeds and returns 200 instead of 403.

Prevention

• Keep policy.yaml files under version control and review changes; an over-broad or over-strict rule is easy to miss.
• Prefer role assignments over editing policy — grant admin/reader rather than rewriting rules whenever possible.
• Adopt the secure RBAC model (reader/member/admin with system vs project scope) consistently across services so scoping is predictable.
• Document which operational tasks require system scope so operators request the right token up front.
• Use short-lived scoped credentials in automation and re-issue tokens after role changes.

Related Errors

• The request you have made requires authentication. (HTTP 401) — missing/expired token, not a permissions problem.
• Could not find project: <id> (HTTP 404) — scoping to a project that does not exist.
• Failed to validate token (HTTP 404) — Keystone could not validate the token (fernet/cache issue).
• Policy doesn't allow <action> to be performed — the same 403 surfaced by Nova/Neutron/Cinder policy engines.

Frequently Asked Questions

Is a 403 an authentication failure? No. A 403 means you are authenticated but not authorized; a missing/expired token produces a 401 instead. Fix 403s with role or policy changes, not credentials.

Why does my new role not take effect immediately? Existing tokens are cached and are not upgraded when you add a role. Unset your current token and re-authenticate to mint a fresh one that carries the new assignment.

What is system scope and when do I need it? Under secure RBAC, cross-project and infrastructure-wide actions require a --os-system-scope all token rather than a project-scoped one. If an --all-projects read fails with 403 despite having admin on your project, request a system-scoped token.

How do I know which policy rule blocked me? The action name in the error (e.g. identity:list_projects) maps directly to a key in that service’s policy.yaml. Grep for it to see the required rule. For prompt-driven RBAC debugging, browse the OpenStack prompts.

Can I just make the policy permissive to unblock everyone? You can, but loosening rules removes tenant isolation guarantees. Prefer targeted role grants. For more identity and access patterns, see the OpenStack guides.