Added complete Doc Convention to Security Guide.
Change-Id: I8310331f48399310d1a5d7af88bd91fba20ea89c Partial-Bug: #1121866
This commit is contained in:
Chandan kumar
parent
b095baffec
commit
77ec2d6e4c
@ -68,49 +68,49 @@
|
||||
</imageobject>
|
||||
</inlinemediaobject></para>
|
||||
<section xml:id="ch004_book-introduction-idp134736">
|
||||
<title>OpenStack Compute</title>
|
||||
<para>OpenStack compute (Nova) provides services to support the management of virtual machine instances at scale, instances that host multi-tiered applications, dev/test environments, "Big Data" crunching Hadoop clusters, and/or high performance computing.</para>
|
||||
<para>Nova facilitates this management through an abstraction layer that interfaces with supported hypervisors, which we address later on in more detail.</para>
|
||||
<title>Compute</title>
|
||||
<para>OpenStack Compute Service (Nova) provides services to support the management of virtual machine instances at scale, instances that host multi-tiered applications, dev/test environments, "Big Data" crunching Hadoop clusters, and/or high performance computing.</para>
|
||||
<para>The Compute Service facilitates this management through an abstraction layer that interfaces with supported hypervisors, which we address later on in more detail.</para>
|
||||
<para>Later in the guide, we focus generically on the
|
||||
virtualization stack as it relates to hypervisors.</para>
|
||||
<para>For information about the current state of feature support, see
|
||||
<link
|
||||
xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
|
||||
>OpenStack Hypervisor Support Matrix</link>.</para>
|
||||
<para>The security of Nova is critical for an OpenStack deployment. Hardening techniques should include support for strong instance isolation, secure communication between Nova sub-components, and resiliency of public-facing <glossterm>API</glossterm> endpoints.</para>
|
||||
<para>The security of Compute is critical for an OpenStack deployment. Hardening techniques should include support for strong instance isolation, secure communication between Compute sub-components, and resiliency of public-facing <glossterm>API</glossterm> endpoints.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp138800">
|
||||
<title>OpenStack Object Storage</title>
|
||||
<para>OpenStack object storage service (Swift) provides support for storing and retrieving arbitrary data in the cloud. Swift provides both a native API and an Amazon Web Services S3 compatible API. The service provides a high degree of resiliency through data replication and can handle petabytes of data.</para>
|
||||
<title>Object Storage</title>
|
||||
<para>The OpenStack Object Storage Service (Swift) provides support for storing and retrieving arbitrary data in the cloud. The Object Storage Service provides both a native API and an Amazon Web Services S3 compatible API. The service provides a high degree of resiliency through data replication and can handle petabytes of data.</para>
|
||||
<para>It is important to understand that object storage differs from traditional file system storage. It is best used for static data such as media files (MP3s, images, videos), virtual machine images, and backup files.</para>
|
||||
<para>Object security should focus on access control and encryption of data in transit and at rest. Other concerns may relate to system abuse, illegal or malicious content storage, and cross authentication attack vectors.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp141536">
|
||||
<title>OpenStack Block Storage</title>
|
||||
<title>Block Storage</title>
|
||||
<para>The OpenStack Block Storage service (Cinder) provides
|
||||
persistent block storage for compute instances. Cinder is
|
||||
responsible for managing the life-cycle of block devices, from
|
||||
the creation and attachment of volumes to instances, to their
|
||||
persistent block storage for compute instances. The Block Storage
|
||||
Service is responsible for managing the life-cycle of block devices,
|
||||
from the creation and attachment of volumes to instances, to their
|
||||
release.</para>
|
||||
<para>Security considerations for block storage are similar to that of object storage.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp143424">
|
||||
<title>OpenStack Networking</title>
|
||||
<para>The OpenStack networking service (Neutron, previously called Quantum) provides various networking services to cloud users (tenants) such as IP address management, <glossterm>DNS</glossterm>, <glossterm>DHCP</glossterm>, load balancing, and security groups (network access rules, like firewall policies). It provides a framework for software defined networking (SDN) that allows for pluggable integration with various networking solutions.</para>
|
||||
<para>The OpenStack Networking Service (Neutron, previously called Quantum) provides various networking services to cloud users (tenants) such as IP address management, <glossterm>DNS</glossterm>, <glossterm>DHCP</glossterm>, load balancing, and security groups (network access rules, like firewall policies). It provides a framework for software defined networking (SDN) that allows for pluggable integration with various networking solutions.</para>
|
||||
<para>OpenStack Networking allows cloud tenants to manage their guest network configurations. Security concerns with the networking service include network traffic isolation, availability, integrity and confidentiality.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp145600">
|
||||
<title>OpenStack Dashboard</title>
|
||||
<para>The OpenStack dashboard service (Horizon) provides a web-based interface for both cloud administrators and cloud tenants. Through this interface administrators and tenants can provision, manage, and monitor cloud resources. Horizon is commonly deployed in a public facing manner with all the usual security concerns of public web portals.</para>
|
||||
<title>Dashboard</title>
|
||||
<para>The OpenStack Dashboard Service (Horizon) provides a web-based interface for both cloud administrators and cloud tenants. Through this interface administrators and tenants can provision, manage, and monitor cloud resources. Horizon is commonly deployed in a public facing manner with all the usual security concerns of public web portals.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp147104">
|
||||
<title>Identity management</title>
|
||||
<para>The identity management service (Keystone) is a <emphasis role="bold">shared service</emphasis> that provides authentication and authorization services throughout the entire cloud infrastructure. Keystone has pluggable support for multiple forms of authentication.</para>
|
||||
<title>Identity Service</title>
|
||||
<para>The OpenStack Identity Service (Keystone) is a <emphasis role="bold">shared service</emphasis> that provides authentication and authorization services throughout the entire cloud infrastructure. The Identity Service has pluggable support for multiple forms of authentication.</para>
|
||||
<para>Security concerns here pertain to trust in authentication, management of authorization tokens, and secure communication.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp149712">
|
||||
<title>Image Service</title>
|
||||
<para>The OpenStack image service (Glance) provides disk image management services. Glance provides image discovery, registration, and delivery services to Nova, the compute service, as needed.</para>
|
||||
<para>The OpenStack Image Service (Glance) provides disk image management services. The Image Service provides image discovery, registration, and delivery services to Compute, the compute service, as needed.</para>
|
||||
<para>Trusted processes for managing the life cycle of disk images are required, as are all the previously mentioned issues with respect to data security.</para>
|
||||
</section>
|
||||
<section xml:id="ch004_book-introduction-idp152400">
|
||||
|
||||
@ -83,7 +83,7 @@
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<para>The above table illustrates a generic approach to measuring the impact of a vulnerability based on where it occurs in your deployment and the effect; for example, a single level privilege escalation on a Nova API node would potentially allow a standard user of the API to escalate to have the same privileges as the root user on the node.</para>
|
||||
<para>The above table illustrates a generic approach to measuring the impact of a vulnerability based on where it occurs in your deployment and the effect; for example, a single level privilege escalation on a Compute API node would potentially allow a standard user of the API to escalate to have the same privileges as the root user on the node.</para>
|
||||
<para>We suggest cloud administrators customize and expand this table to suit their needs. Then work to define how to handle the various severity levels. For example, a critical-level security update might require the cloud to be upgraded on a specified time line, whereas a low-level update might be more relaxed.</para>
|
||||
</section>
|
||||
<section xml:id="ch012_configuration-management-idp100864">
|
||||
|
||||
@ -20,8 +20,8 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp49280">
|
||||
<title>OpenStack Dashboard (Horizon)</title>
|
||||
<para>The OpenStack Dashboard (Horizon) provides administrators and tenants a web-based graphical interface to provision and access cloud-based resources. Horizon communicates with the back-end services via calls to the OpenStack API (discussed above).</para>
|
||||
<title>Dashboard</title>
|
||||
<para>The OpenStack Dashboard (Horizon) provides administrators and tenants a web-based graphical interface to provision and access cloud-based resources. The dashboard communicates with the back-end services via calls to the OpenStack API (discussed above).</para>
|
||||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp50608">
|
||||
<title>Capabilities</title>
|
||||
<itemizedlist><listitem>
|
||||
@ -31,7 +31,7 @@
|
||||
<para>The dashboard provides tenant-users a self-service portal to provision their own resources within the limits set by administrators.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The dashboard provides GUI support for routers and load-balancers. For example, Horizon now implements all of the main Neutron features.</para>
|
||||
<para>The dashboard provides GUI support for routers and load-balancers. For example, the dashboard now implements all of the main Networking features.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>It is an extensible <glossterm>Django</glossterm> web application that allows easy plug-in of third-party products and services, such as billing, monitoring, and additional management tools.</para>
|
||||
@ -44,10 +44,10 @@
|
||||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp56400">
|
||||
<title>Security Considerations</title>
|
||||
<itemizedlist><listitem>
|
||||
<para>Horizon requires cookies and JavaScript to be enabled in the web browser.</para>
|
||||
<para>The dashboard requires cookies and JavaScript to be enabled in the web browser.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The web server that hosts Horizon should be configured for SSL to ensure data is encrypted.</para>
|
||||
<para>The web server that hosts dashboard should be configured for SSL to ensure data is encrypted.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Both the Horizon web service and the OpenStack API it uses to communicate with the back-end are susceptible to web attack vectors such as denial of service and must be monitored.</para>
|
||||
@ -101,7 +101,7 @@
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="ch014_best-practices-for-operator-mode-access-idp76272">
|
||||
<title>OpenStack Management Utilities</title>
|
||||
<title>Management Utilities</title>
|
||||
<para>The OpenStack Management Utilities are open-source Python
|
||||
command-line clients that make API calls. There is a client for
|
||||
each OpenStack service (nova, glance, etc.). In addition to the
|
||||
|
||||
@ -7,8 +7,8 @@
|
||||
<para>OpenStack provides both public facing and private API endpoints. By default, OpenStack components use the publicly defined endpoints. The recommendation is to configure these components to use the API endpoint within the proper security domain.</para>
|
||||
<para>Services select their respective API endpoints based on the OpenStack service catalog. The issue here is these services may not obey the listed public or internal API end point values. This can lead to internal management traffic being routed to external API endpoints.</para>
|
||||
<section xml:id="ch021_paste-and-middleware-idp40496">
|
||||
<title>Configure Internal URLs in Keystone Catalog</title>
|
||||
<para>The keystone catalog should be aware of your internal URLs. While this feature is not utilized by default, it may be leveraged through configuration. Additionally, it should be forward-compatible with expectant changes once this behavior becomes the default.</para>
|
||||
<title>Configure Internal URLs in Identity Service Catalog</title>
|
||||
<para>The Identity Service catalog should be aware of your internal URLs. While this feature is not utilized by default, it may be leveraged through configuration. Additionally, it should be forward-compatible with expectant changes once this behavior becomes the default.</para>
|
||||
<para>To register an internal URL for an endpoint:</para>
|
||||
<screen>
|
||||
$ keystone endpoint-create \
|
||||
@ -21,7 +21,7 @@ $ keystone endpoint-create \
|
||||
<section xml:id="ch021_paste-and-middleware-idp43360">
|
||||
<title>Configure Applications for Internal URLs</title>
|
||||
<para>Some services can be forced to use specific API endpoints. Therefore, it is recommended that each OpenStack service communicating to the API of another service must be explicitly configured to access the proper internal API endpoint.</para>
|
||||
<para>Each project may present an inconsistent way of defining target API endpoints. Future releases of OpenStack seek to resolve these inconsistencies through consistent use of the Keystone catalog.</para>
|
||||
<para>Each project may present an inconsistent way of defining target API endpoints. Future releases of OpenStack seek to resolve these inconsistencies through consistent use of the Identity Service catalog.</para>
|
||||
<section xml:id="ch021_paste-and-middleware-idp45520">
|
||||
<title>Configuration Example #1: Nova</title>
|
||||
<screen>
|
||||
|
||||
@ -1,20 +1,20 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch024_authentication"><?dbhtml stop-chunking?>
|
||||
<title>Identity</title>
|
||||
<para>The OpenStack Identity Service (Keystone) supports multiple methods of authentication, including username & password, LDAP, and external authentication methods. Upon successful authentication, Keystone provides the user with an authorization token used for subsequent service requests.</para>
|
||||
<para>The OpenStack Identity Service (Keystone) supports multiple methods of authentication, including username & 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>
|
||||
<para>Transport Layer Security TLS/SSL provides authentication between services and persons using X.509 certificates. Although the default mode for SSL is server-side only authentication, certificates may also be used for client authentication.</para>
|
||||
<section xml:id="ch024_authentication-idp195568">
|
||||
<title>Authentication</title>
|
||||
<section xml:id="ch024_authentication-idp196256">
|
||||
<title>Invalid Login Attempts</title>
|
||||
<para>Keystone does not provide a method to limit access to accounts after repeated unsuccessful login attempts. Repeated failed login attempts are likely brute-force attacks (Refer figure Attack-types). This is a more significant issue in Public clouds.</para>
|
||||
<para>The Identity Service does not provide a method to limit access to accounts after repeated unsuccessful login attempts. Repeated failed login attempts are likely brute-force attacks (Refer figure Attack-types). This is a more significant issue in Public clouds.</para>
|
||||
<para>Prevention is possible by using an external authentication system that blocks out an account after some configured number of failed login attempts. The account then may only be unlocked with further side-channel intervention.</para>
|
||||
<para>If prevention is not an option, detection can be used to mitigate damage.Detection involves frequent review of access control logs to identify unauthorized attempts to access accounts. Possible remediation would include reviewing the strength of the user password, or blocking the network source of the attack via firewall rules. Firewall rules on the keystone server that restrict the number of connections could be used to reduce the attack effectiveness, and thus dissuade the attacker.</para>
|
||||
<para>In addition, it is useful to examine account activity for unusual login times and suspicious actions, with possibly disable the account. Often times this approach is taken by credit card providers for fraud detection and alert.</para>
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp241008">
|
||||
<title>Multi-factor Authentication</title>
|
||||
<para>Employ multi-factor authentication for network access to privileged user accounts. Keystone supports external authentication services through the Apache web server that can provide this functionality. Servers may also enforce client-side authentication using certificates.</para>
|
||||
<para>Employ multi-factor authentication for network access to privileged user accounts. The Identity Service supports external authentication services through the Apache web server that can provide this functionality. Servers may also enforce client-side authentication using certificates.</para>
|
||||
<para>This recommendation provides insulation from brute force, social engineering, and both spear and mass phishing attacks that may compromise administrator passwords.</para>
|
||||
</section>
|
||||
</section>
|
||||
@ -22,12 +22,12 @@
|
||||
<title>Authentication Methods</title>
|
||||
<section xml:id="ch024_authentication-idp243824">
|
||||
<title>Internally Implemented Authentication Methods</title>
|
||||
<para>Keystone can store user credentials in an SQL Database, or may use an LDAP-compliant directory server. The Keystone database may be separate from databases used by other OpenStack services to reduce the risk of a compromise of the stored credentials.</para>
|
||||
<para>When authentication is provided via username and password, Keystone does not enforce policies on password strength, expiration, or failed authentication attempts as recommended by NIST Special Publication 800-118 (draft). Organizations that desire to enforce stronger password policies should consider using Keystone Identity Service Extensions or external authentication services.</para>
|
||||
<para>LDAP simplifies integration of Keystone authentication into an organization's existing directory service and user account management processes.</para>
|
||||
<para>Authentication and authorization policy in OpenStack may be delegated to an external LDAP server. A typical use case is an organization that seeks to deploy a private cloud and already has a database of employees, the users. This may be in an LDAP system. Using LDAP as a source of authority authentication, requests to Keystone are delegated to the LDAP service, which will authorize or deny requests based on locally set policies. A token is generated on successful authentication.</para>
|
||||
<para>Note that if the LDAP system has attributes defined for the user such as admin, finance, HR etc, these must be mapped into roles and groups within Keystone for use by the various OpenStack services. The <emphasis>etc/keystone.conf</emphasis> file provides the mapping from the LDAP attributes to Keystone attributes.</para>
|
||||
<para>Keystone <emphasis role="bold">MUST NOT</emphasis> be allowed to write to LDAP services used for authentication outside of the OpenStack deployment as this would allow a sufficiently privileged keystone user to make changes to the LDAP directory. This would allow privilege escalation within the wider organization or facilitate unauthorized access to other information and resources. In such a deployment, user provisioning would be out of the realm of the OpenStack deployment.</para>
|
||||
<para>The Identity Service can store user credentials in an SQL Database, or may use an LDAP-compliant directory server. The Identity database may be separate from databases used by other OpenStack services to reduce the risk of a compromise of the stored credentials.</para>
|
||||
<para>When authentication is provided via username and password, the Identity Service does not enforce policies on password strength, expiration, or failed authentication attempts as recommended by NIST Special Publication 800-118 (draft). Organizations that desire to enforce stronger password policies should consider using Keystone Identity Service Extensions or external authentication services.</para>
|
||||
<para>LDAP simplifies integration of Identity authentication into an organization's existing directory service and user account management processes.</para>
|
||||
<para>Authentication and authorization policy in OpenStack may be delegated to an external LDAP server. A typical use case is an organization that seeks to deploy a private cloud and already has a database of employees, the users. This may be in an LDAP system. Using LDAP as a source of authority authentication, requests to Identity Service are delegated to the LDAP service, which will authorize or deny requests based on locally set policies. A token is generated on successful authentication.</para>
|
||||
<para>Note that if the LDAP system has attributes defined for the user such as admin, finance, HR etc, these must be mapped into roles and groups within Identity for use by the various OpenStack services. The <emphasis>etc/keystone.conf</emphasis> file provides the mapping from the LDAP attributes to Identity attributes.</para>
|
||||
<para>The Identity Service <emphasis role="bold">MUST NOT</emphasis> be allowed to write to LDAP services used for authentication outside of the OpenStack deployment as this would allow a sufficiently privileged keystone user to make changes to the LDAP directory. This would allow privilege escalation within the wider organization or facilitate unauthorized access to other information and resources. In such a deployment, user provisioning would be out of the realm of the OpenStack deployment.</para>
|
||||
<note>
|
||||
<para>There is an <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1168252">OpenStack Security Note (OSSN) regarding keystone.conf permissions</link>.</para>
|
||||
<para>There is an <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1168252">OpenStack Security Note (OSSN) regarding potential DoS attacks</link>.</para>
|
||||
@ -51,7 +51,7 @@
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp256832">
|
||||
<title>Authorization</title>
|
||||
<para>Keystone supports the notion of groups and roles. Users belong to groups. A group has a list of roles. OpenStack services reference the roles of the user attempting to access the service. The OpenStack policy enforcer middleware takes into consideration the policy rule associated with each resource and the user's group/roles and tenant association to determine if he/she has access to the requested resource.</para>
|
||||
<para>The Identity Service supports the notion of groups and roles. Users belong to groups. A group has a list of roles. OpenStack services reference the roles of the user attempting to access the service. The OpenStack policy enforcer middleware takes into consideration the policy rule associated with each resource and the user's group/roles and tenant association to determine if he/she has access to the requested resource.</para>
|
||||
<para>The Policy enforcement middleware enables fine-grained access control to OpenStack resources. Only admin users can provision new users and have access to various management functionality. The cloud tenant would be able to only spin up instances, attach volumes, etc.</para>
|
||||
<section xml:id="ch024_authentication-idp259168">
|
||||
<title>Establish Formal Access Control Policies</title>
|
||||
@ -60,25 +60,25 @@
|
||||
<section xml:id="ch024_authentication-idp261600">
|
||||
<title>Service Authorization</title>
|
||||
<para>As described in the <link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/index.html"><citetitle>OpenStack Cloud Administrator Guide</citetitle></link>, cloud administrators must define a user for each service, with a role of Admin. This service user account provides the service with the authorization to authenticate users.</para>
|
||||
<para>The Nova and Swift services can be configured to use either the "tempAuth" file or Keystone to store authentication information. The "tempAuth" solution MUST NOT be deployed in a production environment since it stores passwords in plain text.</para>
|
||||
<para>Keystone 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 identification. It reduces the risk of unauthorized access when usernames and passwords may be compromised. However, there is additional administrative overhead and cost to issue certificates to users that may not be feasible in every deployment.</para>
|
||||
<para>NOTE: We recommend using client authentication using SSL for the authentication of services to Keystone.</para>
|
||||
<para>The Compute and Object Storage services can be configured to use either the "tempAuth" file or Identity Service to store authentication information. The "tempAuth" solution MUST NOT be deployed in a production environment since it stores passwords in plain text.</para>
|
||||
<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 identification. It reduces the risk of unauthorized access when usernames and passwords may be compromised. However, there is additional administrative overhead and cost to issue certificates to users that may not be feasible in every deployment.</para>
|
||||
<para>NOTE: We recommend using client authentication using SSL for the authentication of services to Identity.</para>
|
||||
<para>The cloud administrator should protect sensitive configuration files for unauthorized modification. This can be achieved with mandatory access control frameworks such as SELinux, including <literal>/etc/keystone.conf</literal> and X.509 certificates.</para>
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp267040">
|
||||
<title>Administrative Users</title>
|
||||
<para>We recommend that admin users authenticate using Keystone and an external authentication service that supports 2-factor authentication, such as a certificate. This reduces the risk from passwords that may be compromised. This recommendation is in compliance with NIST 800-53 IA-2(1) guidance in the use of multifactor authentication for network access to privileged accounts.</para>
|
||||
<para>We recommend that admin users authenticate using Identity Service and an external authentication service that supports 2-factor authentication, such as a certificate. This reduces the risk from passwords that may be compromised. This recommendation is in compliance with NIST 800-53 IA-2(1) guidance in the use of multifactor authentication for network access to privileged accounts.</para>
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp268960">
|
||||
<title>End Users</title>
|
||||
<para>Keystone can directly provide end-user authentication, or can be configured to use external authentication methods to conform to an organization's security policies and requirements.</para>
|
||||
<para>The Identity Service can directly provide end-user authentication, or can be configured to use external authentication methods to conform to an organization's security policies and requirements.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp270544">
|
||||
<title>Policies</title>
|
||||
<para>Each OpenStack service has a policy file in json format, called <emphasis role="bold">policy.json</emphasis>. The policy file specifies rules, and the rule that governs each resource. A resource could be API access, the ability to attach to a volume, or to fire up instances.</para>
|
||||
<para>The policies can be updated by the cloud administrator to further control access to the various resources. The middleware could also be further customized. Note that your users must be assigned to groups/roles that you refer to in your policies.</para>
|
||||
<para>Below is a snippet of the Cinder service policy.json file.</para>
|
||||
<para>Below is a snippet of the Block Storage service policy.json file.</para>
|
||||
<screen>
|
||||
{
|
||||
"context_is_admin": [["role:admin"]],
|
||||
@ -101,7 +101,7 @@
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp276176">
|
||||
<title>Tokens</title>
|
||||
<para>Once a user is authenticated, a token is generated and used internally in OpenStack for authorization and access. The default token <emphasis role="bold">lifespan</emphasis> is<emphasis role="bold"> 24 hours</emphasis>. It is recommended that this value be set lower but caution needs to be taken as some internal services will need sufficient time to complete their work. The cloud may not provide services if tokens expire too early. An example of this would be the time needed by Nova to transfer a disk image onto the hypervisor for local caching.</para>
|
||||
<para>Once a user is authenticated, a token is generated and used internally in OpenStack for authorization and access. The default token <emphasis role="bold">lifespan</emphasis> is<emphasis role="bold"> 24 hours</emphasis>. It is recommended that this value be set lower but caution needs to be taken as some internal services will need sufficient time to complete their work. The cloud may not provide services if tokens expire too early. An example of this would be the time needed by the Compute Service to transfer a disk image onto the hypervisor for local caching.</para>
|
||||
<para>The Identity service could alternatively be configured to provide UUID tokens which are significantly shorter but may be less secure depending on your specific deployment model. Decisions about token implementation should take into consideration the level of trust needed within a given security domain.</para>
|
||||
<para>Below is an example of a PKI token. Note that, in practice, the token id value is very long (e.g., around 3500 bytes), but for brevity we shorten it in this example.</para>
|
||||
<screen>
|
||||
@ -116,8 +116,8 @@
|
||||
"name": "demo"
|
||||
}
|
||||
}</screen>
|
||||
<para>Note that the token is often passed within the structure of a larger context of a Keystone response. These responses also provide a catalog of the various OpenStack services. Each service is listed with its name, access endpoints for internal, admin, and public access.</para>
|
||||
<para>Keystone supports token revocation. This manifests as an API to revoke a token, to list revoked tokens and individual OpenStack services that cache tokens to query for the revoked tokens and remove them from their cache and append the same to their list of cached revoked tokens.</para>
|
||||
<para>Note that the token is often passed within the structure of a larger context of a Identity Service response. These responses also provide a catalog of the various OpenStack services. Each service is listed with its name, access endpoints for internal, admin, and public access.</para>
|
||||
<para>The Identity Service supports token revocation. This manifests as an API to revoke a token, to list revoked tokens and individual OpenStack services that cache tokens to query for the revoked tokens and remove them from their cache and append the same to their list of cached revoked tokens.</para>
|
||||
</section>
|
||||
<section xml:id="ch024_authentication-idp287584">
|
||||
<title>Future</title>
|
||||
|
||||
@ -2,18 +2,18 @@
|
||||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch025_web-dashboard"><?dbhtml stop-chunking?>
|
||||
<title>Dashboard</title>
|
||||
<para>Horizon is the OpenStack dashboard, providing access to a majority of the capabilities available in OpenStack. These include provisioning users, defining instance flavors, uploading VM images, managing networks, setting up security groups, starting instances, and accessing the instances via a console.</para>
|
||||
<para>Horizon is based on the Django web framework, therefore secure deployment practices for Django apply directly to Horizon. This guide provides a popular set of Django security recommendations, further information can be found by reading the <link xlink:href="https://docs.djangoproject.com/en/1.5/#security">Django deployment and security documentation</link>.</para>
|
||||
<para>Horizon ships with reasonable default security settings, and has good <link xlink:href="http://docs.openstack.org/developer/horizon/topics/deployment.html">deployment and configuration documentation</link>.</para>
|
||||
<para>The dashboard is based on the Django web framework, therefore secure deployment practices for Django apply directly to Horizon. This guide provides a popular set of Django security recommendations, further information can be found by reading the <link xlink:href="https://docs.djangoproject.com/en/1.5/#security">Django deployment and security documentation</link>.</para>
|
||||
<para>The dashboard ships with reasonable default security settings, and has good <link xlink:href="http://docs.openstack.org/developer/horizon/topics/deployment.html">deployment and configuration documentation</link>.</para>
|
||||
<section xml:id="ch025_web-dashboard-idp237648">
|
||||
<title>Basic Web Server Configuration</title>
|
||||
<para>Horizon should be deployed as a Web Services Gateway Interface (WSGI) application behind an HTTPS proxy such as Apache or nginx. If Apache is not already in use, we recommend nginx since it is lighter weight and easier to configure correctly.</para>
|
||||
<para>The dashboard should be deployed as a Web Services Gateway Interface (WSGI) application behind an HTTPS proxy such as Apache or nginx. If Apache is not already in use, we recommend nginx since it is lighter weight and easier to configure correctly.</para>
|
||||
<para>When using nginx, we recommend <link xlink:href="http://docs.gunicorn.org/en/latest/deploy.html">gunicorn</link> as the wsgi host with an appropriate number of synchronous workers. We strongly advise against deployments using fastcgi, scgi, or uWSGI. We strongly advise against the use of synthetic performance benchmarks when choosing a wsgi server.</para>
|
||||
<para>When using Apache, we recommend <link xlink:href="https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/">mod_wsgi</link> to host Horizon.</para>
|
||||
<para>When using Apache, we recommend <link xlink:href="https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/">mod_wsgi</link> to host dashboard.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp240704">
|
||||
<title>HTTPS</title>
|
||||
<para>Horizon should be deployed behind a secure HTTPS server using a valid, trusted certificate from a recognized certificate authority (CA). Private organization-issued certificates are only appropriate when the root of trust is pre-installed in all user browsers.</para>
|
||||
<para>HTTP requests to the Horizon domain should be configured to redirect to the fully qualified HTTPS URL.</para>
|
||||
<para>The dashboard should be deployed behind a secure HTTPS server using a valid, trusted certificate from a recognized certificate authority (CA). Private organization-issued certificates are only appropriate when the root of trust is pre-installed in all user browsers.</para>
|
||||
<para>HTTP requests to the dashboard domain should be configured to redirect to the fully qualified HTTPS URL.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp242624">
|
||||
<title>HTTP Strict Transport Security (HSTS)</title>
|
||||
@ -23,24 +23,24 @@
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp245456">
|
||||
<title>Frontend Caching</title>
|
||||
<para>Since Horizon is rendering dynamic content passed directly from OpenStack API requests, we do not recommend frontend caching layers such as varnish. In Django, static media is directly served from Apache or nginx and already benefits from web host caching.</para>
|
||||
<para>Since dashboard is rendering dynamic content passed directly from OpenStack API requests, we do not recommend frontend caching layers such as varnish. In Django, static media is directly served from Apache or nginx and already benefits from web host caching.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp246880">
|
||||
<title>Domain Names</title>
|
||||
<para>Many organizations typically deploy web applications at subdomains of an overarching organization domain. It is natural for users to expect a domain of the form openstack.example.org. In this context, there are often many other applications deployed in the same second-level namespace, often serving user-controlled content. This name structure is convenient and simplifies nameserver maintenance.</para>
|
||||
<para>We strongly recommend deploying horizon to a <emphasis>second-level domain</emphasis>, for example <uri>https://example.com</uri>, and advise against deploying horizon on a<emphasis> shared subdomain</emphasis> of any level, for example <uri>https://openstack.example.org</uri> or <uri>https://horizon.openstack.example.org</uri>. We also advise against deploying to bare internal domains like <uri>https://horizon/</uri>.</para>
|
||||
<para>This recommendation is based on the limitations browser same-origin-policy. The recommendations in this guide cannot effectively protect users against known attacks if Horizon is deployed on a domain which also hosts user-generated content (e.g. scripts, images, uploads of any kind) even if the user-generated content is on a different subdomain. This approach is used by most major web presences (e.g. googleusercontent.com, fbcdn.com, github.io, twimg.com) to ensure that user generated content stays separate from cookies and security tokens.</para>
|
||||
<para>Additionally, if you decline to follow this recommendation above about second-level domains, it is vital that you avoid the cookie backed session store and employ HTTP Strict Transport Security (HSTS). When deployed on a subdomain, Horizon's security is only as strong as the weakest application deployed on the same second-level domain.</para>
|
||||
<para>This recommendation is based on the limitations browser same-origin-policy. The recommendations in this guide cannot effectively protect users against known attacks if dashboard is deployed on a domain which also hosts user-generated content (e.g. scripts, images, uploads of any kind) even if the user-generated content is on a different subdomain. This approach is used by most major web presences (e.g. googleusercontent.com, fbcdn.com, github.io, twimg.com) to ensure that user generated content stays separate from cookies and security tokens.</para>
|
||||
<para>Additionally, if you decline to follow this recommendation above about second-level domains, it is vital that you avoid the cookie backed session store and employ HTTP Strict Transport Security (HSTS). When deployed on a subdomain, dashboard's security is only as strong as the weakest application deployed on the same second-level domain.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp251760">
|
||||
<title>Static Media</title>
|
||||
<para>Horizon's static media should be deployed to a subdomain of the Horizon domain and served by the web server. The use of an external content delivery network (CDN) is also acceptable. This subdomain should not set cookies or serve user-provided content. The media should also be served with HTTPS.</para>
|
||||
<para>Dashboard's static media should be deployed to a subdomain of the dashboard domain and served by the web server. The use of an external content delivery network (CDN) is also acceptable. This subdomain should not set cookies or serve user-provided content. The media should also be served with HTTPS.</para>
|
||||
<para>Django media settings are documented at <link xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#static-root">https://docs.djangoproject.com/en/1.5/ref/settings/#static-root</link>.</para>
|
||||
<para>Horizon's default configuration uses <link xlink:href="http://django-compressor.readthedocs.org/">django_compressor</link> to compress and minify css and JavaScript content before serving it. This process should be statically done before deploying Horizon, rather than using the default in-request dynamic compression and copying the resulting files along with deployed code or to the CDN server. Compression should be done in a non-production build environment. If this is not practical, we recommend disabling resource minification entirely. Online compression dependencies (less, nodejs) should not be installed on production machines.</para>
|
||||
<para>Dashboard's default configuration uses <link xlink:href="http://django-compressor.readthedocs.org/">django_compressor</link> to compress and minify css and JavaScript content before serving it. This process should be statically done before deploying dashboard, rather than using the default in-request dynamic compression and copying the resulting files along with deployed code or to the CDN server. Compression should be done in a non-production build environment. If this is not practical, we recommend disabling resource minification entirely. Online compression dependencies (less, nodejs) should not be installed on production machines.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp255696">
|
||||
<title>Secret Key</title>
|
||||
<para>Horizon depends on a shared SECRET_KEY setting for some security functions. It should be a randomly generated string at least 64 characters long. It must be shared across all active Horizon instances. Compromise of this key may allow a remote attacker to execute arbitrary code. Rotating this key invalidates existing user sessions and caching. Do not commit this key to public repositories.</para>
|
||||
<para>Dashboard depends on a shared SECRET_KEY setting for some security functions. It should be a randomly generated string at least 64 characters long. It must be shared across all active Horizon instances. Compromise of this key may allow a remote attacker to execute arbitrary code. Rotating this key invalidates existing user sessions and caching. Do not commit this key to public repositories.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp257248">
|
||||
<title>Session Backend</title>
|
||||
@ -70,12 +70,12 @@ SESSION_COOKIE_SECURE = True</screen>
|
||||
<section xml:id="ch025_web-dashboard-idp268448">
|
||||
<title>Cross Site Request Forgery (CSRF)</title>
|
||||
<para>Django has a dedicated middleware for <link xlink:href="https://docs.djangoproject.com/en/1.5/ref/contrib/csrf/#how-it-works">cross-site request forgery</link> (CSRF).</para>
|
||||
<para>Horizon is designed to discourage developers from introducing cross-site scripting vulnerabilities with custom dashboards. However, it is important to audit custom dashboards, especially ones that are javascript-heavy for inappropriate use of the @csrf_exempt decorator. Dashboards which do not follow these recommended security settings should be carefully evaluated before restrictions are relaxed.</para>
|
||||
<para>Dashboard is designed to discourage developers from introducing cross-site scripting vulnerabilities with custom dashboards. However, it is important to audit custom dashboards, especially ones that are javascript-heavy for inappropriate use of the @csrf_exempt decorator. Dashboards which do not follow these recommended security settings should be carefully evaluated before restrictions are relaxed.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp270608">
|
||||
<title>Cross Site Scripting (XSS)</title>
|
||||
<para>Unlike many similar systems, OpenStack Horizon allows the entire unicode character set in most fields. This means developers have less latitude to make escaping mistakes that open attack vectors for cross-site scripting (XSS).</para>
|
||||
<para>Horizon provides tools for developers to avoid creating XSS vulnerabilities, but they only work if developers use them correctly. Audit any custom dashboards, paying particular attention to use of the mark_safe function, use of is_safe with custom template tags, the safe template tag, anywhere autoescape is turned off, and any javascript which might evaluate improperly escaped data.</para>
|
||||
<para>Unlike many similar systems, OpenStack dashboard allows the entire unicode character set in most fields. This means developers have less latitude to make escaping mistakes that open attack vectors for cross-site scripting (XSS).</para>
|
||||
<para>Dashboard provides tools for developers to avoid creating XSS vulnerabilities, but they only work if developers use them correctly. Audit any custom dashboards, paying particular attention to use of the mark_safe function, use of is_safe with custom template tags, the safe template tag, anywhere autoescape is turned off, and any javascript which might evaluate improperly escaped data.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp272832">
|
||||
<title>Cross Origin Resource Sharing (CORS)</title>
|
||||
@ -90,7 +90,7 @@ Access-Control-Allow-Origin: https://example.com/</screen>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp276864">
|
||||
<title>Upgrading</title>
|
||||
<para>Django security releases are generally well tested and aggressively backwards compatible. In almost all cases, new major releases of Django are also fully backwards compatible with previous releases. Horizon implementers are strongly encouraged to run the latest stable release of Django with up-to-date security releases.</para>
|
||||
<para>Django security releases are generally well tested and aggressively backwards compatible. In almost all cases, new major releases of Django are also fully backwards compatible with previous releases. Dashboard implementers are strongly encouraged to run the latest stable release of Django with up-to-date security releases.</para>
|
||||
</section>
|
||||
<section xml:id="ch025_web-dashboard-idp278672">
|
||||
<title>Debug</title>
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch026_compute"><?dbhtml stop-chunking?>
|
||||
<title>Compute</title>
|
||||
<para>The compute service (Nova) is one of the more complex OpenStack services. It runs in many locations throughout the cloud and interacts with a variety of internal services. For this reason, most of our recommendations regarding best practices for Nova configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database.</para>
|
||||
<para>The Compute Service (Nova) is one of the more complex OpenStack services. It runs in many locations throughout the cloud and interacts with a variety of internal services. For this reason, most of our recommendations regarding best practices for Compute Service configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database.</para>
|
||||
<section xml:id="ch026_compute-idp45072">
|
||||
<title>Virtual Console Selection</title>
|
||||
<para>One decision a cloud architect will need to make regarding Nova configuration is whether to use VNC or SPICE. Below we provide some details on the differences between these options.</para>
|
||||
<para>One decision a cloud architect will need to make regarding Compute Service configuration is whether to use VNC or SPICE. Below we provide some details on the differences between these options.</para>
|
||||
<section xml:id="ch026_compute-idp46336">
|
||||
<title>Virtual Network Computer (VNC)</title>
|
||||
<para>OpenStack can be configured to provide remote desktop console access to instances for tenants and/or administrators using the Virtual Network Computer (VNC) protocol. </para>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<para><emphasis role="bold">neutron server</emphasis> (<literal>neutron-server</literal> and <literal>neutron-*-plugin</literal>): This service runs on the network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port. The neutron-server and plugin agents require access to a database for persistent storage and access to a message queue for inter-communication.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">plugin agent</emphasis> (<literal>neutron-*-agent</literal>): Runs on each Nova compute node to manage local virtual switch (vswitch) configuration. The agents to be run will depend on which plugin you are using. This service requires message queue access. <emphasis>Optional depending on plugin.</emphasis></para>
|
||||
<para><emphasis role="bold">plugin agent</emphasis> (<literal>neutron-*-agent</literal>): Runs on each compute node to manage local virtual switch (vswitch) configuration. The agents to be run will depend on which plugin you are using. This service requires message queue access. <emphasis>Optional depending on plugin.</emphasis></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">DHCP agent</emphasis> (<literal>neutron-dhcp-agent</literal>): Provides DHCP services to tenant networks. This agent is the same across all plugins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access.</para>
|
||||
|
||||
@ -95,7 +95,7 @@ charset=utf8&ssl_ca=/etc/mysql/cacert.pem&ssl_cert=/etc/mysql/server-cer
|
||||
<section xml:id="ch042_database-overview-idp100688">
|
||||
<title>Nova Conductor</title>
|
||||
<para>OpenStack Compute offers a sub-service called <systemitem class="service">nova-conductor</systemitem> which proxies database connections, with the primary purpose of having the nova compute nodes interfacing with <systemitem class="service">nova-conductor</systemitem> to meet data persistence needs as opposed to directly communicating with the database.</para>
|
||||
<para>Nova-conductor receives requests over RPC and performs actions on behalf of the calling service without granting granular access to the database, its tables, or data within. Nova-conductor essentially abstracts direct database access away from Nova compute nodes.</para>
|
||||
<para>Nova-conductor receives requests over RPC and performs actions on behalf of the calling service without granting granular access to the database, its tables, or data within. Nova-conductor essentially abstracts direct database access away from compute nodes.</para>
|
||||
<para>This abstraction offers the advantage of restricting services to executing methods with parameters, similar to stored procedures, preventing a large number of systems from directly accessing or modifying database data. This is accomplished without having these procedures stored or executed within the context or scope of the database itself, a frequent criticism of typical stored procedures.</para>
|
||||
<para><inlinemediaobject><imageobject role="html">
|
||||
<imagedata contentdepth="304" contentwidth="593" fileref="static/novaconductor.png" format="PNG" scalefit="1"/>
|
||||
|
||||
@ -89,7 +89,7 @@
|
||||
<para>Instance memory scrubbing</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Cinder volume data</para>
|
||||
<para>Block Storage volume data</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Compute instance ephemeral storage</para>
|
||||
|
||||
@ -7,26 +7,26 @@
|
||||
<para>Often, data encryption relates positively to the ability to reliably destroy tenant and per-instance data, simply by throwing away the keys. It should be noted that in doing so, it becomes of great importance to destroy those keys in a reliable and secure manner.</para>
|
||||
<para>Opportunities to encrypt data for users are present:</para>
|
||||
<itemizedlist><listitem>
|
||||
<para>Swift objects</para>
|
||||
<para>Object Storage objects</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Cinder volumes & Instance Ephemeral Filesystems</para>
|
||||
<para>Block Storage volumes & Instance Ephemeral Filesystems</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Network data</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<section xml:id="ch047_data-encryption-idp50112">
|
||||
<title>Swift Objects</title>
|
||||
<para>The ability to encrypt objects in Swift is presently limited to disk-level encryption per node. However, there does exist third-party extensions and modules for per-object encryption. These modules have been proposed upstream, but have not per this writing been formally accepted. Below are some pointers: </para>
|
||||
<title>Object Storage Objects</title>
|
||||
<para>The ability to encrypt objects in Object Stoarge is presently limited to disk-level encryption per node. However, there does exist third-party extensions and modules for per-object encryption. These modules have been proposed upstream, but have not per this writing been formally accepted. Below are some pointers: </para>
|
||||
<para><link xmlns:xl="http://www.w3.org/1999/xlink" xl:href="https://github.com/Mirantis/swift-encrypt">https://github.com/Mirantis/swift-encrypt</link></para>
|
||||
<para><link xmlns:xl="http://www.w3.org/1999/xlink" xl:href="http://www.mirantis.com/blog/on-disk-encryption-prototype-for-openstack-swift/">http://www.mirantis.com/blog/on-disk-encryption-prototype-for-openstack-swift/</link></para>
|
||||
</section>
|
||||
<section xml:id="ch047_data-encryption-idp53616">
|
||||
<title>Cinder Volumes & Instance Ephemeral Filesystems</title>
|
||||
<title>Block Storage Volumes & Instance Ephemeral Filesystems</title>
|
||||
<para>The ability to encrypt volumes depends on the service backends chosen. Some backends may not support this at all.</para>
|
||||
<para>As both Cinder block storage and Nova compute support LVM backed storage, we can easily provide an example applicable to both systems. In deployments using LVM, encryption may be performed against the backing physical volumes. An encrypted block device would be created using the standard Linux tools, with the LVM physical volume (PV) created on top of the decrypted block device using pvcreate. Then, the vgcreate or vgmodify tool may be used to add the encrypted physical volume to an LVM volume group (VG).</para>
|
||||
<para>A feature aimed for the Havana release provides encryption of the VM's data before it is written to disk. This allows the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This feature presents a normal block storage device to the VM but encrypts the bytes in the virtualization host before writing them to the disk. The block server operates exactly as it does when reading and writing unencrypted blocks, except special handling will be required for Cinder features such as snapshots and live migration. Note that this feature uses an independent key manager.</para>
|
||||
<para>As both block storage and compute support LVM backed storage, we can easily provide an example applicable to both systems. In deployments using LVM, encryption may be performed against the backing physical volumes. An encrypted block device would be created using the standard Linux tools, with the LVM physical volume (PV) created on top of the decrypted block device using pvcreate. Then, the vgcreate or vgmodify tool may be used to add the encrypted physical volume to an LVM volume group (VG).</para>
|
||||
<para>A feature aimed for the Havana release provides encryption of the VM's data before it is written to disk. This allows the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This feature presents a normal block storage device to the VM but encrypts the bytes in the virtualization host before writing them to the disk. The block server operates exactly as it does when reading and writing unencrypted blocks, except special handling will be required for Block Storage features such as snapshots and live migration. Note that this feature uses an independent key manager.</para>
|
||||
</section>
|
||||
<section xml:id="ch047_data-encryption-idp57488">
|
||||
<title>Network Data</title>
|
||||
@ -34,6 +34,6 @@
|
||||
other tunnels. This is not functionality common or standard in
|
||||
OpenStack, but is an option available to motivated and
|
||||
interested implementors.</para>
|
||||
<para>Cinder block storage supports a variety of mechanisms for supplying mountable volumes. It is outside the scope of this guide to specify recommendations for each Cinder backend driver. For the purpose of performance, many storage protocols are unencrypted. Some protocols such as iSCSI can provide authentication and encrypted sessions, it is our recommendation to enable these features.</para>
|
||||
<para>Block storage supports a variety of mechanisms for supplying mountable volumes. It is outside the scope of this guide to specify recommendations for each Block Storage backend driver. For the purpose of performance, many storage protocols are unencrypted. Some protocols such as iSCSI can provide authentication and encrypted sessions, it is our recommendation to enable these features.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
@ -125,7 +125,7 @@ system_u:object_r:svirt_image_t:SystemLow image1
|
||||
system_u:object_r:svirt_image_t:SystemLow image2
|
||||
system_u:object_r:svirt_image_t:SystemLow image3
|
||||
system_u:object_r:svirt_image_t:SystemLow image4</screen>
|
||||
<para>The svirt_image_t label uniquely identifies image files on disk, allowing for the SELinux policy to restrict access. When a KVM-based Nova image is powered on, sVirt appends a random numerical identifier to the image. sVirt is technically capable of assigning numerical identifiers to 524,288 virtual machines per hypervisor node, however OpenStack deployments are highly unlikely to encounter this limitation.</para>
|
||||
<para>The svirt_image_t label uniquely identifies image files on disk, allowing for the SELinux policy to restrict access. When a KVM-based Compute image is powered on, sVirt appends a random numerical identifier to the image. sVirt is technically capable of assigning numerical identifiers to 524,288 virtual machines per hypervisor node, however OpenStack deployments are highly unlikely to encounter this limitation.</para>
|
||||
<para>An example of the sVirt category identifier is shown below:</para>
|
||||
<screen>
|
||||
system_u:object_r:svirt_image_t:s0:c87,c520 image1
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
<para>We consider entropy to refer to the quality and source of random data that is available to an instance. Cryptographic technologies typically rely heavily on randomness, requiring a high quality pool of entropy to draw from. It is typically hard for a virtual machine to get enough entropy to support these operations. Entropy starvation can manifest in instances as something seemingly unrelated for example, slow boot times because the instance is waiting for ssh key generation. Entropy starvation may also motivate users to employ poor quality entropy sources from within the instance, making applications running in the cloud less secure overall.</para>
|
||||
<para>Fortunately, a cloud architect may address these issues by providing a high quality source of entropy to the cloud instances. This can be done by having enough hardware random number generators (HRNG) in the cloud to support the instances. In this case, "enough" is somewhat domain specific. For everyday operations, a modern HRNG is likely to produce enough entropy to support 50-100 compute nodes. High bandwidth HRNGs, such as the RdRand instruction available with Intel Ivy Bridge and newer processors could potentially handle more nodes. For a given cloud, an architect needs to understand the application requirements to ensure that sufficient entropy is available.</para>
|
||||
<para>Once the entropy is available in the cloud, the next step is getting that entropy into the instances. Tools such as the entropy gathering daemon (<link xlink:href="http://egd.sourceforge.net/">EGD</link>) provide a way to fairly and securely distribute entropy through a distributed system. Support exists for using the EGD as an entropy source for LibVirt.</para>
|
||||
<para>Nova support for these features is not generally available, but it would only require a moderate amount of work for implementors to integrate this functionality.</para>
|
||||
<para>Compute support for these features is not generally available, but it would only require a moderate amount of work for implementors to integrate this functionality.</para>
|
||||
</section>
|
||||
<section xml:id="ch055_security-services-for-instances-idp128240">
|
||||
<title>Scheduling Instances to Nodes</title>
|
||||
@ -144,9 +144,9 @@ gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2>&1 | grep
|
||||
</section>
|
||||
<section xml:id="ch055_security-services-for-instances-idp166272">
|
||||
<title>Image Provenance and Validation</title>
|
||||
<para>Unfortunately, it is not currently possible to force Nova to validate an image hash immediately prior to starting an instance. To understand the situation, we begin with a brief overview of how images are handled around the time of image launch.</para>
|
||||
<para>Unfortunately, it is not currently possible to force Compute to validate an image hash immediately prior to starting an instance. To understand the situation, we begin with a brief overview of how images are handled around the time of image launch.</para>
|
||||
<para>Images come from the glance service to the nova service on a node. This transfer should be protected by running over SSL. Once the image is on the node, it is verified with a basic checksum and then it's disk is expanded based on the size of the instance being launched. If, at a later time, the same image is launched with the same instance size on this node, it will be launched from the same expanded image. Since this expanded image is not re-verified before launching, it could be tampered with and the user would not have any way of knowing, beyond a manual inspection of the files in the resulting image.</para>
|
||||
<para>We hope that future versions of Nova and/or Glance will offer support for validating the image hash before each instance launch. An alternative option that would be even more powerful would be allow users to sign an image and then have the signature validated when the instance is launched.</para>
|
||||
<para>We hope that future versions of Compute and/or the Image Service will offer support for validating the image hash before each instance launch. An alternative option that would be even more powerful would be allow users to sign an image and then have the signature validated when the instance is launched.</para>
|
||||
</section>
|
||||
</section>
|
||||
<section xml:id="ch055_security-services-for-instances-idp170576">
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
<para>The generation and collection of logs is an important component of securely monitoring an OpenStack infrastructure. Logs provide visibility into the day-to-day actions of administrators, tenants, and guests, in addition to the activity in the compute, networking, and storage and other components that comprise your OpenStack deployment.</para>
|
||||
<para>The basics of logging: configuration, setting log level, location of the log files, and how to use and customize logs, as well as how to do centralized collections of logs is well covered in the <link xlink:href="http://docs.openstack.org/ops/"><citetitle>OpenStack Operations Guide</citetitle></link>.</para>
|
||||
<para>Logs are not only valuable for proactive security and continuous compliance activities, but they are also a valuable information source for investigating and responding to incidents.</para>
|
||||
<para>For instance, analyzing the access logs of Keystone or its replacement authentication system would alert us to failed logins, their frequency, origin IP, whether the events are restricted to select accounts etc. Log analysis supports detection.</para>
|
||||
<para>For instance, analyzing the access logs of Identity Service or its replacement authentication system would alert us to failed logins, their frequency, origin IP, whether the events are restricted to select accounts etc. Log analysis supports detection.</para>
|
||||
<para>On detection, further action may be to black list an IP, or recommend strengthening user passwords, or even de-activating a user account if it is deemed dormant.</para>
|
||||
<section xml:id="ch058_forensicsincident-response-idp60511">
|
||||
<title>Monitoring Use Cases</title>
|
||||
@ -29,7 +29,7 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<itemizedlist><listitem>
|
||||
<para>Other events that are actionable are networking bridges going down, ip tables being flushed on nova compute nodes and consequential loss of access to instances resulting in unhappy customers. </para>
|
||||
<para>Other events that are actionable are networking bridges going down, ip tables being flushed on compute nodes and consequential loss of access to instances resulting in unhappy customers. </para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<itemizedlist><listitem>
|
||||
|
||||
@ -49,7 +49,7 @@
|
||||
<para>The Health Insurance Portability and Accountability Act (HIPAA) is a United States congressional act that governs the collection, storage, use and destruction of patient health records. The act states that Protected Health Information (PHI) must be rendered "unusable, unreadable, or indecipherable" to unauthorized persons and that encryption for data 'at-rest' and 'inflight' should be addressed.</para>
|
||||
<para>HIPAA is not a certification, rather a guide for protecting healthcare data. Similar to the PCI-DSS, the most important issues with both PCI and HIPPA is that a breach of credit card information, and health data, do not occur. In the instance of a breach the cloud provider will be scrutinized for compliance with PCI and HIPPA controls. If proven compliant, the provider can be expected to immediately implement remedial controls, breach notification responsibilities, and significant expenditure on additional compliance activities. If not compliant, the cloud provider can expect on-site audit teams, fines, potential loss of merchant ID (PCI), and massive reputational impact.</para>
|
||||
<para>Users or organizations that possess PHI must support HIPAA requirements and are HIPAA covered entities. If an entity intends to use a service, or in this case, an OpenStack cloud that might use, store or have access to that PHI, then a Business Associate Agreement must be signed. The BAA is a contract between the HIPAA covered entity and the OpenStack service provider that requires the provider to handle that PHI in accordance with HIPAA requirements. If the service provider does not handle the PHI (e.g. with security controls and hardening) then they are subject to HIPAA fines and penalties.</para>
|
||||
<para>OpenStack architects interpret and respond to HIPAA statements, with data encryption remaining a core practice. Currently this would require any protected health information contained within an OpenStack deployment to be encrypted with industry standard encryption algorithms. Potential future OpenStack projects such as Swift object encryption will facilitate HIPAA guidelines for compliance with the act.</para>
|
||||
<para>OpenStack architects interpret and respond to HIPAA statements, with data encryption remaining a core practice. Currently this would require any protected health information contained within an OpenStack deployment to be encrypted with industry standard encryption algorithms. Potential future OpenStack projects such as object encryption will facilitate HIPAA guidelines for compliance with the act.</para>
|
||||
<para>For more details see the <link xlink:href="https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf">Health Insurance Portability And Accountability Act</link>.</para>
|
||||
<section xml:id="ch064_certifications-compliance-statements-idp4736">
|
||||
<title>PCI-DSS</title>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user