98e7068e48
There are several instances of "Image service" in the upstream documentation. As was recently clarified in the docs mailing list, these should be "Image Service". This patch applies the fix. Change-Id: Iefb63673162ae97b2c0fe1c3ff3fb1ac05e95d83 Partial-Bug: #1217503
114 lines
6.2 KiB
XML
114 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>
|