Basic Concepts
The Identity services has two primary functions:
-
User management: keep track of users and what they are permitted to do
-
Service catalog: Provide a catalog of what services are available and where their API endpoints are located
The three main concepts of Identity user management are:
-
Users
-
Tenants
-
Roles
A user represents a human user, and has associated information such as username, password and email. This example creates a user named "alice":
$ keystone user-create --name=alice --pass=mypassword123 --email=alice@example.com
A tenant can be thought of as a project, group, or organization. Whenever you make requests to OpenStack services, you must specify a tenant. For example, if you query the Compute service for a list of running instances, you will receive a list
of all of the running instances in the tenant you specified in your query. This example creates a tenant named "acme":
$ keystone tenant-create --name=acme
Note
Because the term project was used in instead of tenant in earlier versions of OpenStack Compute, some command-line tools use --project_id instead of --tenant_id to refer to a tenant ID.
A role captures what operations a user is permitted to perform in a given tenant. This example creates a tenant named "compute-user":
$ keystone role-create --name=compute-user
Note
It is up to individual services such as the Compute service and Image service to assign meaning to these roles. As far as the Identity service is concerned, a role is simply a name.
The Identity service associates a user with a tenant and a role. To continue with our previous examples, we may wish to assign the "alice" user the "compute-user" role in the "acme" tenant:
$ keystone user-list
+----------------------------------+---------+-------+--------+
| id | enabled | email | name |
+----------------------------------+---------+-------+--------+
| 96a6ebba0d4c441887aceaeced892585 | True | ... | alice |
+----------------------------------+---------+-------+--------+
$ keystone role-list
+----------------------------------+--------------+
| id | name |
+----------------------------------+--------------+
| f8dd5a2e4dc64a41b96add562d9a764e | compute-user |
+----------------------------------+--------------+
$ keystone tenant-list
+----------------------------------+--------------+---------+
| id | name | enabled |
+----------------------------------+--------------+---------+
| 2395953419144b67955ac4bab96b8fd2 | acme | True |
+----------------------------------+--------------+---------+
$ keystone user-role-add \
--user=96a6ebba0d4c441887aceaeced892585 \
--role=f8dd5a2e4dc64a41b96add562d9a764e \
--tenant_id=2395953419144b67955ac4bab96b8fd2
A user can be assigned different roles in different tenants: for example, Alice may also have the "admin" role in the "Cyberdyne" tenant. A user can also be assigned multiple roles in the same tenant.
The /etc/[SERVICE_CODENAME]/policy.json controls what users are allowed to do for a given service. For example, /etc/nova/policy.json specifies the access policy for the Compute service, /etc/glance/policy.json specifies the access policy for the
Image service, and /etc/keystone/policy.json specifies the access policy for the Identity service.
The default policy.json files in the Compute, Identity, and Image service recognize only the admin role: all operations that do not require the admin role will be accessible by any user that has any role in a tenant.
If you wish to restrict users from performing operations in, say, the Compute service, you need to create a role in the Identity service and then modify /etc/nova/policy.json so that this role is required for Compute operations.
For example, this line in /etc/nova/policy.json specifies that there are no restrictions on which users can create volumes: if the user has any role in a tenant, they will be able to create volumes in that tenant.
1"volume:create":[],
If we wished to restrict creation of volumes to users who had the compute-user role in a particular tenant, we would add "role:compute-user", like so:
1"volume:create":["role:compute-user"],
If we wished to restrict all Compute service requests to require this role, the resulting file would look like:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102{ "admin_or_owner":
[["role:admin"], ["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"], "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_api"]], "compute_extension:admin_actions:unlock":[["rule:admin_api"]], "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: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: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 two main concepts of Identity service management are:
-
Services
-
Endpoints
The Identity service also maintains a user that corresponds to each service (e.g., a user named
nova, for the Compute service) and a special service tenant, which is called
service.
The commands for creating services and endpoints are described in a later section.