General updates to Compute for style and convention
Editing the nested sections for the compute chapter. Mostly grammar, wording, style, convention, etc. This patch includes rootwrap and security. Watch this space for more. Change-Id: I63d9691e64f14c4eba9ca4440930f06e757f9750 Partial-Bug: #1251195
This commit is contained in:
Lana Brindley
parent
6b4aa47f9a
commit
e880c6e326
@ -4,113 +4,93 @@
|
|||||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
version="5.0"
|
version="5.0"
|
||||||
xml:id="root-wrap-reference">
|
xml:id="root-wrap-reference">
|
||||||
<title>Secure with root wrappers</title>
|
<title>Secure with rootwrap</title>
|
||||||
<para>The root wrapper enables an unprivileged user to run a number of Compute actions as the
|
<para>Rootwrap allows unprivileged users to safely run Compute actions
|
||||||
root user in the safest manner possible. Historically, Compute used a specific
|
as the root user. Compute previously used <command>sudo</command> for
|
||||||
<filename>sudoers</filename> file that listed every command that the Compute user was
|
this purpose, but this was difficult to maintain, and did not allow
|
||||||
allowed to run, and used <command>sudo</command> to run that command as
|
advanced filters. The <command>rootwrap</command> command replaces
|
||||||
<literal>root</literal>. However this was difficult to maintain (the
|
<command>sudo</command> for Compute.</para>
|
||||||
<filename>sudoers</filename> file was in packaging), and did not enable complex
|
<para>To use rootwrap, prefix the Compute command with
|
||||||
filtering of parameters (advanced filters). The rootwrap was designed to solve those
|
<command>nova-rootwrap</command>. For example:</para>
|
||||||
issues.</para>
|
<screen><prompt>$</prompt> <userinput>sudo nova-rootwrap /etc/nova/rootwrap.conf <replaceable>command</replaceable></userinput></screen>
|
||||||
<simplesect>
|
<para>
|
||||||
<title>How rootwrap works</title>
|
A generic <filename>sudoers</filename> entry lets the Compute user run
|
||||||
<para>Instead of calling <command>sudo make me a sandwich</command>, Compute services start
|
<command>nova-rootwrap</command> as root. The
|
||||||
with a <command>nova-rootwrap</command> call; for example, <command>sudo nova-rootwrap
|
<command>nova-rootwrap</command> code looks for filter definition
|
||||||
/etc/nova/rootwrap.conf make me a sandwich</command>. A generic sudoers entry lets
|
directories in its configuration file, and loads command filters from
|
||||||
the Compute user run <command>nova-rootwrap</command> as root. The
|
them. It then checks if the command requested by Compute matches one of
|
||||||
<command>nova-rootwrap</command> code looks for filter definition directories in its
|
those filters and, if so, executes the command (as root). If no filter
|
||||||
configuration file, and loads command filters from them. Then it checks if the command
|
matches, it denies the request.</para>
|
||||||
requested by Compute matches one of those filters, in which case it executes the command
|
<note><para>Be aware of issues with using NFS and root-owned files. The
|
||||||
(as root). If no filter matches, it denies the request.</para>
|
NFS share must be configured with the <option>no_root_squash</option>
|
||||||
<note><para>To use <command>nova-rootwrap</command>, you must be aware of the issues with using NFS and
|
option enabled, in order for rootwrap to work correctly.</para>
|
||||||
root-owned files. The NFS share must be configured with the
|
</note>
|
||||||
<option>no_root_squash</option> option enabled.</para>
|
<para>Rootwrap is fully controlled by the root user. The root user owns
|
||||||
</note>
|
the sudoers entry which allows Compute to run a specific rootwrap
|
||||||
</simplesect>
|
executable as root, and only with a specific configuration file (which
|
||||||
<simplesect>
|
should also be owned by root). The <command>nova-rootwrap</command>
|
||||||
<title>Security model</title>
|
command imports the Python modules it needs from a cleaned,
|
||||||
<para>The escalation path is fully controlled by the root user. A sudoers entry (owned by
|
system-default <replaceable>PYTHONPATH</replaceable>. The root-owned
|
||||||
root) allows Compute to run (as root) a specific rootwrap executable, and only with a
|
configuration file points to root-owned filter definition directories,
|
||||||
specific configuration file (which should be owned by root).
|
which contain root-owned filters definition files. This chain ensures
|
||||||
<command>nova-rootwrap</command> imports the Python modules it needs from a cleaned
|
that the Compute user itself is not in control of the configuration or
|
||||||
(and system-default) <replaceable>PYTHONPATH</replaceable>. The configuration file (also
|
modules used by the <command>nova-rootwrap</command> executable.</para>
|
||||||
root-owned) points to root-owned filter definition directories, which contain root-owned
|
<para>Rootwrap is configured using the <filename>rootwrap.conf</filename>
|
||||||
filters definition files. This chain ensures that the Compute user itself is not in
|
file. Because it's in the trusted security path, it must be owned and
|
||||||
control of the configuration or modules used by the <command>nova-rootwrap</command>
|
writable by only the root user. The file's location is specified in both
|
||||||
executable.</para>
|
the sudoers entry and in the <filename>nova.conf</filename> configuration
|
||||||
</simplesect>
|
file with the <parameter>rootwrap_config=entry</parameter> parameter.</para>
|
||||||
<simplesect>
|
<para>The <filename>rootwrap.conf</filename> file uses an INI file format
|
||||||
<title>Details of rootwrap.conf</title>
|
with these sections and parameters:</para>
|
||||||
<para>You configure <command>nova-rootwrap</command> in the
|
<table rules="all" frame="border" xml:id="rootwrap-conf-table-filter-path" width="100%">
|
||||||
<filename>rootwrap.conf</filename> file. Because it's in the trusted security path,
|
<caption>rootwrap.conf configuration options</caption>
|
||||||
it must be owned and writable by only the root user. The file's location is specified
|
<col width="50%"/>
|
||||||
both in the sudoers entry and in the <filename>nova.conf</filename> configuration file
|
<col width="50%"/>
|
||||||
with the <code>rootwrap_config=entry</code>.</para>
|
<thead>
|
||||||
<para>The <filename>rootwrap.conf</filename> file uses an INI file format with these
|
<tr>
|
||||||
sections and parameters:</para>
|
<td><para>Configuration option=Default value</para></td>
|
||||||
<table rules="all" frame="border"
|
<td><para>(Type) Description</para></td>
|
||||||
xml:id="rootwrap-conf-table-filter-path" width="100%">
|
</tr>
|
||||||
<caption>rootwrap.conf configuration options</caption>
|
</thead>
|
||||||
<col width="50%"/>
|
<tbody>
|
||||||
<col width="50%"/>
|
<tr>
|
||||||
<thead>
|
<td><para>[DEFAULT]</para>
|
||||||
<tr>
|
<para>filters_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap</para></td>
|
||||||
<td><para>Configuration option=Default
|
<td><para>(ListOpt) Comma-separated list of directories containing
|
||||||
value</para></td>
|
filter definition files. Defines where rootwrap filters are
|
||||||
<td><para>(Type) Description</para></td>
|
stored. Directories defined on this line should all exist, and be
|
||||||
</tr>
|
owned and writable only by the root user.</para></td>
|
||||||
</thead>
|
</tr>
|
||||||
<tbody>
|
</tbody>
|
||||||
<tr>
|
</table>
|
||||||
<td><para>[DEFAULT]</para>
|
<para>The filters definition files contain lists of filters that rootwrap
|
||||||
<para>filters_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap
|
will use to allow or deny a specific command. They are generally
|
||||||
</para></td>
|
suffixed by <literal>.filters</literal>. Since they are in the trusted
|
||||||
<td><para>(ListOpt) Comma-separated list of
|
security path, they need to be owned and writable only by the root user.
|
||||||
directories containing filter definition
|
Their location is specified in the <filename>rootwrap.conf</filename>
|
||||||
files. Defines where filters for root wrap
|
file.</para>
|
||||||
are stored. Directories defined on this
|
<para>Filter definition files use an INI file format with a
|
||||||
line should all exist, be owned and
|
<parameter>[Filters]</parameter> section and several lines, each with a
|
||||||
writable only by the root
|
unique parameter name, which should be different for each filter you
|
||||||
user.</para></td>
|
define:</para>
|
||||||
</tr>
|
<table rules="all" frame="border" xml:id="rootwrap-conf-table-filter-name" width="100%">
|
||||||
</tbody>
|
<caption>.filters configuration options</caption>
|
||||||
</table>
|
<col width="50%"/>
|
||||||
</simplesect>
|
<col width="50%"/>
|
||||||
<simplesect>
|
<thead>
|
||||||
<title>Details of .filters files</title>
|
<tr>
|
||||||
<para>Filters definition files contain lists of filters that
|
<td><para>Configuration option=Default value</para></td>
|
||||||
<command>nova-rootwrap</command> will use to allow or deny a specific command. They
|
<td><para>(Type) Description</para></td>
|
||||||
are generally suffixed by .filters. Since they are in the trusted security path, they
|
</tr>
|
||||||
need to be owned and writable only by the root user. Their location is specified in the
|
</thead>
|
||||||
<filename>rootwrap.conf</filename> file.</para>
|
<tbody>
|
||||||
<para>Filter definition files use an INI file format with a [Filters] section and several
|
<tr>
|
||||||
lines, each with a unique parameter name (different for each filter that you
|
<td><para>[Filters]</para>
|
||||||
define):</para>
|
<para>filter_name=kpartx: CommandFilter, /sbin/kpartx, root</para></td>
|
||||||
<table rules="all" frame="border"
|
<td><para>(ListOpt) Comma-separated list containing the filter class
|
||||||
xml:id="rootwrap-conf-table-filter-name" width="100%">
|
to use, followed by the Filter arguments (which vary depending
|
||||||
<caption>.filters configuration options</caption>
|
on the Filter class selected).</para></td>
|
||||||
<col width="50%"/>
|
</tr>
|
||||||
<col width="50%"/>
|
</tbody>
|
||||||
<thead>
|
</table>
|
||||||
<tr>
|
|
||||||
<td><para>Configuration option=Default
|
|
||||||
value</para></td>
|
|
||||||
<td><para>(Type) Description</para></td>
|
|
||||||
</tr>
|
|
||||||
</thead>
|
|
||||||
<tbody>
|
|
||||||
<tr>
|
|
||||||
<td><para>[Filters]</para>
|
|
||||||
<para>filter_name=kpartx: CommandFilter,
|
|
||||||
/sbin/kpartx, root</para></td>
|
|
||||||
<td><para>(ListOpt) Comma-separated list
|
|
||||||
containing first the Filter class to use,
|
|
||||||
followed by that Filter arguments (which
|
|
||||||
vary depending on the Filter class
|
|
||||||
selected).</para></td>
|
|
||||||
</tr>
|
|
||||||
</tbody>
|
|
||||||
</table>
|
|
||||||
</simplesect>
|
|
||||||
</section>
|
</section>
|
||||||
|
|||||||
@ -2,23 +2,28 @@
|
|||||||
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
|
<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="section-compute-security">
|
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="section-compute-security">
|
||||||
<title>Security hardening</title>
|
<title>Security hardening</title>
|
||||||
<para>You can integrate OpenStack Compute with various third-party technologies to increase
|
<para>OpenStack Compute can be integrated with various third-party
|
||||||
security. For information, see the <link xlink:href="http://docs.openstack.org/sec/"
|
technologies to increase security. For more information, see the
|
||||||
><citetitle>OpenStack Security Guide</citetitle></link>.</para>
|
<link xlink:href="http://docs.openstack.org/sec/">
|
||||||
|
<citetitle>OpenStack Security Guide</citetitle></link>.</para>
|
||||||
|
|
||||||
<xi:include href="section_trusted-compute-pools.xml"/>
|
<xi:include href="section_trusted-compute-pools.xml"/>
|
||||||
|
|
||||||
<section xml:id="section_compute_metadata_https">
|
<section xml:id="section_compute_metadata_https">
|
||||||
<title>Encrypt Compute metadata traffic</title>
|
<title>Encrypt Compute metadata traffic</title>
|
||||||
<para>OpenStack Juno supports encrypting Compute metadata traffic with HTTPS. You enable SSL
|
<para>OpenStack supports encrypting Compute metadata traffic with HTTPS.
|
||||||
encryption in the <filename>metadata_agent.ini</filename> file.</para>
|
Enable SSL encryption in the <filename>metadata_agent.ini</filename>
|
||||||
|
file.</para>
|
||||||
<procedure>
|
<procedure>
|
||||||
<title>To enable SSL encryption</title>
|
<title>Enabling SSL encryption</title>
|
||||||
<step>
|
<step>
|
||||||
<para>Enable the HTTPS protocol:</para>
|
<para>Enable the HTTPS protocol:</para>
|
||||||
<programlisting>nova_metadata_protocol = https</programlisting>
|
<programlisting>nova_metadata_protocol = https</programlisting>
|
||||||
</step>
|
</step>
|
||||||
<step>
|
<step>
|
||||||
<para>Determine whether insecure SSL connections are accepted for Compute metadata server
|
<para>Determine whether insecure SSL connections are accepted for
|
||||||
requests. The default value is <option>False</option>:</para>
|
Compute metadata server requests. The default value is
|
||||||
|
<option>False</option>:</para>
|
||||||
<programlisting>nova_metadata_insecure = False</programlisting>
|
<programlisting>nova_metadata_insecure = False</programlisting>
|
||||||
</step>
|
</step>
|
||||||
<step>
|
<step>
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user