x/swauth
Code Issues Proposed changes

Added draft of security guide to my forked repo of swauth.

Browse Source
This commit is contained in:
Rodney Beede 2013-12-13 10:43:16 -06:00
parent 96d6e54385
commit f0415ed5b0
4 changed files with 129 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/source/Draft Security Guide/Documentation LICENSE.txt Normal file
View File

@ -0,0 +1,9 @@
This document is licensed under Creative Commons Attribution 3.0 License.
http://creativecommons.org/licenses/by/3.0/legalcode
Rodney Beede
http://www.rodneybeede.com/

BIN
doc/source/Draft Security Guide/SWAuth Security Explained, Rodney Beede, 2013-12-13.pdf Normal file
View File

Binary file not shown.

120
doc/source/Draft Security Guide/docbook SWAuth snippet, Rodney Beede, 2013-12-13.xml Normal file
View File

@ -0,0 +1,120 @@
<section xml:id="ch027_storage-idpH123">
<title>SWAuth</title>
<para>SWAuth is another popular alternative to Keystone.
In contrast to Keystone it stores the user accounts,
credentials, and metadata in object storage itself. More
specifics about where the objects are stored can be found
on the SWAuth website at
<link xlink:href="http://gholt.github.io/swauth/">http://gholt.github.io/swauth/</link>.</para>
<para>SWAuth has these types of roles (or groups) for a
user:</para>
<informaltable>
<tbody>
<tr>
<td>.super_admin</td>
<td>Can perform any action on any
OpenStack Account, Container, or Object</td>
</tr>
<tr>
<td>.reseller_admin</td>
<td>Can perform most actions on
any OpenStack Account, Container, or Object.
Cannot create other reseller admins.
</td>
</tr>
<tr>
<td>.admin</td>
<td>Can perform actions limited to
the single OpenStack Account it belongs to</td>
</tr>
<tr>
<td>Regular User</td>
<td>Can access containers or
objects they have permission to in the
OpenStack Account to which they belong
</td>
</tr>
</tbody>
</informaltable>
<para>The following table provides a matrix of what each
role/group can do:</para>
<figure>
<title>Object storage SWAuth role matrix</title>
<mediaobject>
<imageobject role="html">
<imagedata contentdepth="393"
contentwidth="1047"
fileref="static/swift_swauth_roles_matrix.png"
format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/swift_swauth_roles_matrix.png"
format="PNG" scalefit="1" width="100%"/>
</imageobject>
</mediaobject>
</figure>
<warning><para>The super admin key is stored in
<filename>/etc/swift/proxy-server.conf</filename> and MUST
be protected! See the File Permissions section for
guidance on protecting this file. Frequent changing of
this key is recommended.</para></warning>
<para>One approach for administration is to create an
OpenStack Object Storage Account called "CloudAdmins" and
create reseller_admin users in that account. Each user
will be able to do administrative functions in all the
other accounts. Creating a reseller_admin will require
the super admin key.</para>
<para>Another useful way to secure the super admin key is
to have it exist only on the proxy server and retrieve the
key on-demand via ssh or by running the command on the
proxy server itself and using a grep to extract the key on
the fly.</para>
<section xml:id="ch027_storage-idpH1234">
<title>Protecting cloud administration</title>
<para>When using SWAuth you can actually designate
that certain proxy service nodes are to NOT allow
administrator API calls. This is useful if you have
Proxy service nodes on the public Internet and wish to
restrict administration functions to only special
Proxy service nodes on a private network. This is
done by setting the
<code>allow_account_managment</code> to false in your
<filename>proxy-server.conf</filename>.</para>
<para>Another important consideration is that the
SWAuth command line tools expose the user credentials
on the command-line. The system from which they are
executed must be secure to prevent disclosure in the
process list to other uses. Another option is to use
the SWAuth admin REST API to implement your own admin
CLI tools that don’t expose the key as a command-line
option.</para>
</section>
<section xml:id="ch027_storage-idpH12345">
<title>Salting and hashing passwords</title>
<para>SWAuth by default stores passwords in
clear-text. It also offers a sha1 hashing provider,
but the salt used is global. Additionally, no
iterations or key stretching is performed. This is a
limitation of SWAuth.</para>
<para>You may optionally add-in your own hashing code
or provider as a hook to SWAuth. See the
<link xlink:href="http://gholt.github.io/swauth/dev/authtypes.html">SWAuth code and site</link>
for details.</para>
<para>If you use the global salt be sure to secure it
and back it up. If you have multiple proxy nodes each
one has to have a copy so that may be good enough for
you. If you ever lose it or change it then all
existing user passwords will not work and will have to
be reset.</para>
<para>You should make sure the salt you choose is
generated using a cryptographically secure random
number generator and of sufficient length. At least
20 characters is recommended.</para>
<para>The salt is stored in the
<filename>/etc/swift/proxy-server.conf</filename>
file which must be secured with proper ACLs. See the
File Permissions section for guidance.</para>
</section>
</section><!-- SWAuth -->
</section><!-- Object Storage Authentication -->

BIN
doc/source/Draft Security Guide/swift_swauth_roles_matrix.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB