openstack-manuals/doc/common/section_keystone-concepts-user-management.xml
Andreas Jaeger 3ca32b8434 s/Image Service/Image service/g
Change capitalization as discussed on openstack-docs mailing list.

Change-Id: I2ad81bffbd59bdd8b908664bb0a1ee16da1bf7ae
2015-04-15 15:16:59 +02:00

119 lines
6.4 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="keystone-user-management">
<title>User management</title>
<para>The main components of Identity user management are:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">User</emphasis>. Represents a
human user. Has associated information such as user
name, password, and email. This example creates a user
named <literal>alice</literal>:</para>
<screen><prompt>$</prompt> <userinput>openstack user create --password-prompt --email alice@example.com alice</userinput></screen>
</listitem>
<listitem>
<para><emphasis role="bold">Project</emphasis>. 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
<literal>acme</literal>:</para>
<screen><prompt>$</prompt> <userinput>openstack project create acme</userinput></screen>
</listitem>
<listitem>
<para><emphasis role="bold">Domain</emphasis>. 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.</para>
<para>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.</para>
<para>This example creates a domain named <literal>emea</literal>:
</para>
<screen><prompt>$</prompt> <userinput>openstack domain create emea</userinput></screen>
</listitem>
<listitem>
<para><emphasis role="bold">Role</emphasis>. Captures the
operations that a user can perform in a given tenant.</para>
<para>This example creates a role named
<literal>compute-user</literal>:</para>
<screen><prompt>$</prompt> <userinput>openstack role create compute-user</userinput></screen>
<note>
<para>Individual services, such as Compute and the
Image service, assign meaning to roles. In the
Identity Service, a role is simply a name.</para>
</note>
</listitem>
</itemizedlist>
<?hard-pagebreak?>
<para>The Identity Service assigns a tenant and a role to a user.
You might assign the <literal>compute-user</literal> role to
the <literal>alice</literal> user in the
<literal>acme</literal> tenant:</para>
<screen><prompt>$</prompt> <userinput>openstack user list</userinput>
<computeroutput>+--------+-------+
| ID | Name |
+--------+-------+
| 892585 | alice |
+--------+-------+</computeroutput></screen>
<screen><prompt>$</prompt> <userinput>openstack role list</userinput>
<computeroutput>+--------+---------------+
| ID | Name |
+--------+---------------+
| 9a764e | compute-user |
+--------+---------------+</computeroutput></screen>
<screen><prompt>$</prompt> <userinput>openstack project list</userinput>
<computeroutput>+--------+--------------------+
| ID | Name |
+--------+--------------------+
| 6b8fd2 | acme |
+--------+--------------------+</computeroutput></screen>
<screen><prompt>$</prompt> <userinput>openstack role add --project 6b8fd2 --user 892585 9a764e</userinput> </screen>
<para>A user can have different roles in different tenants. For
example, Alice might also have the <literal>admin</literal>
role in the <literal>Cyberdyne</literal> tenant. A user can
also have multiple roles in the same tenant.</para>
<para>The
<filename>/etc/<replaceable>[SERVICE_CODENAME]</replaceable>/policy.json</filename>
file controls the tasks that users can perform for a given
service. For example,
<filename>/etc/nova/policy.json</filename> specifies the
access policy for the Compute service,
<filename>/etc/glance/policy.json</filename> specifies the
access policy for the Image service, and
<filename>/etc/keystone/policy.json</filename> specifies
the access policy for the Identity Service.</para>
<para>The default <filename>policy.json</filename> files in the
Compute, Identity, and Image service recognize only the
<literal>admin</literal> role: all operations that do not
require the <literal>admin</literal> role are accessible by
any user that has any role in a tenant.</para>
<para>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
<filename>/etc/nova/policy.json</filename> so that this
role is required for Compute operations.</para>
<?hard-pagebreak?>
<para>For example, this line in
<filename>/etc/nova/policy.json</filename> 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.</para>
<programlisting language="json">"volume:create": "",</programlisting>
<para>To restrict creation of volumes to users who had the
<literal>compute-user</literal> role in a particular
tenant, you would add <literal>"role:compute-user"</literal>,
like so:</para>
<programlisting language="json">"volume:create": "role:compute-user",</programlisting>
<para>To restrict all Compute service requests to require this
role, the resulting file would look like:</para>
<programlisting language="json"><xi:include href="../common/samples/restrict_roles2.json" parse="text"/></programlisting>
</section>