From 9220c9f908c247c8b5d82e03b6bfa9ce70c7d94f Mon Sep 17 00:00:00 2001 From: sicarie Date: Tue, 15 Jul 2014 10:58:50 -0700 Subject: [PATCH] Replace 'username' with 'user name' per convention Per IBM style 'user name' is the proper convention, updating security guide to reflect this Closes-Bug: #1341809 Change-Id: I5ed5c85d5b53c6671a887ee9faa006f43c62f7c6 --- security-guide/ch_database-access-control.xml | 2 +- security-guide/ch_identity.xml | 4 ++-- security-guide/ch_messaging-security.xml | 4 ++-- security-guide/ch_object-storage.xml | 4 ++-- security-guide/ch_security-boundaries-and-threats.xml | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/security-guide/ch_database-access-control.xml b/security-guide/ch_database-access-control.xml index 46ef9f52..043167ce 100644 --- a/security-guide/ch_database-access-control.xml +++ b/security-guide/ch_database-access-control.xml @@ -50,7 +50,7 @@
Database authentication and access control - 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. + 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.
Privileges 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. diff --git a/security-guide/ch_identity.xml b/security-guide/ch_identity.xml index fac35081..45f74020 100644 --- a/security-guide/ch_identity.xml +++ b/security-guide/ch_identity.xml @@ -7,7 +7,7 @@ Identity The OpenStack Identity service (keystone) supports multiple - methods of authentication, including username & password, + methods of authentication, including user name & password, LDAP, and external authentication methods. Upon successful authentication, The Identity Service provides the user with an authorization token used for subsequent service requests. @@ -184,7 +184,7 @@ 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 diff --git a/security-guide/ch_messaging-security.xml b/security-guide/ch_messaging-security.xml index 1fdd90a6..6712f100 100644 --- a/security-guide/ch_messaging-security.xml +++ b/security-guide/ch_messaging-security.xml @@ -56,8 +56,8 @@
Queue authentication and access control RabbitMQ and Qpid offer authentication and access control mechanisms for controlling access to queues. ZeroMQ offers no such mechanisms. - 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. - 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. + 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. + 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. Before deployment, consider the SSL libraries that the queuing servers use. Qpid uses Mozilla's NSS library, whereas RabbitMQ diff --git a/security-guide/ch_object-storage.xml b/security-guide/ch_object-storage.xml index 40a4cb9f..2b01b05d 100644 --- a/security-guide/ch_object-storage.xml +++ b/security-guide/ch_object-storage.xml @@ -123,7 +123,7 @@ Service runas user 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."
@@ -341,7 +341,7 @@ Group swift 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. diff --git a/security-guide/ch_security-boundaries-and-threats.xml b/security-guide/ch_security-boundaries-and-threats.xml index 324170d8..4b242adf 100644 --- a/security-guide/ch_security-boundaries-and-threats.xml +++ b/security-guide/ch_security-boundaries-and-threats.xml @@ -74,7 +74,7 @@ Management 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.