115 lines
6.2 KiB
XML
115 lines
6.2 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>keystone user-create --name=alice --pass=mypassword123 --email=alice@example.com</userinput></screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para><emphasis role="bold">Tenant</emphasis>. 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
|
|
<literal>acme</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>keystone tenant-create --name=acme</userinput></screen>
|
|
<note>
|
|
<para>Because the term <emphasis>project</emphasis>
|
|
was used instead of <emphasis>tenant</emphasis> in
|
|
earlier versions of OpenStack Compute, some
|
|
command-line tools use
|
|
<literal>--project_id</literal> instead of
|
|
<literal>--tenant-id</literal> or
|
|
<literal>--os-tenant-id</literal> to refer to
|
|
a tenant ID.</para>
|
|
</note>
|
|
</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>keystone role-create --name=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>keystone user-list</userinput>
|
|
<computeroutput>+--------+---------+-------------------+--------+
|
|
| id | enabled | email | name |
|
|
+--------+---------+-------------------+--------+
|
|
| 892585 | True | alice@example.com | alice |
|
|
+--------+---------+-------------------+--------+</computeroutput></screen>
|
|
<screen><prompt>$</prompt> <userinput>keystone role-list</userinput>
|
|
<computeroutput>+--------+--------------+
|
|
| id | name |
|
|
+--------+--------------+
|
|
| 9a764e | compute-user |
|
|
+--------+--------------+</computeroutput></screen>
|
|
<screen><prompt>$</prompt> <userinput>keystone tenant-list</userinput>
|
|
<computeroutput>+--------+------+---------+
|
|
| id | name | enabled |
|
|
+--------+------+---------+
|
|
| 6b8fd2 | acme | True |
|
|
+--------+------+---------+</computeroutput></screen>
|
|
<screen><prompt>$</prompt> <userinput>keystone user-role-add --user=892585 --role=9a764e --tenant-id=6b8fd2</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>
|