User management
The main components of Identity user management are:
User. Represents a
human user. Has associated information such as user
name, password, and email. This example creates a user
named alice:
$ openstack user create --password-prompt --email alice@example.com alice
Project. A tenant,
group, or organization. When you make requests to
OpenStack services, you must specify a project. For
example, if you query the Compute service for a list
of running instances, you get a list of all running
instances in the project that you specified in your
query. This example creates a project named
acme:
$ openstack project create acme
Domain. Defines
administrative boundaries for the management of Identity
entities. A domain may represent an individual, company, or
operator-owned space. It is used for exposing administrative
activities directly to the system users.
A domain is a collection of projects and users. Users may
be given a domain's administrator role. A domain
administrator may create projects, users, and groups within a
domain and assign roles to users and groups.
This example creates a domain named emea:
$ openstack --os-identity-api-version=3 domain create emea
Role. Captures the
operations that a user can perform in a given tenant.
This example creates a role named
compute-user:
$ openstack role create compute-user
Individual services, such as Compute and the
Image service, assign meaning to roles. In the
Identity Service, a role is simply a name.
The Identity Service assigns a tenant and a role to a user.
You might assign the compute-user role to
the alice user in the
acme tenant:
$ openstack user list
+--------+-------+
| ID | Name |
+--------+-------+
| 892585 | alice |
+--------+-------+
$ openstack role list
+--------+---------------+
| ID | Name |
+--------+---------------+
| 9a764e | compute-user |
+--------+---------------+
$ openstack project list
+--------+--------------------+
| ID | Name |
+--------+--------------------+
| 6b8fd2 | acme |
+--------+--------------------+
$ openstack role add --project 6b8fd2 --user 892585 9a764e
A user can have different roles in different tenants. For
example, Alice might also have the admin
role in the Cyberdyne tenant. A user can
also have multiple roles in the same tenant.
The
/etc/[SERVICE_CODENAME]/policy.json
file controls the tasks that users can perform 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 are 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 can create volumes
in that tenant.
"volume:create": "",
To restrict creation of volumes to users who had the
compute-user role in a particular
tenant, you would add "role:compute-user",
like so:
"volume:create": "role:compute-user",
To restrict all Compute service requests to require this
role, the resulting file would look like: