Policy Management

Overview

Polystack services enforce role-based access control through policy files. Each service has a policy.yaml (or policy.json) file that maps API operations to role requirements. The default policies follow the principle of least privilege — admin gets full access, member gets project-scoped CRUD, and reader gets read-only access. This guide covers viewing default policies, creating custom roles, writing per-service overrides, and applying changes safely.

Administrator Access Required — This operation requires the admin role. Contact your Polystack administrator if you do not have sufficient permissions.

Default Policy Overview

Polystack ships with three built-in roles and a set of default policies enforced across all services:

Role	Typical Policy Permissions
`admin`	Full access to all APIs including administrative endpoints
`member`	Project-scoped create, read, update, delete operations
`reader`	Project-scoped read-only access

The admin role implies member, which implies reader — so each role inherits the permissions of those below it.

Policy files use oslo.policy syntax. Rules can reference roles, project context, object ownership, and system scope. You only need to define overrides — unspecified rules use the service’s compiled-in defaults.

Policy File Locations

Each Polystack service reads its policy file from inside its container. Overrides are placed in /etc/ironcore/<service>/ on the host and deployed by the deployment console:

Service	Policy Override Path	Container Path
Compute (Nova)	`/etc/ironcore/nova/policy.yaml`	`/etc/nova/policy.yaml`
Block Storage (Cinder)	`/etc/ironcore/cinder/policy.yaml`	`/etc/cinder/policy.yaml`
Networking (Neutron)	`/etc/ironcore/neutron/policy.yaml`	`/etc/neutron/policy.yaml`
Image (Glance)	`/etc/ironcore/glance/policy.yaml`	`/etc/glance/policy.yaml`
Identity (Keystone)	`/etc/ironcore/keystone/policy.yaml`	`/etc/keystone/policy.yaml`
Orchestration (Heat)	`/etc/ironcore/heat/policy.yaml`	`/etc/heat/policy.yaml`
Object Storage (Swift)	`/etc/ironcore/swift/policy.yaml`	`/etc/swift/policy.yaml`
DNS (Designate)	`/etc/ironcore/designate/policy.yaml`	`/etc/designate/policy.yaml`
Key Manager (Barbican)	`/etc/ironcore/barbican/policy.yaml`	`/etc/barbican/policy.yaml`
Load Balancer (Octavia)	`/etc/ironcore/octavia/policy.yaml`	`/etc/octavia/policy.yaml`

Start with an empty override file and add only the rules you need to change. All other rules fall back to the service’s built-in defaults.

Custom Roles and Per-Service Policies

Custom roles are names you create in Keystone. They have no permissions by default — you must explicitly grant them permissions in each service’s policy file.

Workflow

Create the custom role in Keystone

Create a custom role

openstack role create network-operator

Verify

openstack role show network-operator

Find the policy rule names for the operations you want to allow

View the current built-in policy rules for the target service:

Show Nova's current effective policies

docker exec nova_api oslopolicy-policy-generator \
  --namespace nova \
  --output-file /tmp/nova-effective-policy.yaml
docker exec nova_api cat /tmp/nova-effective-policy.yaml | grep "flavor"

Show Neutron's current effective policies

docker exec neutron_server oslopolicy-policy-generator \
  --namespace neutron \
  --output-file /tmp/neutron-policy.yaml

Write the policy override file

Create /etc/ironcore/<service>/policy.yaml with only the rules you want to change:

/etc/ironcore/nova/policy.yaml — allow network-operator to list servers

"os_compute_api:servers:index": "role:network-operator or role:member"
"os_compute_api:servers:detail": "role:network-operator or role:member"

/etc/ironcore/neutron/policy.yaml — allow network-operator to manage ports

"create_port": "role:network-operator or role:admin"
"update_port": "role:network-operator or role:admin"
"delete_port": "role:network-operator or role:admin"
"get_port": "role:network-operator or role:member"

Apply the policy changes via the deployment console

Redeploy the affected service

ironcore-ansible deploy --tags nova
ironcore-ansible deploy --tags neutron

The new policy is active. Test with a user holding the custom role to verify enforcement.

Assign the custom role to users

Assign the custom role to a user on a project

openstack role add \
  --user alice \
  --project ops-project \
  network-operator

Policy Syntax Reference

Role-based rules

Common policy rule patterns

# Allow only admin role
"rule_name": "role:admin"

# Allow a custom role or admin
"rule_name": "role:network-operator or role:admin"

# Allow member and admin roles
"rule_name": "role:member or role:admin"

# Allow any authenticated user
"rule_name": "@"

# Deny everyone (disable an operation)
"rule_name": "!"

Project-scoped rules

Project ownership rules

# Allow only the resource owner or admin
"rule_name": "project_id:%(project_id)s or role:admin"

# Allow only within the same project
"rule_name": "project_id:%(target.project.id)s"

System-scope rules

System admin rules

# Require system-scope admin (cross-project operations)
"rule_name": "role:admin and system_scope:all"

Combining rules with aliases

Define reusable aliases at the top of the policy file to avoid repetition:

Policy with reusable aliases

# Define aliases
"is_admin": "role:admin"
"is_operator": "role:network-operator or role:admin"
"is_member": "role:member or role:admin"

# Use aliases in rules
"get_network": "rule:is_member"
"create_network": "rule:is_operator"
"delete_network": "rule:is_admin"

Per-Service Policy Examples

Compute (Nova)
Networking (Neutron)
Block Storage (Cinder)
Image (Glance)
Identity (Keystone)

/etc/ironcore/nova/policy.yaml

# Restrict flavor creation and deletion to admins only
"os_compute_api:os-flavor-manage:create": "role:admin"
"os_compute_api:os-flavor-manage:delete": "role:admin"

# Allow a custom 'compute-operator' role to resize instances
"os_compute_api:servers:resize": "role:compute-operator or role:admin"

# Restrict live migration to admins
"os_compute_api:os-migrate-server:migrate_live": "role:admin"

# Allow readers to list hypervisors (normally admin-only)
"os_compute_api:os-hypervisors:list": "role:reader or role:admin"

/etc/ironcore/neutron/policy.yaml

# Allow a 'network-operator' role to manage routers
"create_router": "role:network-operator or role:admin"
"update_router": "role:network-operator or role:admin"
"delete_router": "role:network-operator or role:admin"

# Allow QoS policy creation for network admins
"create_policy": "role:network-operator or role:admin"
"update_policy": "role:network-operator or role:admin"

# Restrict floating IP allocation to members and above
"create_floatingip": "role:member or role:admin"

/etc/ironcore/cinder/policy.yaml

# Restrict volume type creation to admins
"volume_extension:types_manage": "role:admin"

# Allow a 'storage-operator' to manage volume backups
"backup:create": "role:storage-operator or role:member"
"backup:delete": "role:storage-operator or role:admin"

# Allow members to set volume metadata
"volume:update_volume_metadata": "role:member or role:admin"

/etc/ironcore/glance/policy.yaml

# Restrict image deletion to image owner or admin
"delete_image": "rule:image_owner or role:admin"

# Allow a custom 'image-publisher' role to publicize images
"publicize_image": "role:image-publisher or role:admin"

# Restrict community image creation to members+
"communitize_image": "role:member or role:admin"

/etc/ironcore/keystone/policy.yaml

# Allow a 'domain-admin' role to manage users within a domain
"identity:list_users": "rule:cloud_admin or rule:domain_admin"
"identity:create_user": "rule:cloud_admin or rule:domain_admin"
"identity:update_user": "rule:cloud_admin or rule:domain_admin"

# Restrict role assignment to cloud admins only
"identity:create_grant": "role:admin and system_scope:all"

Discover Policy Rule Names

Before writing an override, find the exact rule name used by the service:

docker exec nova_api oslopolicy-list-redundant --namespace nova

docker exec nova_api oslopolicy-policy-generator \
  --namespace nova 2>/dev/null | grep -A1 "flavor"

docker exec neutron_server \
  cat /etc/neutron/policy.yaml 2>/dev/null || \
  docker exec neutron_server \
  oslopolicy-policy-generator --namespace neutron 2>/dev/null | head -100

cat /etc/ironcore/nova/policy.yaml 2>/dev/null || echo "No override — using defaults"

Audit Policy Enforcement

Regularly review and verify policy configurations across all services:

cat /etc/ironcore/nova/policy.yaml
cat /etc/ironcore/neutron/policy.yaml

# Source a non-admin openrc, then:
openstack server list
openstack image list
openstack network list

openstack role assignment list --names

Overly permissive policies are a leading cause of privilege escalation incidents. Test policy changes in a staging environment before applying to production. Always restrict — never relax — default policies without documented justification.

Maintain a change log for all policy modifications. Document the business justification, date of change, and approver for each policy override. This record is essential for compliance audits.

Next Steps

Roles & Role Assignments

Create custom roles and assign them to users on projects and domains

Security Hardening

Apply the full security hardening checklist including policy auditing best practices

Domain Management

Manage the domain and project hierarchy that policies operate within

Admin Troubleshooting

Resolve 403 Forbidden errors caused by policy misconfigurations

Core Services

Other Services

Overview

Default Policy Overview

Policy File Locations

Custom Roles and Per-Service Policies

Workflow

Create the custom role in Keystone

Find the policy rule names for the operations you want to allow

Write the policy override file

Apply the policy changes via the deployment console

Assign the custom role to users

Policy Syntax Reference

Per-Service Policy Examples

Discover Policy Rule Names

Audit Policy Enforcement

Next Steps

Roles & Role Assignments

Security Hardening

Domain Management

Admin Troubleshooting

​Overview

​Default Policy Overview

​Policy File Locations

​Custom Roles and Per-Service Policies

​Workflow

Create the custom role in Keystone

Find the policy rule names for the operations you want to allow

Write the policy override file

Apply the policy changes via the deployment console

Assign the custom role to users

​Policy Syntax Reference

​Per-Service Policy Examples

​Discover Policy Rule Names

​Audit Policy Enforcement

​Next Steps

Roles & Role Assignments

Security Hardening

Domain Management

Admin Troubleshooting

Overview

Default Policy Overview

Policy File Locations

Custom Roles and Per-Service Policies

Workflow

Policy Syntax Reference

Per-Service Policy Examples

Discover Policy Rule Names

Audit Policy Enforcement

Next Steps