c2e6c077f3
As reported in LP#1277289, the usage of the authorisation token is not clear in the instructions. It refers to a token previously created but potentially leaves the user confused as to which one to use. This patch adds the clarity required and posts a link to the documentation section. Change-Id: Ib16bd2770d4c4aac5292e9a3d2f25c2417e818f2 Closes-Bug: #1277289 backport: havana
67 lines
3.4 KiB
XML
67 lines
3.4 KiB
XML
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
xml:id="keystone-users" os="rhel;centos;fedora;opensuse;sles;ubuntu">
|
|
<title>Define users, tenants, and roles</title>
|
|
|
|
<para>After you install the Identity Service, set up
|
|
<glossterm baseform="user">users</glossterm>,
|
|
<glossterm baseform="tenant">tenants</glossterm>, and
|
|
<glossterm baseform="role">roles</glossterm> to authenticate
|
|
against. These are used to allow access to
|
|
services and <glossterm baseform="endpoint">endpoints</glossterm>, described
|
|
in the next section.</para>
|
|
|
|
<para>Typically, you would indicate a user and password to
|
|
authenticate with the Identity Service. At this point, however, we
|
|
have not created any users, so we have to use the authorization
|
|
token created in an earlier step, see <xref linkend="keystone-install"/>
|
|
for further details. You can pass this with the
|
|
<option>--os-token</option> option to the
|
|
<command>keystone</command> command or set the
|
|
<envar>OS_SERVICE_TOKEN</envar> environment variable. We'll set
|
|
<envar>OS_SERVICE_TOKEN</envar>, as well as
|
|
<envar>OS_SERVICE_ENDPOINT</envar> to specify where the Identity
|
|
Service is running. Replace
|
|
<userinput><replaceable>ADMIN_TOKEN</replaceable></userinput>
|
|
with your authorization token.</para>
|
|
|
|
<screen><prompt>#</prompt> <userinput>export OS_SERVICE_TOKEN=<replaceable>ADMIN_TOKEN</replaceable></userinput>
|
|
<prompt>#</prompt> <userinput>export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0</userinput></screen>
|
|
|
|
<para>First, create a tenant for an administrative user and a tenant
|
|
for other OpenStack services to use.</para>
|
|
|
|
<screen><prompt>#</prompt> <userinput>keystone tenant-create --name=admin --description="Admin Tenant"</userinput>
|
|
<prompt>#</prompt> <userinput>keystone tenant-create --name=service --description="Service Tenant"</userinput></screen>
|
|
|
|
<para>Next, create an administrative user called <literal>admin</literal>.
|
|
Choose a password for the <literal>admin</literal> user and specify an
|
|
email address for the account.</para>
|
|
|
|
<screen><prompt>#</prompt> <userinput>keystone user-create --name=admin --pass=<replaceable>ADMIN_PASS</replaceable> \
|
|
--email=<replaceable>admin@example.com</replaceable></userinput></screen>
|
|
|
|
<para>Create a role for administrative tasks called <literal>admin</literal>.
|
|
Any roles you create should map to roles specified in the
|
|
<filename>policy.json</filename> files of the various OpenStack services.
|
|
The default policy files use the <literal>admin</literal> role to allow
|
|
access to most services.</para>
|
|
|
|
<screen><prompt>#</prompt> <userinput>keystone role-create --name=admin</userinput></screen>
|
|
|
|
<para>Now, you have to add roles to users. Users always log in with
|
|
a tenant, and roles are assigned to users within tenants. Add the
|
|
<literal>admin</literal> role to the <literal>admin</literal> user when
|
|
logging in with the <literal>admin</literal> tenant.</para>
|
|
|
|
<screen><prompt>#</prompt> <userinput>keystone user-role-add --user=admin --tenant=admin --role=admin</userinput></screen>
|
|
|
|
<para>
|
|
Add the <literal>_member_</literal> role to the <literal>admin</literal>
|
|
user. This is a special role that grants access to the OpenStack Dashboard.
|
|
</para>
|
|
<screen><prompt>#</prompt> <userinput>keystone user-role-add --user=admin --tenant=admin --role=_member_</userinput></screen>
|
|
|
|
</section>
|