openstack/security-doc
Code Issues Proposed changes

Replace 'username' with 'user name' per convention

Browse Source 
Per IBM style 'user name' is the proper convention, updating security guide to reflect this

Closes-Bug: #1341809
Change-Id: I5ed5c85d5b53c6671a887ee9faa006f43c62f7c6
This commit is contained in:
sicarie
2014-07-15 10:58:50 -07:00
parent 527d2594d5
commit 9220c9f908
5 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
security-guide/ch_database-access-control.xml
View File

@@ -50,7 +50,7 @@
</section>
<section xml:id="database-access-control-idp83456">
<title>Database authentication and access control</title>
<para>Given the risks around access to the database, we strongly recommend that unique database user accounts be created per node needing access to the database. Doing this facilitates better analysis and auditing for ensuring compliance or in the event of a compromise of a node allows you to isolate the compromised host by removing access for that node to the database upon detection. When creating these per service endpoint database user accounts, care should be taken to ensure that they are configured to require SSL. Alternatively, for increased security it is recommended that the database accounts be configured using X.509 certificate authentication in addition to usernames and passwords.</para>
<para>Given the risks around access to the database, we strongly recommend that unique database user accounts be created per node needing access to the database. Doing this facilitates better analysis and auditing for ensuring compliance or in the event of a compromise of a node allows you to isolate the compromised host by removing access for that node to the database upon detection. When creating these per service endpoint database user accounts, care should be taken to ensure that they are configured to require SSL. Alternatively, for increased security it is recommended that the database accounts be configured using X.509 certificate authentication in addition to user names and passwords.</para>
<section xml:id="database-access-control-idp85888">
<title>Privileges</title>
<para>A separate database administrator (DBA) account should be created and protected that has full privileges to create/drop databases, create user accounts, and update user privileges. This simple means of separation of responsibility helps prevent accidental misconfiguration, lowers risk and lowers scope of compromise.</para>

4
security-guide/ch_identity.xml
View File

@@ -7,7 +7,7 @@
<?dbhtml stop-chunking?>
<title>Identity</title>
<para>The OpenStack Identity service (keystone) supports multiple
methods of authentication, including username &amp; password,
methods of authentication, including user name &amp; password,
LDAP, and external authentication methods. Upon successful
authentication, The Identity Service provides the user with an
authorization token used for subsequent service requests.</para>
@@ -184,7 +184,7 @@
<para>The Identity Service supports client authentication for
SSL which may be enabled. SSL client authentication provides
an additional authentication factor, in addition to the
username / password, that provides greater reliability on user
user name / password, that provides greater reliability on user
identification. It reduces the risk of unauthorized access
when user names and passwords may be compromised. However,
there is additional administrative overhead and cost to issue

4
security-guide/ch_messaging-security.xml
View File

@@ -56,8 +56,8 @@
<section xml:id="messaging-security-idp48960">
<title>Queue authentication and access control</title>
<para>RabbitMQ and Qpid offer authentication and access control mechanisms for controlling access to queues. ZeroMQ offers no such mechanisms.</para>
<para>Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. Both RabbitMQ and Qpid offer SASL and other pluggable authentication mechanisms beyond simple usernames and passwords that allow for increased authentication security. While RabbitMQ supports SASL, support in OpenStack does not currently allow for requesting a specific SASL authentication mechanism. RabbitMQ support in OpenStack allows for either username and password authentication over an unencrypted connection or username and password in conjunction with X.509 client certificates to establish the secure SSL connection.</para>
<para>We recommend configuring X.509 client certificates on all the OpenStack service nodes for client connections to the messaging queue and where possible (currently only Qpid) perform authentication with X.509 client certificates. When using usernames and passwords, accounts should be created per-service and node for finer grained auditability of access to the queue.</para>
<para>Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. Both RabbitMQ and Qpid offer SASL and other pluggable authentication mechanisms beyond simple user names and passwords that allow for increased authentication security. While RabbitMQ supports SASL, support in OpenStack does not currently allow for requesting a specific SASL authentication mechanism. RabbitMQ support in OpenStack allows for either user name and password authentication over an unencrypted connection or user name and password in conjunction with X.509 client certificates to establish the secure SSL connection.</para>
<para>We recommend configuring X.509 client certificates on all the OpenStack service nodes for client connections to the messaging queue and where possible (currently only Qpid) perform authentication with X.509 client certificates. When using user names and passwords, accounts should be created per-service and node for finer grained auditability of access to the queue.</para>
<para>
Before deployment, consider the SSL libraries that the queuing
servers use. Qpid uses Mozilla's NSS library, whereas RabbitMQ

4
security-guide/ch_object-storage.xml
View File

@@ -123,7 +123,7 @@
<title>Service runas user</title>
<para>It is recommended that you configure each service to
run under a non-root (UID 0) service account. One
recommendation is the username "swift" with primary
recommendation is the user name "swift" with primary
group "swift."</para>
</section>
<section xml:id="object-storage-idpC123">
@@ -341,7 +341,7 @@ Group swift</programlisting>
<para>Object Storage uses wsgi to provide a middleware for
authentication of end-point clients. The authentication
provider defines what roles and user types exist. Some use
traditional username and password credentials while others
traditional user name and password credentials while others
may leverage API key tokens or even client-side x.509 SSL
certificates. Custom providers can be integrated in using
the wsgi model.</para>

2
security-guide/ch_security-boundaries-and-threats.xml
View File

@@ -74,7 +74,7 @@
<title>Management</title>
<para>The management security domain is where services interact. Sometimes referred to as the
"control plane", the networks in this domain transport confidential data such as
configuration parameters, usernames, and passwords. Command and Control traffic typically
configuration parameters, user names, and passwords. Command and Control traffic typically
resides in this domain, which necessitates strong integrity requirements. Access to this
domain should be highly restricted and monitored. At the same time, this domain should still
employ all of the security best practices described in this guide.</para>