diff --git a/doc/source/Draft Security Guide/Documentation LICENSE.txt b/doc/source/Draft Security Guide/Documentation LICENSE.txt new file mode 100644 index 0000000..242e8a3 --- /dev/null +++ b/doc/source/Draft Security Guide/Documentation LICENSE.txt @@ -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/ \ No newline at end of file diff --git a/doc/source/Draft Security Guide/SWAuth Security Explained, Rodney Beede, 2013-12-13.pdf b/doc/source/Draft Security Guide/SWAuth Security Explained, Rodney Beede, 2013-12-13.pdf new file mode 100644 index 0000000..06114d1 Binary files /dev/null and b/doc/source/Draft Security Guide/SWAuth Security Explained, Rodney Beede, 2013-12-13.pdf differ diff --git a/doc/source/Draft Security Guide/docbook SWAuth snippet, Rodney Beede, 2013-12-13.xml b/doc/source/Draft Security Guide/docbook SWAuth snippet, Rodney Beede, 2013-12-13.xml new file mode 100644 index 0000000..60841e1 --- /dev/null +++ b/doc/source/Draft Security Guide/docbook SWAuth snippet, Rodney Beede, 2013-12-13.xml @@ -0,0 +1,120 @@ +
+ SWAuth + 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 + http://gholt.github.io/swauth/. + SWAuth has these types of roles (or groups) for a + user: + + + + .super_admin + Can perform any action on any + OpenStack Account, Container, or Object + + + .reseller_admin + Can perform most actions on + any OpenStack Account, Container, or Object. + Cannot create other reseller admins. + + + + .admin + Can perform actions limited to + the single OpenStack Account it belongs to + + + Regular User + Can access containers or + objects they have permission to in the + OpenStack Account to which they belong + + + + + The following table provides a matrix of what each + role/group can do: +
+ Object storage SWAuth role matrix + + + + + + + + +
+ The super admin key is stored in + /etc/swift/proxy-server.conf and MUST + be protected! See the File Permissions section for + guidance on protecting this file. Frequent changing of + this key is recommended. + 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. + 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. +
+ Protecting cloud administration + 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 + allow_account_managment to false in your + proxy-server.conf. + 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. +
+
+ Salting and hashing passwords + 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. + You may optionally add-in your own hashing code + or provider as a hook to SWAuth. See the + SWAuth code and site + for details. + 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. + 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. + The salt is stored in the + /etc/swift/proxy-server.conf + file which must be secured with proper ACLs. See the + File Permissions section for guidance. +
+
+ \ No newline at end of file diff --git a/doc/source/Draft Security Guide/swift_swauth_roles_matrix.png b/doc/source/Draft Security Guide/swift_swauth_roles_matrix.png new file mode 100644 index 0000000..9401c4a Binary files /dev/null and b/doc/source/Draft Security Guide/swift_swauth_roles_matrix.png differ