The Identity service performs the following functions:
User management. Tracks users and their permissions.
Service catalog. Provides a catalog of available services with their API endpoints.
To understand the Identity Service, you must understand the following concepts:
- User
Digital representation of a person, system, or service who uses OpenStack cloud services. Identity authentication services will validate that incoming request are being made by the user who claims to be making the call. Users have a login and may be assigned tokens to access resources. Users may be directly assigned to a particular tenant and behave as if they are contained in that tenant.
- Credentials
Data that is known only by a user that proves who they are. In the Identity Service, examples are:
Username and password
Username and API key
An authentication token provided by the Identity Service
- Authentication
The act of confirming the identity of a user. The Identity Service confirms an incoming request by validating a set of credentials supplied by the user. These credentials are initially a username and password or a username and API key. In response to these credentials, the Identity Service issues the user an authentication token, which the user provides in subsequent requests.
- Token
An arbitrary bit of text that is used to access resources. Each token has a scope which describes which resources are accessible with it. A token may be revoked at anytime and is valid for a finite duration.
While the Identity Service supports token-based authentication in this release, the intention is for it to support additional protocols in the future. The intent is for it to be an integration service foremost, and not aspire to be a full-fledged identity store and management solution.
- Tenant
A container used to group or isolate resources and/or identity objects. Depending on the service operator, a tenant may map to a customer, account, organization, or project.
- Service
An OpenStack service, such as Compute (Nova), Object Storage (Swift), or Image Service (Glance). Provides one or more endpoints through which users can access resources and perform operations.
- Endpoint
An network-accessible address, usually described by URL, from where you access a service. If using an extension for templates, you can create an endpoint template, which represents the templates of all the consumable services that are available across the regions.
- Role
A personality that a user assumes that enables them to perform a specific set of operations. A role includes a set of rights and privileges. A user assuming that role inherits those rights and privileges.
In the Identity Service, a token that is issued to a user includes the list of roles that user can assume. Services that are being called by that user determine how they interpret the set of roles a user has and which operations or resources each role grants access to.
The main components 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 protected]
A tenant can be 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]](../common/images/admon/note.png) | Note |
|---|---|
Because the term project was
used instead of tenant in earlier
versions of OpenStack Compute, some command-line tools
use |
A role captures what operations a user is permitted to perform in a given tenant. This example creates a role 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 | +--------+---------+-------------------+--------+ | 892585 | True | [email protected] | alice | +--------+---------+-------------------+--------+
$ keystone role-list
+--------+--------------+ | id | name | +--------+--------------+ | 9a764e | compute-user | +--------+--------------+
$ keystone tenant-list
+--------+------+---------+ | id | name | enabled | +--------+------+---------+ | 6b8fd2 | acme | True | +--------+------+---------+
$ keystone user-role-add --user=892585 --role=9a764e --tenant-id=6b8fd2
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/
controls what users are allowed to do for a given service.
For example, [SERVICE_CODENAME]/policy.json/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.
{
"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:
{
"volume:create":[
"role:compute-user"
]
}If we wished to restrict all Compute service requests to require this role, the resulting file would look like:
{
"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: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: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"
]
}
The Identity Service provides the following service management functions:
Services
Endpoints
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 tenant, which is called service.
The commands for creating services and endpoints are described in a later section.
