895 lines
38 KiB
XML
895 lines
38 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE chapter [
|
|
<!-- Some useful entities borrowed from HTML -->
|
|
<!ENTITY ndash "–">
|
|
<!ENTITY mdash "—">
|
|
<!ENTITY hellip "…">
|
|
<!ENTITY plusmn "±">
|
|
]>
|
|
<chapter 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="projects_users">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Managing Projects and Users</title>
|
|
<para>An OpenStack cloud does not have much value without users.
|
|
This chapter covers topics that relate to managing users,
|
|
projects, and quotas.</para>
|
|
<section xml:id="projects_or_tenants">
|
|
<title>Projects or Tenants?</title>
|
|
<para>In OpenStack user interfaces and documentation, a group
|
|
of users is referred to as a
|
|
<glossterm>project</glossterm> or
|
|
<glossterm>tenant</glossterm>. These terms are
|
|
interchangeable.</para>
|
|
<para>The initial implementation of the OpenStack Compute
|
|
Service (nova) had its own authentication system and used
|
|
the term <literal>project</literal>. When authentication
|
|
moved into the OpenStack Identity Service (keystone)
|
|
project, it used the term <literal>tenant</literal> to
|
|
refer to a group of users. Because of this legacy, some of
|
|
the OpenStack tools refer to projects and some refer to
|
|
tenants.</para>
|
|
<para>This guide uses the term <literal>project</literal>,
|
|
unless an example shows interaction with a tool that uses
|
|
the term <literal>tenant</literal>.</para>
|
|
</section>
|
|
<section xml:id="managing_projects">
|
|
<title>Managing Projects</title>
|
|
<para>Users must be associated with at least one project,
|
|
though they may belong to many. Therefore, you should add
|
|
at least one project before adding users.</para>
|
|
<section xml:id="add_projects">
|
|
<title>Adding Projects</title>
|
|
<para>To create a project through the dashboard:</para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Log in as an administrative user.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Select the "Projects" link in the left hand
|
|
navigation bar.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Click on the "Create Project" button at the
|
|
top right.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
<para>You are prompted for a project name and an optional,
|
|
but recommended, description. Select the check box at
|
|
the bottom of the form to enable this project. By
|
|
default, this is enabled.</para>
|
|
<!-- <informalfigure>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata width="5in"
|
|
fileref="figures/horizon-add-project.png"
|
|
/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</informalfigure> -->
|
|
<para>It is also possible to add
|
|
project members and adjust the project quotas. We'll
|
|
discuss those later, but in practice it can be quite
|
|
convenient to deal with all these operations at one
|
|
time.</para>
|
|
<para>To create a project through the command-line
|
|
interface (CLI):</para>
|
|
<para>To add a project through the command line, you must
|
|
use the keystone utility, which uses "tenant" in place
|
|
of "project":</para>
|
|
<programlisting><?db-font-size 75%?><prompt>#</prompt> keystone tenant-create --name=demo</programlisting>
|
|
<para>This command creates a project named "demo".
|
|
Optionally, you can add a description string by
|
|
appending <code>--description
|
|
<replaceable>tenant-description</replaceable></code> which can be
|
|
very useful. You can also create a group in a disabled
|
|
state by appending <code>--enabled false</code> to the
|
|
command. By default, projects are created in an
|
|
enabled state.</para>
|
|
</section>
|
|
</section>
|
|
<?hard-pagebreak?>
|
|
<section xml:id="quotas">
|
|
<title>Quotas</title>
|
|
<para>To prevent system capacities from being exhausted without
|
|
notification, you can set up quotas. Quotas are operational limits.
|
|
For example, the number of gigabytes allowed per tenant can be
|
|
controlled to ensure that a single tenant cannot consume all of
|
|
the disk space. Quotas are currently enforced at the tenant (or
|
|
project) level, rather than by user.
|
|
</para>
|
|
<para>Using the command-line interface, you can manage quotas for the OpenStack Compute Service and the Block Storage Service.
|
|
</para>
|
|
<para>Typically, default values are changed because a tenant requires
|
|
more than the OpenStack default of 10 volumes per tenant, or more
|
|
than the OpenStack default of 1TB of disk space on a Compute node.
|
|
</para>
|
|
<note><para>To view all tenants, run:
|
|
<screen><prompt>$</prompt> <userinput>keystone tenant-list</userinput>
|
|
<computeroutput>+----------------------------------+----------+---------+
|
|
| id | name | enabled |
|
|
+----------------------------------+----------+---------+
|
|
| a981642d22c94e159a4a6540f70f9f8d | admin | True |
|
|
| 934b662357674c7b9f5e4ec6ded4d0e7 | tenant01 | True |
|
|
| 7bc1dbfd7d284ec4a856ea1eb82dca80 | tenant02 | True |
|
|
| 9c554aaef7804ba49e1b21cbd97d218a | services | True |
|
|
+----------------------------------+----------+---------+</computeroutput></screen>
|
|
</para></note>
|
|
<section xml:id="cli_set_compute_quotas">
|
|
<title>Set Compute Service Quotas</title>
|
|
<para>As an administrative user, you can update the Compute Service quotas for an existing tenant, as well as update the quota
|
|
defaults for a new tenant.
|
|
</para>
|
|
<table rules="all">
|
|
<caption>Compute Quota Descriptions</caption>
|
|
<col width="20%"/>
|
|
<col width="45%"/>
|
|
<col width="35%"/>
|
|
<thead>
|
|
<tr>
|
|
<td>
|
|
Quota
|
|
</td>
|
|
<td>
|
|
Description
|
|
</td>
|
|
<td>
|
|
Property Name
|
|
</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Fixed Ips
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of fixed IP addresses allowed per tenant. This number
|
|
must be equal to or greater than the number of allowed
|
|
instances.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>fixed-ips</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Floating Ips
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of floating IP addresses allowed per tenant.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>floating-ips</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Injected File Content Bytes
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of content bytes allowed per injected file.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>injected-file-content-bytes</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Injected File Path Bytes
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of bytes allowed per injected file path.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>injected-file-path-bytes</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Injected Files
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of injected files allowed per tenant.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>injected-files</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Instances
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of instances allowed per tenant.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>instances</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Key Pairs
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of key pairs allowed per user.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>key-pairs</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Metadata Items
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of metadata items allowed per instance.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>metadata-items</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Ram
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Megabytes of instance ram allowed per tenant.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>ram</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Security Group Rules
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of rules per security group.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>security-group-rules</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
Security Groups
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of security groups per tenant.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>security-groups</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
VCPUs
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of instance cores allowed per tenant.
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
<systemitem>cores</systemitem>
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<section xml:id="cli_set_compute_quotas_procedure">
|
|
<title>View and update Compute quotas for a tenant (project)</title>
|
|
<para>As an administrative user, you can use the <command>nova quota-*</command>
|
|
commands, which are provided by the <literal>python-novaclient</literal>
|
|
package, to view and update tenant quotas.</para>
|
|
<procedure>
|
|
<title>To view and update default quota values</title>
|
|
<step>
|
|
<para>List all default quotas for all tenants, as follows:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova quota-defaults</userinput></screen>
|
|
<para>For example:
|
|
</para>
|
|
<screen><prompt>$</prompt> <userinput>nova quota-defaults</userinput>
|
|
<computeroutput>+-----------------------------+-------+
|
|
| Property | Value |
|
|
+-----------------------------+-------+
|
|
| metadata_items | 128 |
|
|
| injected_file_content_bytes | 10240 |
|
|
| ram | 51200 |
|
|
| floating_ips | 10 |
|
|
| key_pairs | 100 |
|
|
| instances | 10 |
|
|
| security_group_rules | 20 |
|
|
| injected_files | 5 |
|
|
| cores | 20 |
|
|
| fixed_ips | -1 |
|
|
| injected_file_path_bytes | 255 |
|
|
| security_groups | 10 |
|
|
+-----------------------------+-------+</computeroutput></screen>
|
|
</step>
|
|
<step>
|
|
<para>Update a default value for a new tenant, as follows:
|
|
</para>
|
|
<screen><prompt>$</prompt> <userinput>nova quota-class-update default <replaceable>key</replaceable> <replaceable>value</replaceable></userinput></screen>
|
|
<para>For example:
|
|
</para>
|
|
<screen><prompt>$</prompt> <userinput>nova quota-class-update default instances 15</userinput></screen>
|
|
</step>
|
|
</procedure>
|
|
<procedure>
|
|
<title>To view quota values for a tenant (project)</title>
|
|
<step><para>Place the tenant ID in a useable variable, as follows:</para>
|
|
<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list | awk '/<replaceable>tenantName</replaceable>/ {print $2}')</userinput></screen>
|
|
</step>
|
|
<step>
|
|
<para>List the currently set quota values for a
|
|
tenant, as follows:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova quota-show --tenant $tenant</userinput></screen>
|
|
<para>For example:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova quota-show --tenant $tenant</userinput>
|
|
<computeroutput>+-----------------------------+-------+
|
|
| Property | Value |
|
|
+-----------------------------+-------+
|
|
| metadata_items | 128 |
|
|
| injected_file_content_bytes | 10240 |
|
|
| ram | 51200 |
|
|
| floating_ips | 12 |
|
|
| key_pairs | 100 |
|
|
| instances | 10 |
|
|
| security_group_rules | 20 |
|
|
| injected_files | 5 |
|
|
| cores | 20 |
|
|
| fixed_ips | -1 |
|
|
| injected_file_path_bytes | 255 |
|
|
| security_groups | 10 |
|
|
+-----------------------------+-------+</computeroutput></screen>
|
|
</step>
|
|
</procedure>
|
|
<procedure>
|
|
<title>To update quota values for a tenant (project)</title>
|
|
<step><para>Obtain the tenant ID, as follows:</para>
|
|
<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list | awk '/<replaceable>tenantName</replaceable>/ {print $2}')</userinput></screen>
|
|
</step>
|
|
<step>
|
|
<para>Update a particular quota value, as follows:</para>
|
|
<screen><prompt>#</prompt> <userinput>nova quota-update --<replaceable>quotaName</replaceable> <replaceable>quotaValue</replaceable> <replaceable>tenantID</replaceable></userinput></screen>
|
|
<para>For example:</para>
|
|
<screen><prompt>#</prompt> <userinput>nova quota-update --floating-ips 20 $tenant
|
|
<prompt>#</prompt> nova quota-show --tenant $tenant</userinput>
|
|
<computeroutput>+-----------------------------+-------+
|
|
| Property | Value |
|
|
+-----------------------------+-------+
|
|
| metadata_items | 128 |
|
|
| injected_file_content_bytes | 10240 |
|
|
| ram | 51200 |
|
|
| floating_ips | 20 |
|
|
| key_pairs | 100 |
|
|
| instances | 10 |
|
|
| security_group_rules | 20 |
|
|
| injected_files | 5 |
|
|
| cores | 20 |
|
|
| fixed_ips | -1 |
|
|
| injected_file_path_bytes | 255 |
|
|
| security_groups | 10 |
|
|
+-----------------------------+-------+</computeroutput></screen>
|
|
<note>
|
|
<para>To view a list of options for the
|
|
<command>quota-update</command> command, run:
|
|
</para>
|
|
<screen><prompt>$</prompt> <userinput>nova help quota-update</userinput></screen></note>
|
|
</step>
|
|
</procedure>
|
|
</section>
|
|
</section>
|
|
<section xml:id="cli_set_block_storage_quotas">
|
|
<title>Set Block Storage quotas</title>
|
|
<para>As an administrative user, you can update
|
|
the Block Storage Service quotas for a tenant,
|
|
as well as update the quota defaults for a new tenant.
|
|
</para>
|
|
<para>
|
|
<table rules="all">
|
|
<caption>Block Storage Quota Descriptions</caption>
|
|
<col width="20%"/>
|
|
<col width="80%"/>
|
|
<thead>
|
|
<tr>
|
|
<td>
|
|
Property Name
|
|
</td>
|
|
<td>
|
|
Description
|
|
</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
gigabytes
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of volume gigabytes allowed per tenant.
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
snapshots
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of Block Storage snapshots allowed per tenant.
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>
|
|
volumes
|
|
</para>
|
|
</td>
|
|
<td>
|
|
<para>
|
|
Number of Block Storage volumes allowed per tenant.
|
|
</para>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</para>
|
|
<section xml:id="cli_set_block_storage_quotas_procedure">
|
|
<title>View and update Block Storage quotas for a tenant (project)</title>
|
|
<para>As an administrative user, you can use the <command>cinder quota-*</command>
|
|
commands, which are provided by the <literal>python-cinderclient</literal>
|
|
package, to view and update tenant quotas.</para>
|
|
<procedure>
|
|
<title>To view and update default Block Storage quota values</title>
|
|
<step>
|
|
<para>List all default quotas for all tenants, as follows:</para>
|
|
<screen><prompt>$</prompt> <userinput>cinder quota-defaults</userinput></screen>
|
|
<para>For example:</para>
|
|
<screen><prompt>$</prompt> <userinput>cinder quota-defaults</userinput>
|
|
<computeroutput>+-----------+-------+
|
|
| Property | Value |
|
|
+-----------+-------+
|
|
| gigabytes | 1000 |
|
|
| snapshots | 10 |
|
|
| volumes | 10 |
|
|
+-----------+-------+</computeroutput></screen>
|
|
</step>
|
|
<step>
|
|
<para>To update a default value for a new tenant, update the property
|
|
in the <filename>/etc/cinder/cinder.conf</filename> file.
|
|
</para>
|
|
</step>
|
|
</procedure>
|
|
<procedure>
|
|
<title>To view Block Storage quotas for a tenant</title>
|
|
<step>
|
|
<para>View quotas for the tenant, as follows:</para>
|
|
<screen><prompt>#</prompt> <userinput>cinder quota-show <replaceable>tenantName</replaceable></userinput></screen>
|
|
<para>For example:</para>
|
|
<screen><prompt>#</prompt> <userinput>cinder quota-show tenant01</userinput>
|
|
<computeroutput>+-----------+-------+
|
|
| Property | Value |
|
|
+-----------+-------+
|
|
| gigabytes | 1000 |
|
|
| snapshots | 10 |
|
|
| volumes | 10 |
|
|
+-----------+-------+</computeroutput></screen>
|
|
</step>
|
|
</procedure>
|
|
<procedure>
|
|
<title>To update Compute service quotas</title>
|
|
<step><para>Place the tenant ID in a useable variable, as follows:</para>
|
|
<screen><prompt>$</prompt> <userinput>tenant=$(keystone tenant-list | awk '/<replaceable>tenantName</replaceable>/ {print $2}')</userinput></screen>
|
|
</step>
|
|
<step>
|
|
<para>Update a particular quota value, as follows:</para>
|
|
<screen><prompt>#</prompt> <userinput>cinder quota-update --<replaceable>quotaName</replaceable> <replaceable>NewValue</replaceable> <replaceable>tenantID</replaceable></userinput></screen>
|
|
<para>For example:</para>
|
|
<screen><prompt>#</prompt> <userinput>cinder quota-update --volumes 15 $tenant</userinput>
|
|
<prompt>#</prompt> <userinput>cinder quota-show tenant01</userinput>
|
|
<computeroutput>+-----------+-------+
|
|
| Property | Value |
|
|
+-----------+-------+
|
|
| gigabytes | 1000 |
|
|
| snapshots | 10 |
|
|
| volumes | 15 |
|
|
+-----------+-------+</computeroutput></screen>
|
|
</step>
|
|
</procedure>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
<section xml:id="user_mgmt">
|
|
<title>User Management</title>
|
|
<para>The command line tools for managing users are
|
|
inconvenient to use directly. They require issuing
|
|
multiple commands to complete a single task, and they use
|
|
UUIDs rather than symbolic names for many items. In
|
|
practice, humans typically do not use these tools
|
|
directly. Fortunately, the OpenStack Dashboard provides a
|
|
reasonable interface to this. In addition, many sites
|
|
write custom tools for local needs to enforce local
|
|
policies and provide levels of self service to users that
|
|
aren't currently available with packaged tools.</para>
|
|
</section>
|
|
<section xml:id="create_new_users">
|
|
<title>Creating New Users</title>
|
|
<para>To create a user, you need the following
|
|
information:</para>
|
|
<itemizedlist role="compact">
|
|
<listitem>
|
|
<para>Username</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Email address</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Password</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Primary project</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Role</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Username and email address are self-explanatory, though
|
|
your site may have local conventions you should observe.
|
|
Setting and changing passwords in the Identity Service
|
|
requires administrative privileges. As of the Folsom
|
|
release, users cannot change their own passwords. This is
|
|
a large driver for creating local custom tools, and must
|
|
be kept in mind when assigning and distributing passwords.
|
|
The primary project is simply the first project the user
|
|
is associated with and must exist prior to creating the
|
|
user. Role is almost always going to be "member". Out of
|
|
the box, OpenStack comes with two roles defined:</para>
|
|
<itemizedlist role="compact">
|
|
<listitem>
|
|
<para>"member": a typical user.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>"admin": an administrative super user which has
|
|
full permissions across all projects and should be
|
|
used with great care.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>It is possible to define other roles, but doing so is
|
|
uncommon.</para>
|
|
<para>Once you've gathered this information, creating the user
|
|
in the Dashboard is just another web form similar to what
|
|
we've seen before and can be found on the "Users" link in
|
|
the "Admin" navigation bar and then clicking the "Create
|
|
User" button at the top right.</para>
|
|
<para>Modifying users is also done from this "Users" page. If
|
|
you have a large number of users, this page can get quite
|
|
crowded. The "Filter" search box at the top of the page
|
|
can be used to limit the users listing. A form very
|
|
similar to the user creation dialog can be pulled up by
|
|
selecting "Edit" from the actions drop down menu at the
|
|
end of the line for the user you are modifying.</para>
|
|
</section>
|
|
<section xml:id="associate_users_with_projects">
|
|
<title>Associating Users with Projects</title>
|
|
<para>Many sites run with users being associated with only one
|
|
project. This is a more conservative and simpler choice
|
|
both for administration and for users. Administratively if
|
|
a user reports a problem with an instance or quota it is
|
|
obvious which project this relates to as well. Users
|
|
needn't worry about what project they are acting in if
|
|
they are only in one project. However, note that, by
|
|
default, any user can affect the resources of any other
|
|
user within their project. It is also possible to
|
|
associate users with multiple projects if that makes sense
|
|
for your organization.</para>
|
|
<para>Associating existing users with an additional project or
|
|
removing them from an older project is done from the
|
|
"Projects" page of the Dashboard by selecting the "Modify
|
|
Users" from the "Actions" column:</para>
|
|
<informalfigure>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata width="5in"
|
|
fileref="figures/horizon-user-project.png"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</informalfigure>
|
|
<para>From this view you can do a number of useful and a few
|
|
dangerous things.</para>
|
|
<para>The first column of this form, titled "All Users", will
|
|
include a list of all the users in your cloud who are not
|
|
already associated with this project and the second all
|
|
the users who are. These can be quite long, but can be
|
|
limited by typing a substring of the user name you are
|
|
looking for in the filter field at the top of the
|
|
column.</para>
|
|
<para>From here, click the <guiicon>+</guiicon> icon to add
|
|
users to the project. Click the <guiicon>-</guiicon> to
|
|
remove them.</para>
|
|
<para>The dangerous possibility comes in the ability to change
|
|
member roles. This is the drop down list after the user
|
|
name in the "Project Members" list. In virtually all cases
|
|
this value should be set to "Member". This example
|
|
purposefully show and administrative user where this value
|
|
is "admin".</para><important><para>The "admin" is global not per project so granting a user the
|
|
admin role in any project gives the administrative
|
|
rights across the whole cloud. </para></important>
|
|
<para>Typical use is to only create administrative users in a
|
|
single project, by convention the "admin" project which is
|
|
created by default during cloud setup. If your
|
|
administrative users also use the cloud to launch and
|
|
manage instances it is strongly recommended that you use
|
|
separate user accounts for administrative access and
|
|
normal operations and that they be in distinct
|
|
projects.</para>
|
|
<section xml:id="customize_auth">
|
|
<title>Customizing Authorization</title>
|
|
<para>The default <glossterm>authorization</glossterm>
|
|
settings only allow administrative users to create
|
|
resources on behalf of a different project. OpenStack
|
|
handles two kind of authorization policies:</para>
|
|
<itemizedlist role="compact">
|
|
<listitem>
|
|
<para>
|
|
<emphasis role="bold"
|
|
>Operation-based</emphasis>: policies
|
|
specify access criteria for specific
|
|
operations, possibly with fine-grained control
|
|
over specific attributes.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<emphasis role="bold"
|
|
>Resource-based</emphasis>: whether access
|
|
to a specific resource might be granted or not
|
|
according to the permissions configured for
|
|
the resource (currently available only for the
|
|
network resource). The actual authorization
|
|
policies enforced in an OpenStack service vary
|
|
from deployment to deployment.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>The policy engine reads entries from the
|
|
<code>policy.json</code> file. The actual location
|
|
of this file might vary from distribution to
|
|
distribution, for nova it is typically in
|
|
<code>/etc/nova/policy.json</code>. You can update
|
|
entries while the system is running, and you do not
|
|
have to restart services. Currently the only way to
|
|
update such policies is to edit the policy
|
|
file.</para>
|
|
<para>The OpenStack service's policy engine matches a
|
|
policy directly. A rule indicates evaluation of the
|
|
elements of such policies. For instance, in a
|
|
<code>compute:create:
|
|
[["rule:admin_or_owner"]]</code> statement, the
|
|
policy is <code>compute:create</code>, and the rule is
|
|
<code>admin_or_owner</code>.</para>
|
|
<para>Policies are triggered by an OpenStack policy engine
|
|
whenever one of them matches an OpenStack API
|
|
operation or a specific attribute being used in a
|
|
given operation. For instance, the engine tests the
|
|
<code>create:compute</code> policy every time a
|
|
user sends a <code>POST /v2/{tenant_id}/servers</code>
|
|
request to the OpenStack Compute API server. Policies
|
|
can be also related to specific <glossterm>API
|
|
extension</glossterm>s. For instance, if a user
|
|
needs an extension like
|
|
<code>compute_extension:rescue</code> the
|
|
attributes defined by the provider extensions trigger
|
|
the rule test for that operation.</para>
|
|
<para>An authorization policy can be composed by one or
|
|
more rules. If more rules are specified, evaluation
|
|
policy is successful if any of the rules evaluates
|
|
successfully; if an API operation matches multiple
|
|
policies, then all the policies must evaluate
|
|
successfully. Also, authorization rules are recursive.
|
|
Once a rule is matched, the rule(s) can be resolved to
|
|
another rule, until a terminal rule is reached. These
|
|
are the rules defined:</para>
|
|
<itemizedlist role="compact">
|
|
<listitem>
|
|
|
|
<para>
|
|
<emphasis role="bold">Role-based
|
|
rules</emphasis>: evaluate successfully if
|
|
the user submitting the request has the
|
|
specified role. For instance
|
|
<code>"role:admin"</code>is successful if
|
|
the user submitting the request is an
|
|
administrator.</para>
|
|
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<emphasis role="bold">Field-based rules:
|
|
</emphasis>evaluate successfully if a field of
|
|
the resource specified in the current request
|
|
matches a specific value. For instance
|
|
<code>"field:networks:shared=True"</code>
|
|
is successful if the attribute shared of the
|
|
network resource is set to true.</para>
|
|
|
|
</listitem>
|
|
<listitem>
|
|
|
|
<para>
|
|
<emphasis role="bold">Generic
|
|
rules:</emphasis> compare an attribute in
|
|
the resource with an attribute extracted from
|
|
the user's security credentials and evaluates
|
|
successfully if the comparison is successful.
|
|
For instance
|
|
<code>"tenant_id:%(tenant_id)s"</code> is
|
|
successful if the tenant identifier in the
|
|
resource is equal to the tenant identifier of
|
|
the user submitting the request.</para>
|
|
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Here are snippets of the default nova
|
|
<filename>policy.json</filename> file:</para>
|
|
<programlisting><?db-font-size 65%?>{
|
|
"context_is_admin": [["role:admin"]],
|
|
"admin_or_owner": [["is_admin:True"], ["project_id:%(project_id)s"]], <emphasis role="bold">[1]</emphasis>
|
|
"default": [["rule:admin_or_owner"]], <emphasis role="bold">[2]</emphasis>
|
|
"compute:create": [ ],
|
|
"compute:create:attach_network": [ ],
|
|
"compute:create:attach_volume": [ ],
|
|
"compute:get_all": [ ],
|
|
"admin_api": [["is_admin:True"]],
|
|
"compute_extension:accounts": [["rule:admin_api"]],
|
|
"compute_extension:admin_actions": [["rule:admin_api"]],
|
|
"compute_extension:admin_actions:pause": [["rule:admin_or_owner"]],
|
|
"compute_extension:admin_actions:unpause": [["rule:admin_or_owner"]],
|
|
...
|
|
"compute_extension:admin_actions:migrate": [["rule:admin_api"]],
|
|
"compute_extension:aggregates": [["rule:admin_api"]],
|
|
"compute_extension:certificates": [ ],
|
|
...
|
|
"compute_extension:flavorextraspecs": [ ],
|
|
"compute_extension:flavormanage": [["rule:admin_api"]], <emphasis role="bold">[3]</emphasis>
|
|
}
|
|
</programlisting>
|
|
<para>[1] Shows a rule which evaluates successfully if the
|
|
current user is an administrator or the owner of the
|
|
resource specified in the request (tenant identifier
|
|
is equal).</para>
|
|
<para>[2] Shows the default policy which is always
|
|
evaluated if an API operation does not match any of
|
|
the policies in <code>policy.json</code>.</para>
|
|
<para>[3] Shows a policy restricting the ability of
|
|
manipulating flavors to administrators using the Admin
|
|
API only.</para>
|
|
<para>In some cases, some operations should be restricted
|
|
to administrators only. Therefore, as a further
|
|
example, let us consider how this sample policy file
|
|
could be modified in a scenario where we enable users
|
|
to create their own flavors:</para>
|
|
<programlisting><?db-font-size 65%?>"compute_extension:flavormanage": [ ],</programlisting>
|
|
</section>
|
|
<section xml:id="problem_users">
|
|
<title>Users that Disrupt Other Users</title>
|
|
<para>Users on your cloud can disrupt other users,
|
|
sometimes intentionally and maliciously and other
|
|
times by accident. Understanding the situation allows
|
|
you to make a better decision on how to handle the
|
|
disruption.</para>
|
|
<para>For example: A group of users have instances that
|
|
are utilizing a large amount of compute resources for
|
|
very compute-intensive tasks. This is driving the load
|
|
up on compute nodes and affecting other users. In this
|
|
situation, review your user use cases. You may find
|
|
that high compute scenarios are common and should then
|
|
plan for proper segregation in your cloud such as host
|
|
aggregation or regions.</para>
|
|
<para>Another example is a user consuming a very large
|
|
amount of bandwidth. Again, the key is to understand
|
|
what the user is doing. If they naturally need a high
|
|
amount of bandwidth, you might have to limit their
|
|
transmission rate as to not affect other users or move
|
|
them to an area with more bandwidth available. On the
|
|
other hand, maybe the user's instance has been hacked
|
|
and is part of a botnet launching DDOS attacks.
|
|
Resolution to this issue is the same as if any other
|
|
server on your network has been hacked. Contact the
|
|
user and give them time to respond. If they don't
|
|
respond, shut the instance down.</para>
|
|
<para>A final example is if a user is hammering cloud
|
|
resources repeatedly. Contact the user and learn what
|
|
they are trying to do. Maybe they don't understand
|
|
that what they're doing is inappropriate or maybe
|
|
there is an issue with the resource they are trying to
|
|
access that is causing their requests to queue or
|
|
lag.</para>
|
|
<para>One key element of systems administration that is
|
|
often overlooked is that end users are the reason why
|
|
systems administrators exist. Don't go the BOFH route
|
|
and terminate every user who causes an alert to go
|
|
off. Work with them to understand what they're trying
|
|
to accomplish and see how your environment can better
|
|
assist them in achieving their goals.</para>
|
|
</section>
|
|
</section>
|
|
</chapter>
|