Taikun Logo

Taikun OCP Guide

Table of Contents

Identity concepts

User management

Identity user management examples:

  • Create a user named alice:

    $ openstack user create --password-prompt --email [email protected] alice
  • Create a project named acme:

    $ openstack project create acme --domain default
  • Create a domain named emea:

    $ openstack --os-identity-api-version=3 domain create emea
  • Create a role named compute-user:

    $ openstack role create compute-user


    Individual services assign meaning to roles, typically through
    limiting or granting access to users with the role to the operations
    that the service supports. Role access is typically configured in the
    service’s policy.yaml file. For example, to limit Compute
    access to the compute-user role, edit the Compute service’s
    policy.yaml file to require this role for Compute

The Identity service assigns a project and a role to a user. You
might assign the compute-user role to the
alice user in the acme project:

$ openstack role add --project acme --user alice compute-user

A user can have different roles in different projects. For example,
Alice might also have the admin role in the
Cyberdyne project. A user can also have multiple roles in
the same project.

The /etc/[SERVICE_CODENAME]/policy.yaml file controls
the tasks that users can perform for a given service. For example, the
/etc/nova/policy.yaml file specifies the access policy for
the Compute service, the /etc/glance/policy.yaml file
specifies the access policy for the Image service, and the
/etc/keystone/policy.yaml file specifies the access policy
for the Identity service.

The default policy.yaml files in the Compute, Identity,
and Image services recognize only the admin role. Any user
with any role in a project can access all operations that do not require
the admin role.

To restrict users from performing operations in, for example, the
Compute service, you must create a role in the Identity service and then
modify the /etc/nova/policy.yaml file so that this role is
required for Compute operations.

For example, the following line in the
/etc/cinder/policy.yaml file does not restrict which users
can create volumes:

"volume:create": "",

If the user has any role in a project, he can create volumes in that

To restrict the creation of volumes to users who have the
compute-user role in a particular project, you add

"volume:create": "role:compute-user",

