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:
$ keystone user-create --name=alice --pass=mypassword123 --email=alice@example.com
Tenant. A project,
group, or organization. When 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 get a list of all running
instances in the tenant that you specified in your
query. This example creates a tenant named
acme:
$ keystone tenant-create --name=acme
Because the term project
was used instead of tenant in
earlier versions of OpenStack Compute, some
command-line tools use
--project_id instead of
--tenant-id or
--os-tenant-id to refer to
a tenant ID.
Role. Captures the
operations that a user can perform in a given tenant.
This example creates a role named
compute-user:
$ keystone role-create --name=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:
$ keystone user-list
+--------+---------+-------------------+--------+
| id | enabled | email | name |
+--------+---------+-------------------+--------+
| 892585 | True | alice@example.com | 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 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: