Customize RBAC policies to control which roles can perform each API operation across Xloud services. Create custom roles and map them to service-level permissions.
Xloud 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
Xloud administrator if you do not have sufficient permissions.
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.
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.
Create /etc/xavs/<service>/policy.yaml with only the rules you want to change:
/etc/xavs/nova/policy.yaml — allow network-operator to list servers
Copy
"os_compute_api:servers:index": "role:network-operator or role:member""os_compute_api:servers:detail": "role:network-operator or role:member"
/etc/xavs/neutron/policy.yaml — allow network-operator to manage ports
Copy
"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"
# 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
Copy
# 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
Copy
# 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
Copy
# 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"
# 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/xavs/neutron/policy.yaml
Copy
# 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/xavs/cinder/policy.yaml
Copy
# 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/xavs/glance/policy.yaml
Copy
# 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/xavs/keystone/policy.yaml
Copy
# 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"
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.