To restrict all Compute service requests to require this role, the
resulting file looks like:

   "admin_or_owner": "role:admin or project_id:%(project_id)s",
   "default": "rule:admin_or_owner",
   "compute:create": "role:compute-user",
   "compute:create:attach_network": "role:compute-user",
   "compute:create:attach_volume": "role:compute-user",
   "compute:get_all": "role:compute-user",
   "compute:unlock_override": "rule:admin_api",
   "admin_api": "role:admin",
   "compute_extension:accounts": "rule:admin_api",
   "compute_extension:admin_actions": "rule:admin_api",
   "compute_extension:admin_actions:pause": "rule:admin_or_owner",
   "compute_extension:admin_actions:unpause": "rule:admin_or_owner",
   "compute_extension:admin_actions:suspend": "rule:admin_or_owner",
   "compute_extension:admin_actions:resume": "rule:admin_or_owner",
   "compute_extension:admin_actions:lock": "rule:admin_or_owner",
   "compute_extension:admin_actions:unlock": "rule:admin_or_owner",
   "compute_extension:admin_actions:resetNetwork": "rule:admin_api",
   "compute_extension:admin_actions:injectNetworkInfo": "rule:admin_api",
   "compute_extension:admin_actions:createBackup": "rule:admin_or_owner",
   "compute_extension:admin_actions:migrateLive": "rule:admin_api",
   "compute_extension:admin_actions:migrate": "rule:admin_api",
   "compute_extension:aggregates": "rule:admin_api",
   "compute_extension:certificates": "role:compute-user",
   "compute_extension:cloudpipe": "rule:admin_api",
   "compute_extension:console_output": "role:compute-user",
   "compute_extension:consoles": "role:compute-user",
   "compute_extension:createserverext": "role:compute-user",
   "compute_extension:deferred_delete": "role:compute-user",
   "compute_extension:disk_config": "role:compute-user",
   "compute_extension:evacuate": "rule:admin_api",
   "compute_extension:extended_server_attributes": "rule:admin_api",
   "compute_extension:extended_status": "role:compute-user",
   "compute_extension:flavorextradata": "role:compute-user",
   "compute_extension:flavorextraspecs": "role:compute-user",
   "compute_extension:flavormanage": "rule:admin_api",
   "compute_extension:floating_ip_dns": "role:compute-user",
   "compute_extension:floating_ip_pools": "role:compute-user",
   "compute_extension:floating_ips": "role:compute-user",
   "compute_extension:hosts": "rule:admin_api",
   "compute_extension:keypairs": "role:compute-user",
   "compute_extension:multinic": "role:compute-user",
   "compute_extension:networks": "rule:admin_api",
   "compute_extension:quotas": "role:compute-user",
   "compute_extension:rescue": "role:compute-user",
   "compute_extension:security_groups": "role:compute-user",
   "compute_extension:server_action_list": "rule:admin_api",
   "compute_extension:server_diagnostics": "rule:admin_api",
   "compute_extension:simple_tenant_usage:show": "rule:admin_or_owner",
   "compute_extension:simple_tenant_usage:list": "rule:admin_api",
   "compute_extension:users": "rule:admin_api",
   "compute_extension:virtual_interfaces": "role:compute-user",
   "compute_extension:virtual_storage_arrays": "role:compute-user",
   "compute_extension:volumes": "role:compute-user",
   "compute_extension:volume_attachments:index": "role:compute-user",
   "compute_extension:volume_attachments:show": "role:compute-user",
   "compute_extension:volume_attachments:create": "role:compute-user",
   "compute_extension:volume_attachments:delete": "role:compute-user",
   "compute_extension:volumetypes": "role:compute-user",
   "volume:create": "role:compute-user",
   "volume:get_all": "role:compute-user",
   "volume:get_volume_metadata": "role:compute-user",
   "volume:get_snapshot": "role:compute-user",
   "volume:get_all_snapshots": "role:compute-user",
   "network:get_all_networks": "role:compute-user",
   "network:get_network": "role:compute-user",
   "network:delete_network": "role:compute-user",
   "network:disassociate_network": "role:compute-user",
   "network:get_vifs_by_instance": "role:compute-user",
   "network:allocate_for_instance": "role:compute-user",
   "network:deallocate_for_instance": "role:compute-user",
   "network:validate_networks": "role:compute-user",
   "network:get_instance_uuids_by_ip_filter": "role:compute-user",
   "network:get_floating_ip": "role:compute-user",
   "network:get_floating_ip_pools": "role:compute-user",
   "network:get_floating_ip_by_address": "role:compute-user",
   "network:get_floating_ips_by_project": "role:compute-user",
   "network:get_floating_ips_by_fixed_address": "role:compute-user",
   "network:allocate_floating_ip": "role:compute-user",
   "network:deallocate_floating_ip": "role:compute-user",
   "network:associate_floating_ip": "role:compute-user",
   "network:disassociate_floating_ip": "role:compute-user",
   "network:get_fixed_ip": "role:compute-user",
   "network:add_fixed_ip_to_instance": "role:compute-user",
   "network:remove_fixed_ip_from_instance": "role:compute-user",
   "network:add_network_to_project": "role:compute-user",
   "network:get_instance_nw_info": "role:compute-user",
   "network:get_dns_domains": "role:compute-user",
   "network:add_dns_entry": "role:compute-user",
   "network:modify_dns_entry": "role:compute-user",
   "network:delete_dns_entry": "role:compute-user",
   "network:get_dns_entries_by_address": "role:compute-user",
   "network:get_dns_entries_by_name": "role:compute-user",
   "network:create_private_dns_domain": "role:compute-user",
   "network:create_public_dns_domain": "role:compute-user",
   "network:delete_dns_domain": "role:compute-user"

Service management

The Identity service provides identity, token, catalog, and policy
services. It consists of:

  • keystone Web Server Gateway Interface (WSGI) service

    Can be run in a WSGI-capable web server such as Apache httpd to
    provide the Identity service. The service and administrative APIs are
    run as separate instances of the WSGI service.

  • Identity service functions

    Each has a pluggable back end that allow different ways to use the
    particular service. Most support standard back ends like LDAP or

The Identity service also maintains a user that corresponds to each
service, such as, a user named nova for the Compute
service, and a special service project called service.

For information about how to create services and endpoints, see the
Administrator Guide <manage_services>.


A group is a collection of users in a domain. Administrators can
create groups and add users to them. A role can then be assigned to the
group, rather than individual users. Groups were introduced with the
Identity API v3.

Identity API V3 provides the following group-related operations:

  • Create a group
  • Delete a group
  • Update a group (change its name or description)
  • Add a user to a group
  • Remove a user from a group
  • List group members
  • List groups for a user
  • Assign a role on a project to a group
  • Assign a role on a domain to a group
  • Query role assignments to groups


The Identity service server might not allow all operations. For
example, if you use the Identity server with the LDAP Identity back end
and group updates are disabled, a request to create, delete, or update a
group fails.

Here are a couple of examples:

  • Group A is granted Role A on Project A. If User A is a member of
    Group A, when User A gets a token scoped to Project A, the token also
    includes Role A.
  • Group B is granted Role B on Domain B. If User B is a member of
    Group B, when User B gets a token scoped to Domain B, the token also
    includes Role B.