openstack/openstack-manuals
Code Issues Proposed changes

Edits on security guide

Browse Source 
Change all titles to sentence style capitalization (some were already,
majority not)
Adjust project and service name spelling.
Minor edits
Fix links to TPM section

Change-Id: Ic8cc709b068d2273762f074daa5ac30ebe9aaf20
Partial-Bug: #1217503
This commit is contained in:
Andreas Jaeger
2014-05-05 21:32:29 +02:00
parent 7469b6767d
commit 6bf4dedafc
52 changed files with 792 additions and 399 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/security-guide/ch001_acknowledgements.xml
View File

@@ -1,5 +1,9 @@
<?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="ch001_acknowledgements"><?dbhtml stop-chunking?>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0" xml:id="ch001_acknowledgements">
<?dbhtml stop-chunking?>
<title>Acknowledgments</title>
<para>The OpenStack Security Group would like to acknowledge contributions from the following organizations who were instrumental in making this book possible. These are:</para>
<para>

9
doc/security-guide/ch002_why-and-how-we-wrote-this-book.xml
View File

@@ -1,5 +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="ch002_why-and-how-we-wrote-this-book"><?dbhtml stop-chunking?>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch002_why-and-how-we-wrote-this-book">
<?dbhtml stop-chunking?>
<title>Why and how we wrote this book</title>
<para>As OpenStack adoption continues to grow and the product matures, security has become a priority. The OpenStack Security Group has recognized the need for a comprehensive and authoritative security guide. The <emphasis role="bold">OpenStack Security Guide</emphasis> has been written to provide an overview of security best practices, guidelines, and recommendations for increasing the security of an OpenStack deployment. The authors bring their expertise from deploying and securing OpenStack in a variety of environments.</para>
<para>The guide augments the <link xlink:href="http://docs.openstack.org/ops/"><citetitle>OpenStack Operations Guide</citetitle></link> and can be referenced to harden existing OpenStack deployments or to evaluate the security controls of OpenStack cloud providers.</para>
@@ -109,7 +114,7 @@
</para>
<para>Rodney D. Beede is the Cloud Security Engineer for
Seagate Technology. He contributed the missing chapter on
securing OpenStack Object Storage (Swift). He holds a M.S.
securing OpenStack Object Storage (swift). He holds a M.S.
in Computer Science from the University of Colorado.
</para>
</listitem>

20
doc/security-guide/ch004_book-introduction.xml
View File

@@ -142,9 +142,9 @@
</section>
<section xml:id="ch004_book-introduction-idp138800">
<title>Object Storage</title>
<para>The OpenStack Object Storage Service (Swift) provides
<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
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>
@@ -159,7 +159,7 @@
</section>
<section xml:id="ch004_book-introduction-idp141536">
<title>Block Storage</title>
<para>The OpenStack Block Storage service (Cinder) provides
<para>The OpenStack Block Storage service (cinder) provides
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
@@ -169,8 +169,8 @@
</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
<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,
@@ -184,7 +184,7 @@
</section>
<section xml:id="ch004_book-introduction-idp145600">
<title>Dashboard</title>
<para>The OpenStack Dashboard Service (Horizon) provides a
<para>The OpenStack dashboard (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
@@ -192,11 +192,11 @@
security concerns of public web portals.</para>
</section>
<section xml:id="ch004_book-introduction-idp147104">
<title>Identity Service</title>
<para>The OpenStack Identity Service (Keystone) is a <emphasis
<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
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
@@ -204,7 +204,7 @@
</section>
<section xml:id="ch004_book-introduction-idp149712">
<title>Image Service</title>
<para>The OpenStack Image Service (Glance) provides disk image
<para>The OpenStack Image Service (glance) provides disk image
management services. The Image Service provides image
discovery, registration, and delivery services to the
Compute service, as needed.</para>

81
doc/security-guide/ch005_security-domains.xml
View File

@@ -1,9 +1,14 @@
<?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="ch005_security-domains"><?dbhtml stop-chunking?>
<title>Security Boundaries and Threats</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch005_security-domains">
<?dbhtml stop-chunking?>
<title>Security boundaries and threats</title>
<para>A cloud can be abstracted as a collection of logical components by virtue of their function, users, and shared security concerns, which we call security domains. Threat actors and vectors are classified based on their motivation and access to resources. Our goal is to provide you a sense of the security concerns with respect to each domain depending on your risk/vulnerability protection objectives.</para>
<section xml:id="ch005_security-domains-idp39040">
<title>Security Domains</title>
<title>Security domains</title>
<para>A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization (AuthN/Z) requirements and users.</para>
<para>Although you may desire to break these domains down further (we later discuss where this may be appropriate), we generally refer to four distinct security domains which form the bare minimum that is required to deploy any OpenStack cloud securely. These security domains are:</para>
<orderedlist><listitem>
@@ -49,7 +54,7 @@
</section>
</section>
<section xml:id="ch005_security-domains-idp61360">
<title>Bridging Security Domains</title>
<title>Bridging security domains</title>
<para>A <emphasis>bridge</emphasis> is a component that exists inside more than one security domain. Any component that bridges security domains with different trust levels or authentication requirements must be carefully configured. These bridges are often the weak points in network architecture. A bridge should always be configured to meet the security requirements of the highest trust level of any of the domains it is bridging. In many cases the security controls for bridges should be a primary concern due to the likelihood of attack.</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="266" contentwidth="222" fileref="static/bridging_security_domains_1.png" format="PNG" scalefit="1"/>
@@ -70,37 +75,71 @@
<para>The design of OpenStack is such that separation of security domains is difficult - as core services will usually bridge at least two domains, special consideration must be given when applying security controls to them.</para>
</section>
<section xml:id="ch005_security-domains-idp95264">
<title>Threat Classification, Actors and Attack Vectors</title>
<title>Threat classification, actors and attack vectors</title>
<para>Most types of cloud deployment, public or private, are exposed to some form of attack. In this chapter we categorize attackers and summarize potential types of attacks in each security domain.</para>
<section xml:id="ch005_security-domains-idp96560">
<title>Threat Actors</title>
<para>A threat actor is an abstract way to refer to a class of adversary that you may attempt to defend against. The more capable the actor, the more expensive the security controls that are required for successful attack mitigation and prevention. Security is a tradeoff between cost, usability and defense. In some cases it will not be possible to secure a cloud deployment against all of the threat actors we describe here. Those deploying an OpenStack cloud will have to decide where the balance lies for their deployment / usage.</para>
<title>Threat actors</title>
<para>A threat actor is an abstract way to refer to a class of
adversary that you may attempt to defend against. The more
capable the actor, the more expensive the security controls
that are required for successful attack mitigation and
prevention. Security is a tradeoff between cost, usability and
defense. In some cases it will not be possible to secure a
cloud deployment against all of the threat actors we describe
here. Those deploying an OpenStack cloud will have to decide
where the balance lies for their deployment / usage.</para>
<itemizedlist><listitem>
<para><emphasis role="bold">Intelligence Services</emphasis> &#x2014; Considered by this guide as the most capable adversary. Intelligence Services and other state actors can bring tremendous resources to bear on a target. They have capabilities beyond that of any other actor. It is very difficult to defend against these actors without incredibly stringent controls in place, both human and technical.</para>
<para><emphasis role="bold">Intelligence
services</emphasis> &#x2014; Considered by this guide as
the most capable adversary. Intelligence Services and
other state actors can bring tremendous resources to bear
on a target. They have capabilities beyond that of any
other actor. It is very difficult to defend against these
actors without incredibly stringent controls in place,
both human and technical.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Serious Organized Crime</emphasis> &#x2014; Highly capable and financially driven groups of attackers. Able to fund in-house exploit development and target research. In recent years the rise of organizations such as the Russian Business Network, a massive cyber-criminal enterprise has demonstrated how cyber attacks have become a commodity. Industrial espionage falls within the SOC group.</para>
<listitem>
<para><emphasis role="bold">Serious organized
crime</emphasis> &#x2014; Highly capable and financially
driven groups of attackers. Able to fund in-house exploit
development and target research. In recent years the rise
of organizations such as the Russian Business Network, a
massive cyber-criminal enterprise has demonstrated how
cyber attacks have become a commodity. Industrial
espionage falls within the SOC group.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Highly Capable Groups</emphasis> &#x2014; This refers to 'Hacktivist' type organizations who are not typically commercially funded but can pose a serious threat to service providers and cloud operators.</para>
<listitem>
<para><emphasis role="bold">Highly capable
groups</emphasis> &#x2014; This refers to 'Hacktivist'
type organizations who are not typically commercially
funded but can pose a serious threat to service providers
and cloud operators.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Motivated Individuals</emphasis> &#x2014; Acting alone, these attackers come in many guises, such as rogue or malicious employees, disaffected customers, or small-scale industrial espionage.</para>
<listitem>
<para><emphasis role="bold">Motivated
individuals</emphasis> &#x2014; Acting alone, these
attackers come in many guises, such as rogue or malicious
employees, disaffected customers, or small-scale
industrial espionage.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Script Kiddies</emphasis> &#x2014; Automated vulnerability scanning/exploitation. Non-targeted attacks. Often only a nuisance, compromise by one of these actors presents a major risk to an organization's reputation.</para>
<listitem>
<para><emphasis role="bold">Script kiddies</emphasis>
&#x2014; Automated vulnerability
scanning/exploitation. Non-targeted attacks. Often only a
nuisance, compromise by one of these actors presents a
major risk to an organization's reputation.</para>
</listitem>
</itemizedlist>
</itemizedlist>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="403" contentwidth="472" fileref="static/threat_actors.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/threat_actors.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
</inlinemediaobject></para>
</section>
<section xml:id="ch005_security-domains-idp111680">
<title>Public / Private Considerations</title>
<title>Public and private cloud considerations</title>
<para>Private clouds are typically deployed by enterprises or institutions inside their networks and behind their firewalls. Enterprises will have strict policies on what data is allowed to exit their network and may even have different clouds for specific purposes. Users of a private cloud are typically employees of the organization that owns the cloud and are able to be held accountable for their actions. Employees often attend training sessions before accessing the cloud and will likely take part in regular scheduled security awareness training. Public clouds by contrast cannot make any assertions about their users, cloud use-cases or user motivations. This immediately pushes the guest security domain into a completely <emphasis>untrusted</emphasis> state for public cloud providers.</para>
<para>A notable difference in the attack surface of public clouds is that they must provide internet access to their services. Instance connectivity, access to files over the internet and the ability to interact with the cloud controlling fabric such as the API endpoints and dashboard are must-haves for the public cloud.</para>
<para>Privacy concerns for public and private cloud users are typically diametrically opposed. The data generated and stored in private clouds is normally owned by the operator of the cloud, who is able to deploy technologies such as data loss prevention (DLP) protection, file inspection, deep packet inspection and prescriptive firewalling. In contrast, privacy is one of the primary barriers to adoption for the public cloud, as many of these controls do not exist.</para>
@@ -110,7 +149,7 @@
<para>Careful consideration should be given to potential outbound abuse from a cloud deployment. Whether public or private, clouds tend to have lots of resource available. An attacker who has established a point of presence within the cloud, either through hacking in or via entitled access (rogue employee), can bring these resources to bear against the internet at large. Clouds with Compute services make for ideal DDoS and brute force engines. This is perhaps a more pressing issue for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks. Major damage can be inflicted upon a company's reputation if it becomes known for hosting malicious software or launching attacks on other networks. Methods of prevention include egress security groups, outbound traffic inspection, customer education and awareness, and fraud and abuse mitigation strategies.</para>
</section>
<section xml:id="ch005_security-domains-idp120000">
<title>Attack Types</title>
<title>Attack types</title>
<para>The diagram shows the types of attacks that may be expected from the actors described in the previous section. Note that there will always be exceptions to this diagram but in general, this describes the sorts of attack that could be typical for each actor.</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="642" contentwidth="616" fileref="static/high-capability.png" format="PNG" scalefit="1"/>

6
doc/security-guide/ch006_introduction-to-case-studies.xml
View File

@@ -5,11 +5,11 @@
version="5.0"
xml:id="ch006_introduction-to-case-studies">
<?dbhtml stop-chunking?>
<title>Introduction to Case Studies</title>
<title>Introduction to case studies</title>
<para>This guide refers to two running case studies, which are
introduced here and referred to at the end of each chapter.</para>
<section xml:id="ch006_introduction-to-case-studies-idp44496">
<title>Case Study : Alice the private cloud builder</title>
<title>Case study: Alice, the private cloud builder</title>
<para>Alice deploys a private cloud for use by a government
department in the US. The cloud must comply with relevant
standards, such as FedRAMP. The security paperwork requirements
@@ -22,7 +22,7 @@
logging services.</para>
</section>
<section xml:id="ch006_introduction-to-case-studies-idp46720">
<title>Case Study : Bob the public cloud provider</title>
<title>Case study: Bob, the public cloud provider</title>
<para>Bob is a lead architect for a company that deploys a large
greenfield public cloud. This cloud provides IaaS for the masses
and enables any consumer with a valid credit card access to

18
doc/security-guide/ch008_system-roles-types.xml
View File

@@ -5,7 +5,7 @@
version="5.0"
xml:id="ch008_system-roles-types">
<?dbhtml stop-chunking?>
<title>System Documentation Requirements</title>
<title>System documentation requirements</title>
<para>The system documentation for an OpenStack cloud deployment
should follow the templates and best practices for the Enterprise
Information Technology System in your organization. Organizations
@@ -15,7 +15,7 @@
related to documenting the dynamic cloud infrastructure and
keeping the information up-to-date.</para>
<section xml:id="ch008_system-roles-types-idp44832">
<title>System Roles &amp; Types</title>
<title>System roles and types</title>
<para>The two broadly defined types of
nodes that generally make up an OpenStack installation are:</para>
<itemizedlist>
@@ -34,7 +34,7 @@
</itemizedlist>
</section>
<section xml:id="ch008_system-roles-types-idp48496">
<title>System Inventory</title>
<title>System inventory</title>
<para>Documentation should provide a general description of the
OpenStack environment and cover all systems used (production,
development, test, etc.). Documenting system components,
@@ -45,7 +45,7 @@
virtual machines or virtual disk volumes that would otherwise be
persistent resources in a traditional IT system.</para>
<section xml:id="ch008_system-roles-types-idp50832">
<title>Hardware Inventory</title>
<title>Hardware inventory</title>
<para>Clouds without stringent compliance requirements for
written documentation might benefit from having a
Configuration Management Database
@@ -60,7 +60,7 @@
are available.</para>
</section>
<section xml:id="ch008_system-roles-types-idp53536">
<title>Software Inventory</title>
<title>Software inventory</title>
<para>Just as with hardware, all software components within the
OpenStack deployment should be documented. Components here
should include system databases; OpenStack software components
@@ -73,8 +73,8 @@
</section>
</section>
<section xml:id="ch008_system-roles-types-idp55328">
<title>Network Topology</title>
<para>A Network Topology should be provided with highlights
<title>Network topology</title>
<para>A network topology should be provided with highlights
specifically calling out the data flows and bridging points
between the security domains. Network ingress and egress points
should be identified along with any OpenStack logical system
@@ -85,8 +85,8 @@
created by OpenStack.</para>
</section>
<section xml:id="ch008_system-roles-types-idp57520">
<title>Services, Protocols and Ports</title>
<para>The Service, Protocols and Ports table provides important
<title>Services, protocols and ports</title>
<para>The service, protocols and ports table provides important
additional detail of an OpenStack deployment. A table view of
all services running within the cloud infrastructure can
immediately inform, guide, and help check security procedures.

13
doc/security-guide/ch009_case-studies.xml
View File

@@ -1,14 +1,19 @@
<?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="ch009_case-studies"><?dbhtml stop-chunking?>
<title>Case Studies: System Documentation</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch009_case-studies">
<?dbhtml stop-chunking?>
<title>Case studies: system documentation</title>
<para>In this case study we discuss how Alice and Bob would address their system documentation requirements. The documentation suggested above includes hardware and software records, network diagrams, and system configuration details.</para>
<section xml:id="ch009_case-studies-idp44480">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>Alice needs detailed documentation to satisfy FedRamp requirements. She sets up a configuration management database (CMDB) to store information regarding all of the hardware, firmware, and software versions used throughout the cloud. She also creates a network diagram detailing the cloud architecture, paying careful attention to the security domains and the services that span multiple security domains.</para>
<para>Alice also needs to record each network service running in the cloud, what interfaces and ports it binds to, the security domains for each service, and why the service is needed. Alice decides to build automated tools to log into each system in the cloud over secure shell (SSH) using the <link xlink:href="http://fabfile.org">Python Fabric library</link>. The tools collect and store the information in the CMDB, which simplifies the audit process.</para>
</section>
<section xml:id="ch009_case-studies-idp47344">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>In this case, Bob will approach these steps the same as Alice.</para>
</section>
</chapter>

9
doc/security-guide/ch011_management-introduction.xml
View File

@@ -1,6 +1,11 @@
<?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="ch011_management-introduction"><?dbhtml stop-chunking?>
<title>Management Introduction</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch011_management-introduction">
<?dbhtml stop-chunking?>
<title>Management introduction</title>
<para>A cloud deployment is a living system. Machines age and fail, software becomes outdated, vulnerabilities are discovered. When errors or omissions are made in configuration, or when software fixes must be applied, these changes must be made in a secure, but convenient, fashion. These changes are typically solved through configuration management.</para>
<para>Likewise, it is important to protect the cloud deployment from being configured or manipulated by malicious entities. With many systems in a cloud employing compute and networking virtualization, there are distinct challenges applicable to OpenStack which must be addressed through integrity lifecycle management.</para>
<para>Finally, administrators must perform command and control over the cloud for various operational functions. It is important these command and control facilities are understood and secured.</para>

18
doc/security-guide/ch012_configuration-management.xml
View File

@@ -5,7 +5,7 @@
version="5.0"
xml:id="ch012_configuration-management">
<?dbhtml stop-chunking?>
<title>Continuous Systems Management</title>
<title>Continuous systems management</title>
<para>A cloud will always have bugs. Some of these will be security
problems. For this reason, it is critically important to be
prepared to apply security updates and general software updates.
@@ -13,7 +13,7 @@
are discussed below. This also involves knowing when an upgrade is
necessary.</para>
<section xml:id="ch012_configuration-management-idp44720">
<title>Vulnerability Management</title>
<title>Vulnerability management</title>
<para>For announcements regarding security relevant changes,
subscribe to the <link
xlink:href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce"
@@ -162,7 +162,7 @@
line, whereas a low-level update might be more relaxed.</para>
</section>
<section xml:id="ch012_configuration-management-idp100864">
<title>Testing the Updates</title>
<title>Testing the updates</title>
<para>You should test any update before you deploy it in a
production environment. Typically this requires having a
separate test cloud setup that first receives the update. This
@@ -174,7 +174,7 @@
such as a specific vulnerability, is actually fixed.</para>
</section>
<section xml:id="ch012_configuration-management-idp102976">
<title>Deploying the Updates</title>
<title>Deploying the updates</title>
<para>Once the updates are fully tested, they can be deployed to
the production environment. This deployment should be fully
automated using the configuration management tools described
@@ -182,7 +182,7 @@
</section>
</section>
<section xml:id="ch012_configuration-management-idp104464">
<title>Configuration Management</title>
<title>Configuration management</title>
<para>A production quality cloud should always use tools to
automate configuration and deployment. This eliminates human
error, and allows the cloud to scale much more rapidly.
@@ -233,7 +233,7 @@
</listitem>
</itemizedlist>
<section xml:id="ch012_configuration-management-idp8400">
<title>Policy Changes</title>
<title>Policy changes</title>
<para>Whenever a policy or configuration management is changed,
it is good practice to log the activity, and backup a copy of
the new set. Often, such policies and configurations are
@@ -241,13 +241,13 @@
</section>
</section>
<section xml:id="ch012_configuration-management-idp10160">
<title>Secure Backup and Recovery</title>
<title>Secure backup and recovery</title>
<para>It is important to include Backup procedures and policies in
the overall System Security Plan. For a good overview of
OpenStack's Backup and Recovery capabilities and procedures,
please refer to the OpenStack Operations Guide.</para>
<section xml:id="ch012_configuration-management-idp123104">
<title>Security Considerations</title>
<title>Security considerations</title>
<itemizedlist>
<listitem>
<para>Ensure only authenticated users and backup clients
@@ -294,7 +294,7 @@
</section>
</section>
<section xml:id="ch012_configuration-management-idp131856">
<title>Security Auditing Tools</title>
<title>Security auditing tools</title>
<para>Security auditing tools can complement the configuration
management tools. Security auditing tools automate the process
of verifying that a large number of security controls are

18
doc/security-guide/ch013_node-bootstrapping.xml
View File

@@ -5,7 +5,7 @@
version="5.0"
xml:id="ch013_node-bootstrapping">
<?dbhtml stop-chunking?>
<title>Integrity Life-cycle</title>
<title>Integrity life-cycle</title>
<para>We define integrity life cycle as a deliberate process that
provides assurance that we are always running the expected
software with the expected configurations throughout the cloud.
@@ -14,7 +14,7 @@
chapter provides recommendations on how to approach the integrity
life-cycle process.</para>
<section xml:id="ch013_node-bootstrapping-idp44768">
<title>Secure Bootstrapping</title>
<title>Secure bootstrapping</title>
<para>Nodes in the cloud -- including compute, storage, network,
service, and hybrid nodes -- should have an automated
provisioning process. This ensures that nodes are provisioned
@@ -47,7 +47,7 @@
should refer to the related specifications and software
configuration manuals.</para>
<section xml:id="ch013_node-bootstrapping-idp48720">
<title>Node Provisioning</title>
<title>Node provisioning</title>
<para>Nodes should use Preboot eXecution Environment (PXE) for
provisioning. This significantly reduces the effort required
for redeploying nodes. The typical process involves the node
@@ -89,7 +89,7 @@
operations.</para>
</section>
<section xml:id="ch013_node-bootstrapping-idp58144">
<title>Verified Boot</title>
<title>Verified boot</title>
<para>In general, there are two different strategies for
verifying the boot process. Traditional <emphasis>secure
boot</emphasis> will validate the code run at each step in
@@ -240,7 +240,7 @@
here will be deployment and failure mode specific.</para>
</section>
<section xml:id="ch013_node-bootstrapping-idp3728">
<title>Node Hardening</title>
<title>Node hardening</title>
<para>At this point we know that the node has booted with the
correct kernel and underlying components. There are many paths
for hardening a given operating system deployment. The
@@ -286,7 +286,7 @@
</section>
</section>
<section xml:id="ch013_node-bootstrapping-idp11376">
<title>Runtime Verification</title>
<title>Runtime verification</title>
<para>Once the node is running, we need to ensure that it remains
in a good state over time. Broadly speaking, this includes both
configuration management and security monitoring. The goals for
@@ -295,7 +295,7 @@
discuss configuration management in the management section, and
security monitoring below.</para>
<section xml:id="ch013_node-bootstrapping-idp135504">
<title>Intrusion Detection System</title>
<title>Intrusion detection system</title>
<para>Host-based intrusion detection tools are also useful for
automated validation of the cloud internals. There are a wide
variety of host-based intrusion detection tools available.
@@ -354,9 +354,9 @@
</itemizedlist>
<para>Network intrusion detection tools complement the
host-based tools. OpenStack doesn't have a specific network
IDS built-in, but OpenStack's networking component, Neutron,
IDS built-in, but OpenStack Networking
provides a plug-in mechanism to enable different technologies
via the Neutron API. This plug-in architecture will allow
through the Networking API. This plug-in architecture will allow
tenants to develop API extensions to insert and configure
their own advanced networking services like a firewall, an
intrusion detection system, or a VPN between the VMs.</para>

67
doc/security-guide/ch014_best-practices-for-operator-mode-access.xml
View File

@@ -5,33 +5,39 @@
version="5.0"
xml:id="ch014_best-practices-for-operator-mode-access">
<?dbhtml stop-chunking?>
<title>Management Interfaces</title>
<title>Management interfaces</title>
<para>It is necessary for administrators to perform command and
control over the cloud for various operational functions. It is
important these command and control facilities are understood and
secured.</para>
<para>OpenStack provides several management interfaces for operators and tenants:</para>
<itemizedlist><listitem>
<para>OpenStack dashboard (Horizon)</para>
<para>OpenStack dashboard (horizon)</para>
</listitem>
<listitem>
<listitem>
<para>OpenStack API</para>
</listitem>
<listitem>
<para>Secure Shell (SSH)</para>
<listitem>
<para>Secure shell (SSH)</para>
</listitem>
<listitem>
<para>OpenStack Management Utilities (for example,
<listitem>
<para>OpenStack management utilities (for example,
<systemitem class="service">nova-manage</systemitem>,
<systemitem class="service">glance-manage</systemitem>)</para>
</listitem>
<listitem>
<para>Out-of-Band Management Interfaces (IPMI, etc.)</para>
<listitem>
<para>Out-of-band management interfaces, such as IPMI</para>
</listitem>
</itemizedlist>
</itemizedlist>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp49280">
<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>
<para>
The OpenStack dashboard (horizon) provides administrators and
tenants with 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>
@@ -52,7 +58,7 @@
</itemizedlist>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp56400">
<title>Security Considerations</title>
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The dashboard requires cookies and JavaScript to be enabled in the web browser.</para>
</listitem>
@@ -60,15 +66,26 @@
<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>
<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>
</listitem>
<listitem>
<para>It is now possible (though there are numerous deployment/security implications) to upload an image file directly from a user’s hard disk to OpenStack Image Service through the dashboard. For multi-GB images it is still strongly recommended that the upload be done using the Glance CLI</para>
<listitem>
<para>
It is now possible (though there are numerous
deployment/security implications) to upload an image
file directly from a user’s hard disk to OpenStack Image
Service through the dashboard. For multi-gigabyte images it is
still strongly recommended that the upload be done using
the <command>glance</command> CLI.
</para>
</listitem>
<listitem>
<para>Create and manage security groups through dashboard. The security groups allows L3-L4 packet filtering for security policies to protect virtual machines</para>
<listitem>
<para>
Create and manage security groups through dashboard. The
security groups allows L3-L4 packet filtering for
security policies to protect virtual machines.
</para>
</listitem>
</itemizedlist>
</itemizedlist>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp62384">
<title>References</title>
@@ -98,7 +115,7 @@
</itemizedlist>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp68272">
<title>Security Considerations</title>
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The API service should be configured for SSL to ensure data is encrypted.</para>
</listitem>
@@ -109,10 +126,10 @@
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp71184">
<title>Secure Shell (SSH)</title>
<title>Secure shell (SSH)</title>
<para>It has become industry practice to use secure shell (SSH) access for the management of Linux and Unix systems. SSH uses secure cryptographic primitives for communication. With the scope and importance of SSH in typical OpenStack deployments, it is important to understand best practices for deploying SSH.</para>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp72528">
<title>Host Key Fingerprints</title>
<title>Host key fingerprints</title>
<para>Often overlooked is the need for key management for SSH hosts. As most or all hosts in an OpenStack deployment will provide an SSH service, it is important to have confidence in connections to these hosts. It cannot be understated that failing to provide a reasonably secure and accessible method to verify SSH host key fingerprints is ripe for abuse and exploitation.</para>
<para>All SSH daemons have private host keys and, upon connection, offer a host key fingerprint. This host key fingerprint is the hash of an unsigned public key. It is important these host key fingerprints are known in advance of making SSH connections to those hosts. Verification of host key fingerprints is instrumental in detecting man-in-the-middle attacks.</para>
<para>Typically, when an SSH daemon is installed, host keys will be generated. It is necessary that the hosts have sufficient entropy during host key generation. Insufficient entropy during host key generation can result in the possibility to eavesdrop on SSH sessions.</para>
@@ -120,7 +137,7 @@
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp76272">
<title>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 (for example, <systemitem
@@ -131,7 +148,7 @@
dedicated management utilities are slowly being
deprecated.</para>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp77728">
<title>Security Considerations</title>
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The dedicated management utilities (*-manage) in some cases use the direct database connection.</para>
</listitem>
@@ -147,7 +164,7 @@
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp82336">
<title>Out-of-Band Management Interface</title>
<title>Out-of-band management interface</title>
<para>OpenStack management relies on out-of-band management
interfaces such as the IPMI protocol to access into nodes
running OpenStack components. IPMI is a very popular
@@ -155,7 +172,7 @@
whether the operating system is running or the system has
crashed.</para>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp83712">
<title>Security Considerations</title>
<title>Security considerations</title>
<itemizedlist><listitem>
<para>Use strong passwords and safeguard them, or use client-side SSL authentication.</para>
</listitem>

14
doc/security-guide/ch015_case-studies-management.xml
View File

@@ -5,32 +5,32 @@
version="5.0"
xml:id="ch015_case-studies-management">
<?dbhtml stop-chunking?>
<title>Case Studies: Management Interfaces</title>
<title>Case studies: management interfaces</title>
<para>Previously we discussed typical OpenStack management
interfaces and associated backplane issues. We will now approach
these issues by returning to our Alice and Bob case study.
Specifically, we will look into how both Alice and Bob will
address:</para>
<itemizedlist><listitem>
<para>Cloud Administration</para>
<para>Cloud administration</para>
</listitem>
<listitem>
<para>Self Service</para>
<para>Self service</para>
</listitem>
<listitem>
<para>Data Replication &amp; Recovery</para>
<para>Data replication and recovery</para>
</listitem>
<listitem>
<para>SLA &amp; Security Monitoring.</para>
<para>SLA and security monitoring</para>
</listitem>
</itemizedlist>
<section xml:id="ch015_case-studies-management-idp48432">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>When building her private cloud, while air-gapped, Alice still needs to consider her service management interfaces. Before deploying her private cloud, Alice has completed her system documentation. Specifically she has identified which OpenStack services will exist in each security domain. From there Alice has further restricted access to management interfaces by deploying a combination of IDS, SSL encryption, and physical network isolation. Additionally, Alice requires high availability and redundant services. Thus, Alice sets up redundant infrastructure for various OpenStack API services.</para>
<para>Alice also needs to provide assurances that the physical servers and hypervisors have been built from a known secure state into a well-defined configuration. To enable this, Alice uses a combination of a Configuration Management platform to configure each machine according to the standards and regulations she must comply with. It will also enable Alice to report periodically on the state of her cloud and perform remediation to a known state should anything be out of the ordinary. Additionally, Alice provides hardware assurances by using a PXE system to build her nodes from a known set of base images. During the boot process, Alice provides further assurances by enabling Intel TXT and related trusted boot technologies provided by the hardware.</para>
</section>
<section xml:id="ch015_case-studies-management-idp51424">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>As a public cloud provider, Bob is concerned with both the continuous availability of management interfaces and the security of transactions to the management interfaces. To that end Bob implements multiple redundant OpenStack API endpoints for the services his cloud will run. Additionally on the public network Bob uses SSL to encrypt all transactions between his customers and his cloud interfaces. To isolate his cloud operations Bob has physically isolated his management, instance migration, and storage networks.</para>
<para>To ease scaling and reduce management overhead Bob implements a configuration management system. For customer data assurances, Bob offers a backup as a service product as requirements will vary between customers. Finally, Bob does not provide a "baremetal" or the ability to schedule an entire node, so to reduce management overhead and increase operational efficiency Bob does not implement any node boot time security.</para>
</section>

13
doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml
View File

@@ -1,5 +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="ch017_threat-models-confidence-and-confidentiality"><?dbhtml stop-chunking?>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch017_threat-models-confidence-and-confidentiality">
<?dbhtml stop-chunking?>
<title>Introduction to SSL/TLS</title>
<para>OpenStack services receive requests on behalf of users on public networks as well as from other internal services over management networks. Inter-service communications can also occur over public networks depending on deployment and architecture choices.</para>
<para>While it is commonly accepted that data over public networks should be secured using cryptographic measures, such as Secure Sockets Layer or Transport Layer Security (SSL/TLS) protocols, it is insufficient to rely on security domain separation to protect internal traffic. Using a security-in-depth approach, we recommend securing all domains with SSL/TLS, including the management domain services. It is important that should a tenant escape their VM isolation and gain access to the hypervisor or host resources, compromise an API endpoint, or any other service, they must not be able to easily inject or capture messages, commands, or otherwise affect or control management capabilities of the cloud. SSL/TLS provides the mechanisms to ensure authentication, non-repudiation, confidentiality, and integrity of user communications to the OpenStack services and between the OpenStack services themselves.</para>
@@ -22,18 +27,18 @@
</itemizedlist>
<para>PKI builds the framework on which to provide encryption algorithms, cipher modes, and protocols for securing data and authentication. We strongly recommend securing all services with Public Key Infrastructure (PKI), including the use of SSL/TLS for API endpoints. It is impossible for the encryption or signing of transports or messages alone to solve all these problems. Hosts themselves must be secure and implement policy, namespaces, and other controls to protect their private credentials and keys. However, the challenges of key management and protection do not reduce the necessity of these controls, or lessen their importance.</para>
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp51264">
<title>Certification Authorities</title>
<title>Certification authorities</title>
<para>Many organizations have an established Public Key Infrastructure with their own certification authority (CA), certificate policies, and management for which they should use to issue certificates for internal OpenStack users or services. Organizations in which the public security domain is Internet facing will additionally need certificates signed by a widely recognized public CA. For cryptographic communications over the management network, it is recommended one not use a public CA. Instead, we expect and recommend most deployments deploy their own internal CA.</para>
<para>It is recommended that the OpenStack cloud architect consider using separate PKI deployments for internal systems and customer facing services. This allows the cloud deployer to maintain control of their PKI infrastructure and among other things makes requesting, signing and deploying certificates for internal systems easier. Advanced configurations may use separate PKI deployments for different security domains. This allows deployers to maintain cryptographic separation of environments, ensuring that certificates issued to one are not recognised by another.</para>
<para>Certificates used to support SSL/TLS on internet facing cloud endpoints (or customer interfaces where the customer is not expected to have installed anything other than standard operating system provided certificate bundles) should be provisioned using Certificate Authorities that are installed in the operating system certificate bundle. Typical well known vendors include Verisign and Thawte but many others exist.</para>
<para>There are many management, policy, and technical challenges around creating and signing certificates as such is an area where cloud architects or operators may wish to seek the advice of industry leaders and vendors in addition to the guidance recommended here.</para>
</section>
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp55136">
<title>SSL/TLS Libraries</title>
<title>SSL/TLS libraries</title>
<para>Various components, services, and applications within the OpenStack ecosystem or dependencies of OpenStack are implemented and can be configured to use SSL/TLS libraries. The SSL/TLS and HTTP services within OpenStack are typically implemented using OpenSSL which has been proven to be fairly secure and has a module that has been validated for FIPS 140-2. However, keep in mind that each application or service can still introduce weaknesses in how they use the OpenSSL libraries.</para>
</section>
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp56784">
<title>Cryptographic Algorithms, Cipher Modes, and Protocols</title>
<title>Cryptographic algorithms, cipher modes, and protocols</title>
<para>We recommend only using TLS v1.1 or v1.2. SSLv3 and TLSv1.0 may be used for compatibility but we recommend using caution and only enabling these protocols if you have a strong requirement to do so. Other SSL/TLS versions, explicitly older versions, should not be used. These older versions include SSLv1 and SSLv2. As this book does not intend to be a thorough reference on cryptography we do not wish to be prescriptive about what specific algorithms or cipher modes you should enable or disable in your OpenStack services. However, there are some authoritative references we would like to recommend for further information:</para>
<itemizedlist><listitem>
<para><link xlink:href="http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml">National Security Agency, Suite B Cryptography</link></para>

13
doc/security-guide/ch018_case-studies-pkissl.xml
View File

@@ -1,13 +1,18 @@
<?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="ch018_case-studies-pkissl"><?dbhtml stop-chunking?>
<title>Case Studies: PKI and Certificate Management</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch018_case-studies-pkissl">
<?dbhtml stop-chunking?>
<title>Case studies: PKI and certificate management</title>
<para>In this case study we discuss how Alice and Bob would address deployment of PKI certification authorities (CA) and certificate management.</para>
<section xml:id="ch018_case-studies-pkissl-idp44432">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>Alice as a cloud architect within a government agency knows that her agency operates its own certification authority. Alice contacts the PKI office in her agency that manages her PKI and certificate issuance. Alice obtains certificates issued by this CA and configures the services within both the public and management security domains to use these certificates. Since Alice's OpenStack deployment exists entirely on a disconnected from the Internet network, she makes sure to remove all default CA bundles that contain external public CA providers to ensure the OpenStack services only accept client certificates issued by her agency's CA.</para>
</section>
<section xml:id="ch018_case-studies-pkissl-idp46480">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>Bob is architecting a public cloud and needs to ensure that the publicly facing OpenStack services are using certificates issued by a major public CA. Bob acquires certificates for his public OpenStack services and configures the services to use PKI and SSL and includes the public CAs in his trust bundle for the services. Additionally, Bob also wants to further isolate the internal communications amongst the services within the management security domain. Bob contacts the team within his organization that is responsible for managing his organizations PKI and issuance of certificates using their own internal CA. Bob obtains certificates issued by this internal CA and configures the services that communicate within the management security domain to use these certificates and configures the services to only accept client certificates issued by his internal CA.</para>
</section>
</chapter>

11
doc/security-guide/ch020_ssl-everywhere.xml
View File

@@ -1,6 +1,11 @@
<?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="ch020_ssl-everywhere"><?dbhtml stop-chunking?>
<title>SSL Proxies and HTTP Services</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch020_ssl-everywhere">
<?dbhtml stop-chunking?>
<title>SSL proxies and HTTP services</title>
<para>OpenStack endpoints are HTTP services providing APIs to both end-users on public networks and to other OpenStack services within the same deployment operating over the management network. It is highly recommended these requests, both those internal and external, operate over SSL.</para>
<para>In order for API requests to be encrypted by SSL it's necessary to position the API services behind a proxy that will establish and terminate SSL sessions. The following table offers a non-exhaustive list of software services that can proxy SSL traffic for API requests:</para>
<itemizedlist><listitem>
@@ -249,7 +254,7 @@ write-proxy = off</programlisting>
</section>
</section>
<section xml:id="ch020_ssl-everywhere-idp59152">
<title>HTTP Strict Transport Security</title>
<title>HTTP strict transport security</title>
<para>We recommend that all production deployments use HSTS. This header prevents browsers from making insecure connections after they have made a single secure one. If you have deployed your HTTP services on a public or an untrusted domain, HSTS is especially important. To enable HSTS, configure your web server to send a header like this with all requests:</para>
<screen><computeroutput>Strict-Transport-Security: max-age=31536000; includeSubDomains</computeroutput></screen>
<para>Start with a short timeout of 1 day during testing, and raise it to one year after testing has shown that you haven't introduced problems for users. Note that once this header is set to a large timeout, it is (by design) very difficult to disable.</para>

27
doc/security-guide/ch021_paste-and-middleware.xml
View File

@@ -1,13 +1,18 @@
<?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="ch021_paste-and-middleware"><?dbhtml stop-chunking?>
<title>API Endpoint Configuration Recommendations</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch021_paste-and-middleware">
<?dbhtml stop-chunking?>
<title>API endpoint configuration recommendations</title>
<para>This chapter provides recommendations for improving the security of both public and internal endpoints.</para>
<section xml:id="ch021_paste-and-middleware-idp38176">
<title>Internal API Communications</title>
<title>Internal API communications</title>
<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 Identity Service Catalog</title>
<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><prompt>$</prompt> <userinput>keystone endpoint-create \
@@ -18,11 +23,11 @@
--adminurl='https://management-ip:8776/v1/%(tenant_id)s'</userinput></screen>
</section>
<section xml:id="ch021_paste-and-middleware-idp43360">
<title>Configure Applications for Internal URLs</title>
<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 Identity Service catalog.</para>
<section xml:id="ch021_paste-and-middleware-idp45520">
<title>Configuration Example #1: Nova</title>
<title>Configuration example #1: nova</title>
<programlisting language="ini">[DEFAULT]
cinder_catalog_info='volume:cinder:internalURL'
glance_protocol='https'
@@ -32,33 +37,33 @@ s3_host='s3-host'
s3_use_ssl=True</programlisting>
</section>
<section xml:id="ch021_paste-and-middleware-idp47184">
<title>Configuration Example #2: Cinder</title>
<title>Configuration example #2: cinder</title>
<programlisting language="ini">glance_host='https://glance-server'</programlisting>
</section>
</section>
</section>
<section xml:id="ch021_paste-and-middleware-idp48768">
<title>Paste and Middleware</title>
<title>Paste and middleware</title>
<para>Most API endpoints and other HTTP services in OpenStack utilize the Python Paste Deploy library. This is important to understand from a security perspective as it allows for manipulation of the request filter pipeline through the application's configuration. Each element in this chain is referred to as <emphasis>middleware</emphasis>. Changing the order of filters in the pipeline or adding additional middleware may have unpredictable security impact.</para>
<para>It is not uncommon that implementors will choose to add additional middleware to extend OpenStack's base functionality. We recommend implementors make careful consideration of the potential exposure introduced by the addition of non-standard software components to their HTTP request pipeline.</para>
<para>Additional information on Paste Deploy may be found at
<link xlink:href="http://pythonpaste.org/deploy/">http://pythonpaste.org/deploy/</link>.</para>
</section>
<section xml:id="ch021_paste-and-middleware-idp52496">
<title>API Endpoint Process Isolation &amp; Policy</title>
<title>API endpoint process isolation and policy</title>
<para>API endpoint processes, especially those that reside within the public security domain should be isolated as much as possible. Where deployments allow, API endpoints should be deployed on separate hosts for increased isolation.</para>
<section xml:id="ch021_paste-and-middleware-idp53840">
<title>Namespaces</title>
<para>Many operating systems now provide compartmentalization support. Linux supports namespaces to assign processes into independent domains. System compartmentalization is covered in more detail in other parts of the guide.</para>
</section>
<section xml:id="ch021_paste-and-middleware-idp55232">
<title>Network Policy</title>
<title>Network policy</title>
<para>API endpoints typically bridge multiple security domains, as such particular attention should be paid to the compartmentalization of the API processes. See the <emphasis>Security Domain Bridging</emphasis> section for additional information in this area.</para>
<para>With careful modeling, network ACLs and IDS technologies can be use to enforce explicit point to point communication between network services. As critical cross domain service, this type of explicit enforcement works well for OpenStack's message queue service.</para>
<para>Policy enforcement can be implemented through the configuration of services, host-based firewalls (such as IPTables), local policy (SELinux or AppArmor), and optionally enforced through global network policy.</para>
</section>
<section xml:id="ch021_paste-and-middleware-idp58704">
<title>Mandatory Access Controls</title>
<title>Mandatory access controls</title>
<para>API endpoint processes should be isolated from each other and other processes on a machine. The configuration for those processes should be restricted to those processes not only by Discretionary Access Controls, but through Mandatory Access Controls. The goal of these enhanced access control is to aid in the containment and escalation of API endpoint security breaches. With mandatory access controls, such breaches will severely limit access to resources and provide earlier alerting on such events.</para>
</section>
</section>

49
doc/security-guide/ch022_case-studies-api-endpoints.xml
View File

@@ -1,13 +1,50 @@
<?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="ch022_case-studies-api-endpoints"><?dbhtml stop-chunking?>
<title>Case Studies: API Endpoints</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch022_case-studies-api-endpoints">
<?dbhtml stop-chunking?>
<title>Case studies: API endpoints</title>
<para>In this case study we discuss how Alice and Bob would address endpoint configuration to secure their private and public clouds. Alice's cloud is not publicly accessible, but she is still concerned about securing the endpoints against improper use. Bob's cloud, being public, must take measures to reduce the risk of attacks by external adversaries.</para>
<section xml:id="ch022_case-studies-api-endpoints-idp3824">
<title>Alice's Private Cloud</title>
<para>Alice's organization requires that the security architecture protect the access to the public and private endpoints, so she elects to use the Apache SSL proxy on both public and internal services. Alice's organization has implemented its own certificate authority. Alice contacts the PKI office in her agency that manages her PKI and certificate issuance. Alice obtains certificates issued by this CA and configures the services within both the public and management security domains to use these certificates. Since Alice's OpenStack deployment exists entirely on a disconnected from the Internet network, she makes sure to remove all default CA bundles that contain external public CA providers to ensure the OpenStack services only accept client certificates issued by her agency's CA. Alice has registered all of the services in the Keystone Services Catalog, using the internal URLs for access by internal services. She has installed host-based intrusion detection on all of the API endpoints.</para>
<title>Alice's private cloud</title>
<para>
Alice's organization requires that the security architecture
protect the access to the public and private endpoints, so she
elects to use the Apache SSL proxy on both public and internal
services. Alice's organization has implemented its own
certificate authority. Alice contacts the PKI office in her
agency that manages her PKI and certificate issuance. Alice
obtains certificates issued by this CA and configures the
services within both the public and management security
domains to use these certificates. Since Alice's OpenStack
deployment exists entirely on a disconnected from the Internet
network, she makes sure to remove all default CA bundles that
contain external public CA providers to ensure the OpenStack
services only accept client certificates issued by her
agency's CA. Alice has registered all of the services in the
Identity service's catalog, using the internal URLs for access
by internal services. She has installed host-based intrusion
detection on all of the API endpoints.
</para>
</section>
<section xml:id="ch022_case-studies-api-endpoints-idp6592">
<title>Bob's Public Cloud</title>
<para>Bob must also protect the access to the public and private endpoints, so he elects to use the Apache SSL proxy on both public and internal services. On the public services, he has configured the certificate key files with certificates signed by a well-known Certificate Authority. He has used his organization's self-signed CA to sign certificates in the internal services on the Management network. Bob has registered his services in the Keystone Services Catalog, using the internal URLs for access by internal services. Bob's public cloud runs services on SELinux, which he has configured with a mandatory access control policy to reduce the impact of any publicly accessible services that may be compromised. He has also configured the endpoints with a host-based IDS.</para>
<title>Bob's public cloud</title>
<para>
Bob must also protect the access to the public and private
endpoints, so he elects to use the Apache SSL proxy on both
public and internal services. On the public services, he has
configured the certificate key files with certificates signed
by a well-known Certificate Authority. He has used his
organization's self-signed CA to sign certificates in the
internal services on the Management network. Bob has
registered his services in the Identity service's catalog,
using the internal URLs for access by internal services. Bob's
public cloud runs services on SELinux, which he has configured
with a mandatory access control policy to reduce the impact of
any publicly accessible services that may be compromised. He
has also configured the endpoints with a host-based IDS.
</para>
</section>
</chapter>

38
doc/security-guide/ch024_authentication.xml
View File

@@ -6,7 +6,7 @@
xml:id="ch024_authentication">
<?dbhtml stop-chunking?>
<title>Identity</title>
<para>The OpenStack Identity Service (Keystone) supports multiple
<para>The OpenStack Identity service (keystone) supports multiple
methods of authentication, including username &amp; password,
LDAP, and external authentication methods. Upon successful
authentication, The Identity Service provides the user with an
@@ -18,7 +18,7 @@
<section xml:id="ch024_authentication-idp195568">
<title>Authentication</title>
<section xml:id="ch024_authentication-idp196256">
<title>Invalid Login Attempts</title>
<title>Invalid login attempts</title>
<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
@@ -43,7 +43,7 @@
credit card providers for fraud detection and alert.</para>
</section>
<section xml:id="ch024_authentication-idp241008">
<title>Multi-factor Authentication</title>
<title>Multi-factor authentication</title>
<para>Employ multi-factor authentication for network access to
privileged user accounts. The Identity Service supports
external authentication services through the Apache web server
@@ -55,9 +55,9 @@
</section>
</section>
<section xml:id="ch024_authentication-idp243184">
<title>Authentication Methods</title>
<title>Authentication methods</title>
<section xml:id="ch024_authentication-idp243824">
<title>Internally Implemented Authentication Methods</title>
<title>Internally implemented authentication methods</title>
<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
@@ -68,8 +68,8 @@
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>
policies should consider using Identity
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>
@@ -109,7 +109,7 @@
</note>
</section>
<section xml:id="ch024_authentication-idp251520">
<title>External Authentication Methods</title>
<title>External authentication methods</title>
<para>Organizations may desire to implement external
authentication for compatibility with existing authentication
services or to enforce stronger authentication policy
@@ -154,7 +154,7 @@
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>
<title>Establish formal access control policies</title>
<para>Prior to configuring roles, groups, and users, document
your required access control policies for the OpenStack
installation. The policies should be consistent with any
@@ -168,7 +168,7 @@
policies.</para>
</section>
<section xml:id="ch024_authentication-idp261600">
<title>Service Authorization</title>
<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
@@ -215,7 +215,7 @@
components.</para>
</section>
<section xml:id="ch024_authentication-idp267040">
<title>Administrative Users</title>
<title>Administrative users</title>
<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
@@ -225,7 +225,7 @@
access to privileged accounts.</para>
</section>
<section xml:id="ch024_authentication-idp268960">
<title>End Users</title>
<title>End users</title>
<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
@@ -285,14 +285,14 @@
<title>Future</title>
<para>Domains are high-level containers for projects, users and
groups. As such, they can be used to centrally manage all
Keystone-based identity components. With the introduction of
account Domains, server, storage and other resources can now be
logically grouped into multiple Projects (previously called
Tenants) which can themselves be grouped under a master
keystone-based identity components. With the introduction of
account domains, server, storage and other resources can now be
logically grouped into multiple projects (previously called
tenants) which can themselves be grouped under a master
account-like container. In addition, multiple users can be
managed within an account Domain and assigned roles that vary
for each Project.</para>
<para>Keystone's V3 API supports multiple domains. Users of
managed within an account domain and assigned roles that vary
for each project.</para>
<para>The Identity V3 API supports multiple domains. Users of
different domains may be represented in different authentication
backends and even have different attributes that must be mapped
to a single set of roles and privileges, that are used in the

32
doc/security-guide/ch025_web-dashboard.xml
View File

@@ -12,7 +12,7 @@
uploading VM images, managing networks, setting up security groups, starting
instances, and accessing the instances via a console.</para>
<para>The dashboard is based on the Django web framework, therefore
secure deployment practices for Django apply directly to Horizon.
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
@@ -23,7 +23,7 @@
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>
<title>Basic web server configuration</title>
<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
@@ -65,7 +65,7 @@
configurations, including the configuration of HSTS.</para>
</section>
<section xml:id="ch025_web-dashboard-idp245456">
<title>Front end Caching</title>
<title>Front end caching</title>
<para>Since dashboard is rendering dynamic content passed directly
from OpenStack API requests, we do not recommend front end
caching layers such as varnish. In Django, static media is
@@ -73,7 +73,7 @@
web host caching.</para>
</section>
<section xml:id="ch025_web-dashboard-idp246880">
<title>Domain Names</title>
<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
@@ -108,7 +108,7 @@
on the same second-level domain.</para>
</section>
<section xml:id="ch025_web-dashboard-idp251760">
<title>Static Media</title>
<title>Static media</title>
<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.
@@ -131,23 +131,23 @@
machines.</para>
</section>
<section xml:id="ch025_web-dashboard-idp255696">
<title>Secret Key</title>
<title>Secret key</title>
<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
dashboard 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>
<para>Horizon's default session backend
<title>Session back-end</title>
<para>Horizon's default session back-end
(<emphasis>django.contrib.sessions.backends.signed_cookies</emphasis>)
stores user data in <emphasis>signed</emphasis> but
<emphasis>unencrypted </emphasis>cookies stored in the
browser. This approach allows the most simple session backend
scaling since each Horizon instance is stateless, but it comes
scaling since each dashboard instance is stateless, but it comes
at the cost of <emphasis>storing sensitive access tokens in the
client browser</emphasis> and transmitting them with every
request. This backend ensures that session data has not been
@@ -165,11 +165,11 @@
>Django session backend documentation</link>.</para>
</section>
<section xml:id="ch025_web-dashboard-idp262288">
<title>Allowed Hosts</title>
<title>Allowed hosts</title>
<para>Configure the ALLOWED_HOSTS setting with the domain or
domains where Horizon is available. Failure to configure this
domains where the dashboard is available. Failure to configure this
setting (especially if not following the recommendation above
regarding second level domains) opens Horizon to a number of
regarding second level domains) opens the dashboard to a number of
serious attacks. Wild card domains should be avoided.</para>
<para>For further details, see the <link
xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#allowed-hosts"
@@ -186,7 +186,7 @@
SESSION_COOKIE_SECURE = True</programlisting>
</section>
<section xml:id="ch025_web-dashboard-idp266976">
<title>Password Auto Complete</title>
<title>Password auto complete</title>
<para>We recommend that implementers do not change the default
password auto complete behavior. Users choose stronger passwords
in environments that allow them to use the secure browser
@@ -224,13 +224,13 @@ SESSION_COOKIE_SECURE = True</programlisting>
<section xml:id="ch025_web-dashboard-idp272832">
<title>Cross Origin Resource Sharing (CORS)</title>
<para>Configure your web server to send a restrictive CORS header
with each response, allowing only the Horizon domain and
with each response, allowing only the dashboard domain and
protocol:</para>
<programlisting>Access-Control-Allow-Origin: https://example.com/</programlisting>
<para>Never allow the wild card origin.</para>
</section>
<section xml:id="ch025_web-dashboard-idp275056">
<title>Horizon Image Upload</title>
<title>Horizon image upload</title>
<para>We recommend that implementers <link
xlink:href="http://docs.openstack.org/developer/horizon/topics/deployment.html#file-uploads"
>disable HORIZON_IMAGES_ALLOW_UPLOAD</link> unless they have

30
doc/security-guide/ch026_compute.xml
View File

@@ -1,9 +1,14 @@
<?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?>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="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 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>
<title>Virtual console selection</title>
<para>One decision a cloud architect will need to make regarding
Compute service configuration is whether to use <glossterm
baseform="Virtual Network Computing (VNC)">VNC</glossterm> or
@@ -16,7 +21,14 @@
<section xml:id="ch026_compute-idp48352">
<title>Capabilities</title>
<itemizedlist><listitem>
<para>The OpenStack Dashboard (Horizon) can provide a VNC console for instances directly on the web page using the HTML5 noVNC client. This requires the <systemitem class="service">nova-novncproxy</systemitem> service to bridge from the public network to the management network.</para>
<para>
The OpenStack dashboard (horizon) can provide a VNC
console for instances directly on the web page using the
HTML5 noVNC client. This requires the <systemitem
class="service">nova-novncproxy</systemitem> service to
bridge from the public network to the management
network.
</para>
</listitem>
<listitem>
<para>The <command>nova</command> command-line utility can
@@ -30,7 +42,7 @@
</itemizedlist>
</section>
<section xml:id="ch026_compute-idp51760">
<title>Security Considerations</title>
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The <systemitem class="service">nova-novncproxy</systemitem>and nova-xvpvncproxy services by default open public-facing ports that are token authenticated.</para>
</listitem>
@@ -50,7 +62,13 @@
<section xml:id="ch026_compute-idp57120">
<title>Capabilities</title>
<itemizedlist><listitem>
<para>SPICE is supported by the OpenStack Dashboard (Horizon) directly on the instance web page. This requires the nova-spicehtml5proxy service.</para>
<para>
SPICE is supported by the OpenStack dashboard
(horizon) directly on the instance web page. This
requires the <systemitem
class="service">nova-spicehtml5proxy</systemitem>
service.
</para>
</listitem>
<listitem>
<para>The nova command-line utility can return a URL for SPICE console for access by a SPICE-html client.</para>
@@ -65,7 +83,7 @@
</itemizedlist>
</section>
<section xml:id="ch026_compute-idp83168">
<title>Security Considerations</title>
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The nova-spicehtml5proxy service by default opens public-facing ports that are token authenticated.</para>
</listitem>

16
doc/security-guide/ch027_storage.xml
View File

@@ -6,7 +6,7 @@
xml:id="ch027_storage">
<?dbhtml stop-chunking?>
<title>Object Storage</title>
<para>OpenStack Object Storage (Swift) is a service that provides
<para>OpenStack Object Storage (swift) is a service that provides
storage and retrieval of data over HTTP. Objects (blobs of
data) are stored in an organizational hierarchy that offers
anonymous read-only access or ACL defined access based on the
@@ -99,7 +99,7 @@
<para>The following figure demonstrates one possible network
architecture.</para>
<figure>
<title>Object storage network architecture with a
<title>Object Storage network architecture with a
management node (OSAM)</title>
<mediaobject>
<imageobject role="html">
@@ -230,7 +230,7 @@
what type of access. ACLs are interpreted based on
what authentication system is in use. The two most
common types of authentication providers used are
Keystone and SWAuth. Custom authentication providers
keystone and SWAuth. Custom authentication providers
are also possible. Please see the Object Storage
Authentication section for more information.</para>
</section>
@@ -250,7 +250,7 @@
<section xml:id="ch027_storage-idpE12">
<title>Use SSL/TLS</title>
<para>The built-in or included web server that comes with
Swift supports SSL, but it does not support
OpenStack Object Storage supports SSL, but it does not support
transmission of the entire SSL certificate chain. This
causes issues when you use a third party trusted and
signed certificate, such as Verisign, for your cloud. The
@@ -326,7 +326,7 @@ Group swift</programlisting>
end-point client or cloud administrator credentials
and access the cloud data.</para>
<para>The authentication service you use, such as
Keystone or SWAuth, will determine how you configure a
keystone or SWAuth, will determine how you configure a
different URL in the responses to end-clients so they
use your load balancer instead of an individual Proxy
service node.</para>
@@ -346,14 +346,14 @@ Group swift</programlisting>
<title>Keystone</title>
<para>Keystone is the commonly used Identity provider in
OpenStack. It may also be used for authentication in
Object Storage. Coverage of securing Keystone is
Object Storage. Coverage of securing keystone is
already provided in <xref
linkend="ch024_authentication"/>.</para>
</section>
<section xml:id="ch027_storage-idpH123">
<title>SWAuth</title>
<para>SWAuth is another alternative to Keystone. In
contrast to Keystone it stores the user accounts,
<para>SWAuth is another alternative to keystone. In
contrast to keystone it stores the user accounts,
credentials, and metadata in object storage itself.
More information can be found on the SWAuth website at
<link xlink:href="http://gholt.github.io/swauth/"

47
doc/security-guide/ch028_case-studies-identity-management.xml
View File

@@ -1,15 +1,46 @@
<?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="ch028_case-studies-identity-management"><?dbhtml stop-chunking?>
<title>Case Studies: Identity Management</title>
<para>In this case study we discuss how Alice and Bob would address configuration of OpenStack core services. These include the Keystone Identity service, Dashboard, and Compute services. Alice will be concerned with integration into the existing government directory services, while Bob will need to provide access to the public.</para>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch028_case-studies-identity-management">
<?dbhtml stop-chunking?>
<title>Case studies: Identity management</title>
<para>
In this case study we discuss how Alice and Bob would address
configuration of OpenStack core services. These include the
Identity service, dashboard, and Compute services. Alice will be
concerned with integration into the existing government
directory services, while Bob will need to provide access to the
public.
</para>
<section xml:id="ch028_case-studies-identity-management-idp87424">
<title>Alice's Private Cloud</title>
<para>Alice's enterprise has a well-established directory service with two-factor authentication for all users. She configures Keystone to support an external authentication service supporting authentication with government-issued access cards. She also uses an external LDAP server to provide role information for the users that is integrated with the access control policy. Due to FedRAMP compliance requirements, Alice implements two-factor authentication on the Management network for all administrator access.</para>
<para>Alice also deploys the Dashboard to manage many aspects of the cloud. She deploys the Dashboard with HSTS to ensure that only HTTPS is used. The Dashboard resides within an internal subdomain of the private network domain name system.</para>
<para>Alice decides to use SPICE instead of VNC for the virtual console. She wants to take advantage of the emerging capabilities in SPICE.</para>
<title>Alice's private cloud</title>
<para>
Alice's enterprise has a well-established directory service
with two-factor authentication for all users. She configures
the Identity service to support an external authentication
service supporting authentication with government-issued
access cards. She also uses an external LDAP server to provide
role information for the users that is integrated with the
access control policy. Due to FedRAMP compliance requirements,
Alice implements two-factor authentication on the management
network for all administrator access.
</para>
<para>
Alice also deploys the dashboard to manage many aspects of the
cloud. She deploys the dashboard with HSTS to ensure that only
HTTPS is used. The dashboard resides within an internal
subdomain of the private network domain name system.
</para>
<para>
Alice decides to use SPICE instead of VNC for the virtual
console. She wants to take advantage of the emerging
capabilities in SPICE.
</para>
</section>
<section xml:id="ch028_case-studies-identity-management-idp131936">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>Bob must support authentication by the general public, so he elects to use provide for username / password authentication. He has concerns about brute force attacks attempting to crack user passwords, so he also uses an external authentication extension that throttles the number of failed login attempts. Bob's Management network is separate from the other networks within his cloud, but can be reached from his corporate network via ssh. As recommended earlier, Bob requires administrators to use two-factor authentication on the Management network to reduce the risk from compromised administrator passwords.</para>
<para>Bob also deploys the Dashboard to manage many aspects of the cloud. He deploys the Dashboard with HSTS to ensure that only HTTPS is used. He has ensured that the Dashboard is deployed on a second-level domain due to the limitations of the same-origin policy. He also disables HORIZON_IMAGES_ALLOW_UPLOAD to prevent resource exhaustion.</para>
<para>Bob decides to use VNC for his virtual console for its maturity and security features.</para>

9
doc/security-guide/ch030_state-of-networking.xml
View File

@@ -1,6 +1,11 @@
<?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="ch030_state-of-networking"><?dbhtml stop-chunking?>
<title>State of Networking</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch030_state-of-networking">
<?dbhtml stop-chunking?>
<title>State of networking</title>
<para>OpenStack Networking in the Grizzly release enables the end-user or tenant to define, utilize, and consume networking resources in new ways that had not been possible in previous OpenStack Networking releases. OpenStack Networking provides a tenant-facing API for defining network connectivity and IP addressing for instances in the cloud in addition to orchestrating the network configuration. With the transition to an API-centric networking service, cloud architects and administrators should take into consideration best practices to secure physical and virtual network infrastructure and services.</para>
<para>OpenStack Networking was designed with a plug-in architecture that provides extensibility of the API via open source community or third-party services. As you evaluate your architectural design requirements, it is important to determine what features are available in OpenStack Networking core services, any additional services that are provided by third-party products, and what supplemental services are required to be implemented in the physical infrastructure.</para>
<para>This section is a high-level overview of what processes and best practices should be considered when implementing OpenStack Networking. We will talk about the current state of services that are available, what future services will be implemented, and the current limitations in this project.</para>

13
doc/security-guide/ch031_neutron-architecture.xml
View File

@@ -1,6 +1,11 @@
<?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="ch031_neutron-architecture"><?dbhtml stop-chunking?>
<title>Networking Architecture</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch031_neutron-architecture">
<?dbhtml stop-chunking?>
<title>Networking architecture</title>
<para>OpenStack Networking is a standalone service that often involves deploying several processes across a number of nodes. These processes interact with each other and with other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plug-ins for additional processing.</para>
<para>OpenStack Networking components encompasses the following elements:</para>
<itemizedlist><listitem>
@@ -28,10 +33,10 @@
</imageobject>
</inlinemediaobject></para>
<section xml:id="ch031_neutron-architecture-idp61360">
<title>OS Networking Service placement on Physical Servers</title>
<title>OpenStack Networking service placement on physical servers</title>
<para>In this guide, we focus primarily on a standard architecture that includes a <emphasis>cloud controller</emphasis> host, a <emphasis>network</emphasis> host, and a set of <emphasis>compute</emphasis> hypervisors for running VMs.</para>
<section xml:id="ch031_neutron-architecture-idp63888">
<title>Network Connectivity of Physical Servers</title>
<title>Network connectivity of physical servers</title>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="364" contentwidth="536" fileref="static/1aa-network-domains-diagram.png" format="PNG" scalefit="1"/>
</imageobject>

31
doc/security-guide/ch032_networking-best-practices.xml
View File

@@ -1,10 +1,15 @@
<?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="ch032_networking-best-practices"><?dbhtml stop-chunking?>
<title>Networking Services</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch032_networking-best-practices">
<?dbhtml stop-chunking?>
<title>Networking services</title>
<para>In the initial architectural phases of designing your OpenStack Network infrastructure it is important to ensure appropriate expertise is available to assist with the design of the physical networking infrastructure, to identify proper security controls and auditing mechanisms.</para>
<para>OpenStack Networking adds a layer of virtualized network services - giving tenants the capability to architect their own, virtual networks. These virtualized services are not as currently as mature as their traditional networking counterparts. It is important to be aware of the current state of these virtualized services and what controls may need to be implemented at the virtualized and traditional network boundary.</para>
<section xml:id="ch032_networking-best-practices-idp45376">
<title>L2 Isolation using VLANs and Tunneling</title>
<title>L2 isolation using VLANs and tunneling</title>
<para>OpenStack networking can employ two different mechanisms for traffic segregation on a per tenant/network combination: VLANs (IEEE 802.1Q tagging) or L2 tunnels using GRE encapsulation. Which method you choose for traffic segregation and isolation is determined by the scope and scale of your OpenStack deployment.</para>
<section xml:id="ch032_networking-best-practices-idp46832">
<title>VLANs</title>
@@ -15,24 +20,24 @@
</note>
</section>
<section xml:id="ch032_networking-best-practices-idp50512">
<title>L2 Tunneling</title>
<title>L2 tunneling</title>
<para>Network tunneling encapsulates each tenant/network combination with a unique "tunnel-id" that is used to identify the network traffic belonging to that combination. The tenant's L2 network connectivity is independent of physical locality or underlying network design. By encapsulating traffic inside IP packets, that traffic can cross Layer-3 boundaries, removing the need for preconfigured VLANs and VLAN trunking. Tunneling adds a layer of obfuscation to network data traffic, reducing the visibility of individual tenant traffic from a monitoring point of view.</para>
<para>OpenStack Networking currently only supports GRE encapsulation with planned future support of VXLAN due in the Havana release.</para>
<para>The choice of technology to provide L2 isolation is dependent upon the scope and size of tenant networks that will be created in your deployment. If your environment has limited VLAN ID availability or will have a large number of L2 networks, it is our recommendation that you utilize tunneling.</para>
</section>
</section>
<section xml:id="ch032_networking-best-practices-idp54784">
<title>Network Services</title>
<title>Network services</title>
<para>The choice of tenant network isolation affects how the network security and control boundary is implemented for tenant services. The following additional network services are either available or currently under development to enhance the security posture of the OpenStack network architecture.</para>
<section xml:id="ch032_networking-best-practices-idp56112">
<title>Access Control Lists</title>
<title>Access control lists</title>
<para>OpenStack Compute supports tenant network traffic access controls directly when deployed with the legacy nova-network service, or may defer access control to the OpenStack Networking service.</para>
<para>Note, legacy nova-network security groups are applied to all virtual interface ports on an instance using IPTables.</para>
<para>Security groups allow administrators and tenants the ability to specify the type of traffic, and direction (ingress/egress) that is allowed to pass through a virtual interface port. Security groups rules are stateful L2-L4 traffic filters.</para>
<para>It is our recommendation that you enable security groups via OpenStack Networking.</para>
</section>
<section xml:id="ch032_networking-best-practices-idp59008">
<title>L3 Routing and NAT</title>
<title>L3 routing and NAT</title>
<para>OpenStack Networking routers can connect multiple L2 networks, and can also provide a <emphasis>gateway</emphasis> that connects one or more private L2 networks to a shared <emphasis>external</emphasis> network, such as a public network for access to the Internet.</para>
<para>The L3 router provides basic Network Address Translation (NAT) capabilities on <emphasis>gateway</emphasis> ports that uplink the router to external networks. This router SNATs (Static NAT) all traffic by default, and supports floating IPs, which creates a static one-to-one mapping from a public IP on the external network to a private IP on one of the other subnets attached to the router.</para>
<para>It is our recommendation to leverage per tenant L3 routing and Floating IPs for more granular connectivity of tenant VMs.</para>
@@ -56,7 +61,7 @@
<para>Tenant traffic port mirroring or Network Flow monitoring is currently not an exposed feature in OpenStack Networking. There are third-party plug-in extensions that do provide Port Mirroring on a per port/network/tenant basis. If Open vSwitch is used on the networking hypervisor, it is possible to enable sFlow and port mirroring, however it will require some operational effort to implement.</para>
</section>
<section xml:id="ch032_networking-best-practices-idp69408">
<title>Load Balancing</title>
<title>Load balancing</title>
<para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.</para>
</section>
<section xml:id="ch032_networking-best-practices-idp71664">
@@ -66,18 +71,18 @@
</section>
</section>
<section xml:id="ch032_networking-best-practices-idp74544">
<title>Network Services Extensions</title>
<title>Network services extensions</title>
<para>Here is a list of known plug-ins provided by the open source community or by SDN companies that work with OpenStack Networking:</para>
<para>Big Switch Controller plug-in, Brocade Neutron plug-in
Brocade Neutron plug-in, Cisco UCS/Nexus plug-in, Cloudbase
<para>Big Switch Controller plug-in, Brocade neutron plug-in
Brocade neutron plug-in, Cisco UCS/Nexus plug-in, Cloudbase
Hyper-V plug-in, Extreme Networks plug-in, Juniper Networks
Neutron plug-in, Linux Bridge plug-in, Mellanox Neutron plug-in,
neutron plug-in, Linux Bridge plug-in, Mellanox neutron plug-in,
MidoNet plug-in, NEC OpenFlow plug-in, Open vSwitch plug-in,
PLUMgrid plug-in, Ruijie Networks plug-in, Ryu OpenFlow
Controller plug-in, VMware NSX plug-in.</para>
</section>
<section xml:id="ch032_networking-best-practices-idp78032">
<title>Networking Services Limitations</title>
<title>Networking services limitations</title>
<para>OpenStack Networking has the following known limitations:</para>
<itemizedlist><listitem>
<para><emphasis role="bold">Overlapping IP addresses</emphasis> &#x2014; If nodes that run either <literal>neutron-l3-agent</literal> or <literal>neutron-dhcp-agent</literal> use overlapping IP addresses, those nodes must use Linux network namespaces. By default, the DHCP and L3 agents use Linux network namespaces. However, if the host does not support these namespaces, run the DHCP and L3 agents on different hosts.</para>

13
doc/security-guide/ch033_securing-neutron-services.xml
View File

@@ -1,6 +1,11 @@
<?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="ch033_securing-neutron-services"><?dbhtml stop-chunking?>
<title>Securing OpenStack Networking Services</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch033_securing-neutron-services">
<?dbhtml stop-chunking?>
<title>Securing OpenStack Networking services</title>
<para>In order to secure OpenStack Networking, an understanding of the workflow process for tenant instance creation needs to be mapped to security domains.</para>
<para>There are four main services that interact with OpenStack Networking. In a typical OpenStack deployment these services map to the following security domains:</para>
<itemizedlist><listitem>
@@ -29,9 +34,9 @@
</inlinemediaobject></para>
<para>In order to isolate sensitive data communication between the OpenStack Networking services and other OpenStack core services, we strongly recommend that these communication channels be configured to only allow communications over an isolated management network.</para>
<section xml:id="ch033_securing-neutron-services-idp55312">
<title>OpenStack Networking Service Configuration</title>
<title>OpenStack Networking service configuration</title>
<section xml:id="ch033_securing-neutron-services-idp56016">
<title>Restrict Bind Address of the API server: neutron-server</title>
<title>Restrict bind address of the API server: neutron-server</title>
<para>To restrict the interface or IP address on which the OpenStack Networking API service binds a network socket for incoming client connections, specify the bind_host and bind_port in the neutron.conf file as shown:</para>
<programlisting language="ini">
# Address to bind the API server

15
doc/security-guide/ch034_tenant-secure-networking-best-practices.xml
View File

@@ -1,13 +1,18 @@
<?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="ch034_tenant-secure-networking-best-practices"><?dbhtml stop-chunking?>
<title>Networking Services Security Best Practices</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch034_tenant-secure-networking-best-practices">
<?dbhtml stop-chunking?>
<title>Networking services security best practices</title>
<para>This section discusses OpenStack Networking configuration best practices as they apply to tenant network security within your OpenStack deployment.</para>
<section xml:id="ch034_tenant-secure-networking-best-practices-idp44592">
<title>Tenant Network Services Workflow</title>
<title>Tenant network services workflow</title>
<para>OpenStack Networking provides users real self services of network resources and configurations. It is important that Cloud Architects and Operators evaluate their design use cases in providing users the ability to create, update, and destroy available network resources.</para>
</section>
<section xml:id="ch034_tenant-secure-networking-best-practices-idp46080">
<title>Networking Resource Policy Engine</title>
<title>Networking resource policy engine</title>
<para>A policy engine and its configuration file,
<filename>policy.json</filename>, within OpenStack Networking
provides a method to provide finer grained authorization of
@@ -26,7 +31,7 @@
<para>If your deployment of OpenStack provides multiple external access points into different security domains it is important that you limit the tenant's ability to attach multiple vNICs to multiple external access points -- this would bridge these security domains and could lead to unforeseen security compromise. It is possible mitigate this risk by utilizing the host aggregates functionality provided by OpenStack Compute or through splitting the tenant VMs into multiple tenant projects with different virtual network configurations.</para>
</section>
<section xml:id="ch034_tenant-secure-networking-best-practices-idp51440">
<title>Security Groups</title>
<title>Security groups</title>
<para>The OpenStack Networking Service provides security group functionality using a mechanism that is more flexible and powerful than the security group capabilities built into OpenStack Compute. Thus, when using OpenStack Networking, <emphasis>nova.conf</emphasis> should always disable built-in security groups and proxy all security group calls to the OpenStack Networking API. Failure to do so will result in conflicting security policies being simultaneously applied by both services. To proxy security groups to OpenStack Networking, use the following configuration values:</para>
<itemizedlist><listitem>
<para>firewall_driver : must be set to 'nova.virt.firewall.NoopFirewallDriver' so that <systemitem class="service">nova-compute</systemitem> does not perform iptables-based filtering itself.</para>

15
doc/security-guide/ch035_case-studies-networking.xml
View File

@@ -1,9 +1,14 @@
<?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="ch035_case-studies-networking"><?dbhtml stop-chunking?>
<title>Case Studies: Networking</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch035_case-studies-networking">
<?dbhtml stop-chunking?>
<title>Case studies: Networking</title>
<para>In this case study we discuss how Alice and Bob would address providing networking services to the user.</para>
<section xml:id="ch035_case-studies-networking-idp37440">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>A key objective of Alice's cloud is to integrate with the
existing auth services and security resources. The key design
parameters for this private cloud are a limited scope of
@@ -14,14 +19,14 @@
be modified to restrict creation and changes to network
resources. In this environment, Alice might want to leverage
nova-network in the application of security group polices on a
per instance basis vs. Neutron's application of security group
per instance basis vs. neutron's application of security group
polices on a per port basis. L2 isolation in this environment
would leverage VLAN tagging. The use of VLAN tags will allow
great visibility of tenant traffic by leveraging existing
features and tools of the physical infrastructure.</para>
</section>
<section xml:id="ch035_case-studies-networking-idp40064">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>A major business driver for Bob is to provide an advanced
networking services to his customers. Bob's customers would like
to deploy multi-tiered application stacks. This multi-tiered

2
doc/security-guide/ch037_risks.xml
View File

@@ -5,7 +5,7 @@
version="5.0"
xml:id="ch037_risks">
<?dbhtml stop-chunking?>
<title>Message Queuing Architecture</title>
<title>Message queuing architecture</title>
<para>Message queuing services facilitate inter-process
communication in OpenStack. OpenStack supports these message
queuing service back ends:</para>

31
doc/security-guide/ch038_transport-security.xml
View File

@@ -1,13 +1,18 @@
<?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="ch038_transport-security"><?dbhtml stop-chunking?>
<title>Messaging Security</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch038_transport-security">
<?dbhtml stop-chunking?>
<title>Messaging security</title>
<para>This chapter discusses security hardening approaches for the three most common message queuing solutions use in OpenStack: RabbitMQ, Qpid, and ZeroMQ.</para>
<section xml:id="ch038_transport-security-idp37712">
<title>Messaging Transport Security</title>
<title>Messaging transport security</title>
<para>AMQP based solutions (Qpid and RabbitMQ) support transport-level security using SSL. ZeroMQ messaging does not natively support SSL, but transport-level security is possible using labelled IPSec or CIPSO network labels.</para>
<para>We highly recommend enabling transport-level cryptography for your message queue. Using SSL for the messaging client connections provides protection of the communications from tampering and eavesdropping in-transit to the messaging server. Below is guidance on how SSL is typically configured for the two popular messaging servers Qpid and RabbitMQ. When configuring the trusted certificate authority (CA) bundle that your messaging server uses to verify client connections, it is recommended that this be limited to only the CA used for your nodes, preferably an internally managed CA. The bundle of trusted CAs will determine which client certificates will be authorized and pass the client-server verification step of the setting up the SSL connection. Note, when installing the certificate and key files, ensure that the file permissions are restricted, for example chmod 0600, and the ownership is restricted to the messaging server daemon user to prevent unauthorized access by other processes and users on the messaging server.</para>
<section xml:id="ch038_transport-security-idp40512">
<title>RabbitMQ Server SSL Configuration</title>
<title>RabbitMQ server SSL configuration</title>
<para>The following lines should be added to the system-wide
RabbitMQ configuration file, typically
<filename>/etc/rabbitmq/rabbitmq.config</filename>:
@@ -40,7 +45,7 @@
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp46320">
<title>Qpid Server SSL Configuration</title>
<title>Qpid server SSL configuration</title>
<para>The Apache Foundation has a messaging security guide for Qpid. See:</para>
<itemizedlist><listitem>
<para><link xlink:href="http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-Encryption_using_SSL">Apache Qpid SSL</link></para>
@@ -49,7 +54,7 @@
</section>
</section>
<section xml:id="ch038_transport-security-idp48960">
<title>Queue Authentication and Access Control</title>
<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>
@@ -58,7 +63,7 @@
servers use. Qpid uses Mozilla's NSS library, whereas RabbitMQ
uses Erlang's SSL module which uses OpenSSL.</para>
<section xml:id="ch038_transport-security-idp52640">
<title>Authentication Configuration Example - RabbitMQ</title>
<title>Authentication configuration example: RabbitMQ</title>
<para>On the RabbitMQ server, delete the default
<literal>guest</literal> user:</para>
<screen><prompt>#</prompt> <userinput>rabbitmqctl delete_user quest</userinput></screen>
@@ -83,7 +88,7 @@
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp59648">
<title>OpenStack Service Configuration - RabbitMQ</title>
<title>OpenStack service configuration: RabbitMQ</title>
<programlisting language="ini">[DEFAULT]
rpc_backend=nova.openstack.common.rpc.impl_kombu
rabbit_use_ssl=True
@@ -96,7 +101,7 @@ kombu_ssl_certfile=/etc/ssl/node-cert.pem
kombu_ssl_ca_certs=/etc/ssl/cacert.pem</programlisting>
</section>
<section xml:id="ch038_transport-security-idp62112">
<title>Authentication Configuration Example - Qpid</title>
<title>Authentication configuration example: Qpid</title>
<para>For configuration information see:</para>
<itemizedlist><listitem>
<para><link xlink:href="http://qpid.apache.org/books/0.22/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-User_Authentication">Apache Qpid Authentication</link></para>
@@ -107,7 +112,7 @@ kombu_ssl_ca_certs=/etc/ssl/cacert.pem</programlisting>
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp65584">
<title>OpenStack Service Configuration - Qpid</title>
<title>OpenStack service configuration: Qpid</title>
<programlisting language="ini">
[DEFAULT]
rpc_backend=nova.openstack.common.rpc.impl_qpid
@@ -121,7 +126,7 @@ qpid_password=password</programlisting>
</section>
</section>
<section xml:id="ch038_transport-security-idp68512">
<title>Message Queue Process Isolation &amp; Policy</title>
<title>Message queue process isolation and policy</title>
<para>Each project provides a number of services which send and consume messages. Each binary which sends a message is expected to consume messages, if only replies, from the queue.</para>
<para>Message queue service processes should be isolated from each other and other processes on a machine.</para>
<section xml:id="ch038_transport-security-idp70304">
@@ -130,12 +135,12 @@ qpid_password=password</programlisting>
<para>When using ZeroMQ messaging, each host must run at least one ZeroMQ message receiver to receive messages from the network and forward messages to local processes via IPC. It is possible and advisable to run an independent message receiver per project within an IPC namespace, along with other services within the same project.</para>
</section>
<section xml:id="ch038_transport-security-idp72736">
<title>Network Policy</title>
<title>Network policy</title>
<para>Queue servers should only accept connections from the management network. This applies to all implementations. This should be implemented through configuration of services and optionally enforced through global network policy.</para>
<para>When using ZeroMQ messaging, each project should run a separate ZeroMQ receiver process on a port dedicated to services belonging to that project. This is equivalent to the AMQP concept of control exchanges.</para>
</section>
<section xml:id="ch038_transport-security-idp74736">
<title>Mandatory Access Controls</title>
<title>Mandatory access controls</title>
<para>The configuration for these processes should be restricted to those processes, not only by Directory Access Controls, but through Mandatory Access Controls. The goal of such restrictions is to prevent isolation from other processes running on the same machine(s).</para>
</section>
</section>

13
doc/security-guide/ch039_case-studies-messaging.xml
View File

@@ -1,13 +1,18 @@
<?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="ch039_case-studies-messaging"><?dbhtml stop-chunking?>
<title>Case Studies: Messaging</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch039_case-studies-messaging">
<?dbhtml stop-chunking?>
<title>Case studies: messaging</title>
<para>The message queue is a critical piece of infrastructure that supports a number of OpenStack services but is most strongly associated with the Compute service. Due to the nature of the message queue service, Alice and Bob have similar security concerns. One of the larger concerns that remains is that many systems have access to this queue and there is no way for a consumer of the queue messages to verify which host or service placed the messages on the queue. An attacker who is able to successfully place messages on the queue is able to create and delete VM instances, attach the block storage of any tenant and a myriad of other malicious actions. There are a number of solutions on the horizon to fix this, with several proposals for message signing and encryption making their way through the OpenStack development process.</para>
<section xml:id="ch039_case-studies-messaging-idp38416">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>In this case Alice's controls mimic those Bob has deployed for the public cloud.</para>
</section>
<section xml:id="ch039_case-studies-messaging-idp39920">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>Bob assumes that at some point infrastructure or networks underpinning the Compute service may become compromised. Due to this, he recognizes the importance of locking down access to the message queue. To do this Bob deploys his RabbitMQ servers with SSL and X.509 client auth for access control. This in turn limits the capabilities of an attacker who has compromised a system that does not have queue access.</para>
<para>Additionally, Bob adds strong network ACL rulesets to enforce which endpoints can communicate with the message servers. This second control provides some additional assurance should the other protections fail.</para>
</section>

10
doc/security-guide/ch041_database-backend-considerations.xml
View File

@@ -1,11 +1,15 @@
<?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="ch041_database-backend-considerations"><?dbhtml stop-chunking?>
<title>Database Backend Considerations</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0" xml:id="ch041_database-backend-considerations">
<?dbhtml stop-chunking?>
<title>Database back-end considerations</title>
<para>The choice of database server is an important consideration in the security of an OpenStack deployment. While security considerations are not the only basis on which a database server must be chosen, security considerations are the only ones within the scope of this book. In practice, OpenStack only supports two database types: PostgreSQL and MySQL.</para>
<para>PostgreSQL has a number of desirable security features such as Kerberos authentication, object-level security, and encryption support. The PostgreSQL community has done well to provide solid guidance, documentation, and tooling to promote positive security practices.</para>
<para>MySQL has a large community, widespread adoption, and provides high availability options. MySQL also has the ability to provide enhanced client authentication by way of plug-in authentication mechanisms. Forked distributions in the MySQL community provide many options for consideration. It is important to choose a specific implementation of MySQL based on a thorough evaluation of the security posture and the level of support provided for the given distribution.</para>
<section xml:id="ch041_database-backend-considerations-idp39568">
<title>Security References for Database Backends</title>
<title>Security references for database back-ends</title>
<para>Those deploying MySQL or PostgreSQL are advised to refer to existing security guidance. Some references are listed below:</para>
<para>MySQL:</para>
<itemizedlist><listitem>

40
doc/security-guide/ch042_database-overview.xml
View File

@@ -1,13 +1,18 @@
<?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="ch042_database-overview"><?dbhtml stop-chunking?>
<title>Database Access Control</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch042_database-overview">
<?dbhtml stop-chunking?>
<title>Database access control</title>
<para>Each of the core OpenStack services (Compute, Identity, Networking, Block Storage) store state and configuration information in databases. In this chapter, we discuss how databases are used currently in OpenStack. We also explore security concerns, and the security ramifications of database backend choices.</para>
<section xml:id="ch042_database-overview-idp44624">
<title>OpenStack Database Access Model</title>
<title>OpenStack database access model</title>
<para>All of the services within an OpenStack project access a single database. There are presently no reference policies for creating table or row based access restrictions to the database.</para>
<para>There are no general provisions for granular control of database operations in OpenStack. Access and privileges are granted simply based on whether a node has access to the database or not. In this scenario, nodes with access to the database may have full privileges to DROP, INSERT, or UPDATE functions.</para>
<section xml:id="ch042_database-overview-idp46912">
<title>Granular Access Control</title>
<title>Granular access control</title>
<para>By default, each of the OpenStack services and their processes access the database using a shared set of credentials. This makes auditing database operations and revoking access privileges from a service and its processes to the database particularly difficult.</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="283" contentwidth="355" fileref="static/databaseusername.png" format="PNG" scalefit="1"/>
@@ -18,7 +23,7 @@
</inlinemediaobject></para>
</section>
<section xml:id="ch042_database-overview-idp53264">
<title>Nova Conductor</title>
<title>Nova-conductor</title>
<para>The compute nodes are the least trusted of the services in OpenStack because they host tenant instances. The <systemitem class="service">nova-conductor</systemitem> service has been introduced to serve as a database proxy, acting as an intermediary between the compute nodes and the database. We discuss its ramifications later in this chapter.</para>
<para>We strongly recommend:</para>
<itemizedlist><listitem>
@@ -44,7 +49,7 @@
</section>
</section>
<section xml:id="ch042_database-overview-idp83456">
<title>Database Authentication and Access Control</title>
<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>
<section xml:id="ch042_database-overview-idp85888">
<title>Privileges</title>
@@ -53,13 +58,13 @@
</section>
</section>
<section xml:id="ch042_database-overview-idp88080">
<title>Require User Accounts to Require SSL Transport</title>
<title>Require user accounts to require SSL transport</title>
<section xml:id="ch042_database-overview-idp88784">
<title>Configuration Example #1: (MySQL)</title>
<title>Configuration example #1: (MySQL)</title>
<programlisting>GRANT ALL ON dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SSL;</programlisting>
</section>
<section xml:id="ch042_database-overview-idp90096">
<title>Configuration Example #2: (PostgreSQL)</title>
<title>Configuration example #2: (PostgreSQL)</title>
<para>In file pg_hba.conf:</para>
<programlisting>hostssl dbname compute01 hostname md5</programlisting>
<para>Note this command only adds the ability to communicate over SSL and is non-exclusive. Other access methods that may allow unencrypted transport should be disabled so that SSL is the sole access method.</para>
@@ -67,28 +72,28 @@
</section>
</section>
<section xml:id="ch042_database-overview-idp93120">
<title>Authentication with X.509 Certificates</title>
<title>Authentication with X.509 certificates</title>
<para>Security may be enhanced by requiring X.509 client certificates for authentication. Authenticating to the database in this manner provides greater identity assurance of the client making the connection to the database and ensures that the communications are encrypted.</para>
<section xml:id="ch042_database-overview-idp94704">
<title>Configuration Example #1: (MySQL)</title>
<title>Configuration example #1: (MySQL)</title>
<programlisting>GRANT ALL on dbname.* to 'compute01'@'hostname' IDENTIFIED BY 'password' REQUIRE SUBJECT
'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=compute01' AND ISSUER
'/C=XX/ST=YYY/L=ZZZZ/O=cloudycloud/CN=cloud-ca';</programlisting>
</section>
<section xml:id="ch042_database-overview-idp96192">
<title>Configuration Example #2: (PostgreSQL)</title>
<title>Configuration example #2: (PostgreSQL)</title>
<programlisting>hostssl dbname compute01 hostname cert</programlisting>
</section>
</section>
<section xml:id="ch042_database-overview-idp97536">
<title>OpenStack Service Database Configuration</title>
<title>OpenStack service database configuration</title>
<para>If your database server is configured to require X.509 certificates for authentication you will need to specify the appropriate SQLAlchemy query parameters for the database backend. These parameters specify the certificate, private key, and certificate authority information for use with the initial connection string.</para>
<para>Example of an <literal>:sql_connection</literal> string for X.509 certificate authentication to MySQL:</para>
<programlisting language="ini">sql_connection = mysql://compute01:password@localhost/nova?
charset=utf8&amp;ssl_ca=/etc/mysql/cacert.pem&amp;ssl_cert=/etc/mysql/server-cert.pem&amp;ssl_key=/etc/mysql/server-key.pem</programlisting>
</section>
<section xml:id="ch042_database-overview-idp100688">
<title>Nova Conductor</title>
<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 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>
@@ -101,7 +106,12 @@ charset=utf8&amp;ssl_ca=/etc/mysql/cacert.pem&amp;ssl_cert=/etc/mysql/server-cer
</inlinemediaobject></para>
<para>Unfortunately, this solution complicates the task of more fine-grained access control and the ability to audit data access. Because the <systemitem class="service">nova-conductor</systemitem> service receives requests over RPC, it highlights the importance of improving the security of messaging. Any node with access to the message queue may execute these methods provided by the <systemitem class="service">nova-conductor</systemitem> and effectively modifying the database.</para>
<para>Finally, it should be noted that as of the Grizzly release, gaps exist where <systemitem class="service">nova-conductor</systemitem> is not used throughout OpenStack Compute. Depending on one's configuration, the use of <systemitem class="service">nova-conductor</systemitem> may not allow deployers to avoid the necessity of providing database GRANTs to individual compute host systems.</para>
<para>Note, as <systemitem class="service">nova-conductor</systemitem> only applies to OpenStack Compute, direct database access from compute hosts may still be necessary for the operation of other OpenStack components such as Telemetry (Ceilometer), Networking, and Block Storage.</para>
<para>Note, as <systemitem
class="service">nova-conductor</systemitem> only applies to
OpenStack Compute, direct database access from compute hosts may
still be necessary for the operation of other OpenStack
components such as Telemetry (ceilometer), Networking, and Block
Storage.</para>
<para>Implementors should weigh the benefits and risks of both configurations before enabling or disabling the <systemitem class="service">nova-conductor</systemitem> service. We are not yet prepared to recommend the use of <systemitem class="service">nova-conductor</systemitem> in the Grizzly release. However, we do believe that this recommendation will change as additional features are added into OpenStack.</para>
<para>To disable the <systemitem class="service">nova-conductor</systemitem>, place the following into your <filename>nova.conf</filename> file (on your compute hosts):</para>
<programlisting language="ini">[conductor]

21
doc/security-guide/ch043_database-transport-security.xml
View File

@@ -1,32 +1,37 @@
<?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="ch043_database-transport-security"><?dbhtml stop-chunking?>
<title>Database Transport Security</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch043_database-transport-security">
<?dbhtml stop-chunking?>
<title>Database transport security</title>
<para>This chapter covers issues related to network communications to and from the database server. This includes IP address bindings and encrypting network traffic with SSL.</para>
<section xml:id="ch043_database-transport-security-idp38176">
<title>Database Server IP Address Binding</title>
<title>Database server IP address binding</title>
<para>To isolate sensitive database communications between the services and the database, we strongly recommend that the database server(s) be configured to only allow communications to and from the database over an isolated management network. This is achieved by restricting the interface or IP address on which the database server binds a network socket for incoming client connections.</para>
<section xml:id="ch043_database-transport-security-idp39696">
<title>Restricting Bind Address for MySQL</title>
<title>Restricting bind address for MySQL</title>
<para>In my.cnf:</para>
<programlisting>[mysqld]
...
bind-address &lt;ip address or hostname of management network interface&gt;</programlisting>
</section>
<section xml:id="ch043_database-transport-security-idp41568">
<title>Restricting Listen Address for PostgreSQL</title>
<title>Restricting listen address for PostgreSQL</title>
<para>In postgresql.conf:</para>
<programlisting>listen_addresses = &lt;ip address or hostname of management network interface&gt;</programlisting>
</section>
</section>
<section xml:id="ch043_database-transport-security-idp43520">
<title>Database Transport</title>
<title>Database transport</title>
<para>In addition to restricting database communications to the management network, we also strongly recommend that the cloud administrator configure their database backend to require SSL. Using SSL for the database client connections protects the communications from tampering and eavesdropping. As will be discussed in the next section, using SSL also provides the framework for doing database user authentication via X.509 certificates (commonly referred to as PKI). Below is guidance on how SSL is typically configured for the two popular database backends MySQL and PostgreSQL.</para>
<note>
<para>NOTE: When installing the certificate and key files, ensure that the file permissions are restricted, for example <literal>chmod 0600</literal>, and the ownership is restricted to the database daemon user to prevent unauthorized access by other processes and users on the database server.</para>
</note>
</section>
<section xml:id="ch043_database-transport-security-idp47184">
<title>MySQL SSL Configuration</title>
<title>MySQL SSL configuration</title>
<para>The following lines should be added in the system-wide MySQL configuration file:</para>
<para>In my.cnf:</para>
<programlisting>[[mysqld]]
@@ -39,7 +44,7 @@ ssl-key=/path/to/ssl/server-key.pem</programlisting>
<programlisting>ssl-cipher='cipher:list'</programlisting>
</section>
<section xml:id="ch043_database-transport-security-idp50288">
<title>PostgreSQL SSL Configuration</title>
<title>PostgreSQL SSL configuration</title>
<para>The following lines should be added in the system-wide PostgreSQL configuration file, <literal>postgresql.conf</literal>.</para>
<programlisting>ssl = true</programlisting>
<para>Optionally, if you wish to restrict the set of SSL ciphers used for the encrypted connection. See <link xlink:href="http://www.openssl.org/docs/apps/ciphers.html">http://www.openssl.org/docs/apps/ciphers.html</link> for a list of ciphers and the syntax for specifying the cipher string:</para>

13
doc/security-guide/ch044_case-studies-database.xml
View File

@@ -1,13 +1,18 @@
<?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="ch044_case-studies-database"><?dbhtml stop-chunking?>
<title>Case Studies: Database</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch044_case-studies-database">
<?dbhtml stop-chunking?>
<title>Case studies: database</title>
<para>In this case study we discuss how Alice and Bob would address database selection and configuration for their respective private and public clouds.</para>
<section xml:id="ch044_case-studies-database-idp38048">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>Alice's organization has high availability concerns, so she has elected to use MySQL for the database. She further places the database on the Management network and uses SSL with mutual authentication among the services to ensure secure access. Given there will be no external access of the database, she uses certificates signed with the organization's self-signed root certificate on the database and its access endpoints. Alice creates separate user accounts for each database user, and configures the database to use both passwords and X.509 certificates for authentication. She elects not to use the <systemitem class="service">nova-conductor</systemitem> sub-service due to the desire for fine-grained access control policies and audit support.</para>
</section>
<section xml:id="ch044_case-studies-database-idp40064">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>Bob is concerned about strong separation of his tenants' data, so he has elected to use the Postgres database , known for its stronger security features. The database resides on the Management network and uses SSL with mutual authentication with the services. Since the database is on the Management network, the database uses certificates signed with the company's self-signed root certificate. Bob creates separate user accounts for each database user, and configures the database to use both passwords and X.509 certificates for authentication. He elects not to use the <systemitem class="service">nova-conductor</systemitem> sub-service due to a desire for fine-grained access control.</para>
</section>
</chapter>

75
doc/security-guide/ch046_data-residency.xml
View File

@@ -1,67 +1,80 @@
<?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="ch046_data-residency"><?dbhtml stop-chunking?>
<title>Data Privacy Concerns</title>
<para>OpenStack is designed to support multitenancy and those tenants will most probably have different data requirements. As a cloud builder and operator you need to ensure your OpenStack environment can address various data privacy concerns and regulations. In this chapter we will address the following topics around Data Privacy as it pertains to OpenStack implementations:</para>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch046_data-residency">
<?dbhtml stop-chunking?>
<title>Data privacy concerns</title>
<para>
OpenStack is designed to support multitenancy and those tenants
will most probably have different data requirements. As a cloud
builder and operator you need to ensure your OpenStack
environment can address various data privacy concerns and
regulations. In this chapter we will address the following
topics around Data Privacy as it pertains to OpenStack
implementations:
</para>
<itemizedlist><listitem>
<para>Data Residency</para>
<para>Data residency</para>
</listitem>
<listitem>
<para>Data Disposal</para>
<para>Data disposal</para>
</listitem>
</itemizedlist>
<section xml:id="ch046_data-residency-idp46544">
<title>Data Residency</title>
<title>Data residency</title>
<para>The privacy and isolation of data has consistently been cited as the primary barrier to cloud adoption over the past few years. Concerns over who owns data in the cloud and whether the cloud operator can be ultimately trusted as a custodian of this data have been significant issues in the past.</para>
<para>Numerous OpenStack services maintain data and metadata belonging to tenants or reference tenant information.</para>
<para>Tenant data stored in an OpenStack cloud may include the following items:</para>
<itemizedlist><listitem>
<para>Swift objects</para>
<para>Object Storage objects</para>
</listitem>
<listitem>
<listitem>
<para>Compute instance ephemeral filesystem storage</para>
</listitem>
<listitem>
<listitem>
<para>Compute instance memory</para>
</listitem>
<listitem>
<para>Cinder volume data</para>
<listitem>
<para>Block Storage volume data</para>
</listitem>
<listitem>
<listitem>
<para>Public keys for Compute Access</para>
</listitem>
<listitem>
<para>Virtual Machine Images in Glance</para>
<listitem>
<para>Virtual Machine Images in the Image Service</para>
</listitem>
<listitem>
<listitem>
<para>Machine snapshots</para>
</listitem>
<listitem>
<listitem>
<para>Data passed to OpenStack Compute's configuration-drive extension</para>
</listitem>
</itemizedlist>
</itemizedlist>
<para>Metadata stored by an OpenStack cloud includes the following non-exhaustive items:</para>
<itemizedlist><listitem>
<para>Organization name</para>
</listitem>
<listitem>
<listitem>
<para>User's "Real Name"</para>
</listitem>
<listitem>
<listitem>
<para>Number or size of running instances, buckets, objects, volumes, and other quota-related items</para>
</listitem>
<listitem>
<listitem>
<para>Number of hours running instances or storing data</para>
</listitem>
<listitem>
<listitem>
<para>IP addresses of users</para>
</listitem>
<listitem>
<listitem>
<para>Internally generated private keys for compute image bundling</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch046_data-residency-idp61296">
<title>Data Disposal</title>
<title>Data disposal</title>
<para>OpenStack operators should strive to provide a certain level of tenant data disposal assurance. Best practices suggest that the operator sanitize cloud system media (digital and non-digital) prior to disposal, release out of organization control or release for reuse. Sanitization methods should implement an appropriate level of strength and integrity given the specific security domain and sensitivity of the information.</para>
<blockquote>
<para>"Sanitization is the process used to remove information from system media such that there is reasonable assurance that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, and destroying media information, prevent the disclosure of organizational information to unauthorized individuals when such media is reused or released for disposal." [NIST Special Publication 800-53 Revision 3]</para>
@@ -124,8 +137,20 @@
</section>
<section xml:id="ch046_data-residency-idp85040">
<title>Bare metal server sanitization</title>
<para>A bare metal server driver for Nova was under development and has since moved into a separate project called <link xlink:href="https://wiki.openstack.org/wiki/Ironic">Ironic</link>. At the time of this writing, Ironic does not appear to address sanitization of tenant data resident the physical hardware.</para>
<para>Additionally, it is possible for tenants of a bare metal system to modify system firmware. TPM technology, described in ##link:Management/Node Bootstrapping##, provides a solution for detecting unauthorized firmware changes.</para>
<para>
A bare metal server driver for Compute was under development
and has since moved into a separate project called <link
xlink:href="https://wiki.openstack.org/wiki/Ironic">ironic</link>. At
the time of this writing, ironic does not appear to address
sanitization of tenant data resident the physical hardware.
</para>
<para>
Additionally, it is possible for tenants of a bare metal
system to modify system firmware. TPM technology, described
in <xref linkend="ch013_node-bootstrapping-idp44768"/>,
provides a solution for detecting unauthorized firmware
changes.
</para>
</section>
</section>
</chapter>

17
doc/security-guide/ch047_data-encryption.xml
View File

@@ -1,6 +1,11 @@
<?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="ch047_data-encryption"><?dbhtml stop-chunking?>
<title>Data Encryption</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch047_data-encryption">
<?dbhtml stop-chunking?>
<title>Data encryption</title>
<para>The option exists for implementors to encrypt tenant data wherever it is stored on disk or transported over a network. This is above and beyond the general recommendation that users encrypt their own data before sending it to their provider.</para>
<para>The importance of encrypting data on behalf of tenants is largely related to the risk assumed by a provider that an attacker could access tenant data. There may be requirements here in government, as well as requirements per-policy, in private contract, or even in case law in regard to private contracts for public cloud providers. It is recommended that a risk assessment and legal consul advised before choosing tenant encryption policies.</para>
<para>Per-instance or per-object encryption is preferable over, in descending order, over per-project, per-tenant, per-host, and per-cloud aggregations. This recommendation is inverse to the complexity and difficulty of implementation. Presently, in some projects it is difficult or impossible to implement encryption as loosely granular as even per-tenant. We recommend implementors make a best-effort in encrypting tenant data.</para>
@@ -10,26 +15,26 @@
<para>Object Storage objects</para>
</listitem>
<listitem>
<para>Block Storage volumes &amp; Instance Ephemeral Filesystems</para>
<para>Block Storage volumes and instance ephemeral filesystems</para>
</listitem>
<listitem>
<para>Network data</para>
</listitem>
</itemizedlist>
<section xml:id="ch047_data-encryption-idp50112">
<title>Object Storage Objects</title>
<title>Object Storage objects</title>
<para>The ability to encrypt objects in Object Storage 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>Block Storage Volumes &amp; Instance Ephemeral Filesystems</title>
<title>Block Storage volumes and 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 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>
<title>Network data</title>
<para>Tenant data for compute could be encrypted over IPSec or
other tunnels. This is not functionality common or standard in
OpenStack, but is an option available to motivated and

11
doc/security-guide/ch048_key-management.xml
View File

@@ -1,10 +1,15 @@
<?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="ch048_key-management"><?dbhtml stop-chunking?>
<title>Key Management</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch048_key-management">
<?dbhtml stop-chunking?>
<title>Key management</title>
<para>To address the often mentioned concern of tenant data privacy and limiting cloud provider liability, there is greater interest within the OpenStack community to make data encryption more ubiquitous. It is relatively easy for an end-user to encrypt their data prior to saving it to the cloud, and this is a viable path for tenant objects such as media files, database archives among others. However, when client side encryption is used for virtual machine images, block storage etc, client intervention is necessary in the form of presenting keys to unlock the data for further use. To seamlessly secure the data and yet have it accessible without burdening the client with having to manage their keys and interactively provide them calls for a key management service within OpenStack. Providing encryption and key management services as part of OpenStack eases data-at-rest security adoption, addresses customer concerns about the privacy and misuse of their data with the added advantage of limiting cloud provider liability. Provider liability is of concern in multi-tenant public clouds with respect to handing over tenant data during a misuse investigation.</para>
<para>A key management service is in the early stages of being developed and has a way to go before becoming an official component of OpenStack. Refer to <link xlink:href="https://github.com/cloudkeep/barbican/wiki/_pages">https://github.com/cloudkeep/barbican/wiki/_pages</link> for details.</para>
<para>It shall support the creation of keys, and their secure saving (with a service master-key). Some of the design questions still being debated are how much of the Key Management Interchange Protocol (KMIP) to support, key formats, and certificate management. The key manager will be pluggable to facilitate deployments that need a third-party Hardware Security Module (HSM).</para>
<para>OpenStack Block Storage, Cinder, is the first service looking to integrate with the key manager to provide volume encryption.</para>
<para>OpenStack Block Storage, cinder, is the first service looking to integrate with the key manager to provide volume encryption.</para>
<section xml:id="ch048_key-management-idp47776">
<title>References:</title>
<itemizedlist><listitem>

13
doc/security-guide/ch049_case-studies-tenant-data.xml
View File

@@ -1,9 +1,14 @@
<?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="ch049_case-studies-tenant-data"><?dbhtml stop-chunking?>
<title>Case Studies: Tenant Data</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch049_case-studies-tenant-data">
<?dbhtml stop-chunking?>
<title>Case studies: tenant data</title>
<para>Returning to Alice and Bob, we will use this section to dive into their particular tenant data privacy requirements. Specifically, we will look into how Alice and Bob both handle tenant data, data destruction, and data encryption.</para>
<section xml:id="ch049_case-studies-tenant-data-idp44416">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>As stated during the introduction to Alice's case study,
data protection is of an extremely high priority. She
needs to ensure that a compromise of one tenant's data
@@ -20,7 +25,7 @@
</itemizedlist>
</section>
<section xml:id="ch049_case-studies-tenant-data-idp51856">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>As stated during the introduction to Bob's case study, tenant privacy is of an extremely high priority. In addition to the requirements and actions Bob will take to isolate tenants from one another at the infrastructure layer, Bob also needs to provide assurances for tenant data privacy. Bob does this using the following:</para>
<itemizedlist>
<listitem><para>Establishing procedures to sanitize customer data when a customer churns</para> </listitem>

25
doc/security-guide/ch051_vss-intro.xml
View File

@@ -4,8 +4,13 @@
%openstack;
]>
<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="ch051_vss-intro"><?dbhtml stop-chunking?>
<title>Hypervisor Selection</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch051_vss-intro">
<?dbhtml stop-chunking?>
<title>Hypervisor selection</title>
<para>Virtualization provides flexibility and other key benefits
that enable cloud building. However, a virtualization stack also
needs to be secured appropriately to reduce the risks associated
@@ -39,7 +44,7 @@
<para>Within the framework of OpenStack you can choose from any number of hypervisor platforms and corresponding OpenStack plug-ins to optimize your cloud environment. In the context of the OpenStack Security guide, we will be highlighting hypervisor selection considerations as they pertain to feature sets that are critical to security. However, these considerations are not meant to be an exhaustive investigation into the pros and cons of particular hypervisors. NIST provides additional guidance in Special Publication 800-125, "<emphasis>Guide to Security for Full Virtualization Technologies</emphasis>".</para>
</section>
<section xml:id="ch051_vss-intro-idp242144">
<title>Selection Criteria</title>
<title>Selection criteria</title>
<para>As part of your hypervisor selection process, you will need to consider a number of important factors to help increase your security posture. Specifically, we will be looking into the following areas:</para>
<itemizedlist><listitem>
<para>Team Expertise</para>
@@ -71,7 +76,7 @@
</listitem>
</itemizedlist><bridgehead>Team Expertise</bridgehead> Most likely, the most important aspect in hypervisor selection is the expertise of your staff in managing and maintaining a particular hypervisor platform. The more familiar your team is with a given product, its configuration, and its eccentricities, the less likely will there be configuration mistakes. Additionally, having staff expertise spread across an organization on a given hypervisor will increase availability of your systems, allow for developing a segregation of duties, and mitigate problems in the event that a team member is unavailable.</para>
<section xml:id="ch051_vss-intro-idp252752">
<title>Product or Project Maturity</title>
<title>Product or project maturity</title>
<para>The maturity of a given hypervisor product or project is critical to your security posture as well. Product maturity will have a number of effects once you have deployed your cloud, in the context of this security guide we are interested in the following:</para>
<itemizedlist><listitem>
<para>Availability of expertise</para>
@@ -90,7 +95,7 @@
<para>Further, the quality of community, as it surrounds an open source hypervisor like KVM or Xen, will have a direct impact on the timeliness of bug fixes and security updates. When investigating both commercial and open source hypervisors, you will want to look into their release and support cycles as well as the time delta between the announcement of a bug or security issue and a patch or response. Lastly, the supported capabilities of OpenStack compute vary depending on the hypervisor chosen. Refer to the <link xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix">OpenStack Hypervisor Support Matrix</link> for OpenStack compute feature support by hypervisor.</para>
</section>
<section xml:id="ch051_vss-intro-idp260720">
<title>Certifications and Attestations</title>
<title>Certifications and attestations</title>
<para>One additional consideration when selecting a hypervisor is the availability of various formal certifications and attestations. While they may not be requirements for your specific organization, these certifications and attestations speak to the maturity, production readiness, and thoroughness of the testing a particular hypervisor platform has been subjected to.</para>
</section>
<section xml:id="ch051_vss-intro-idp262672">
@@ -184,7 +189,7 @@
</section>
<section xml:id="ch051_vss-intro-idp324896">
<title>Cryptography Standards</title>
<title>Cryptography standards</title>
<para>Several cryptography algorithms are available within OpenStack for identification and authorization, data transfer and protection of data at rest. When selecting a hypervisor, the following are recommended algorithms and implementation standards to ensure the virtualization layer supports:</para>
<informaltable rules="all" width="80%"><colgroup><col/><col/><col/><col/><col/></colgroup>
@@ -270,7 +275,7 @@
</section>
</section>
<section xml:id="ch051_vss-intro-idp367552">
<title>Hardware Concerns</title>
<title>Hardware concerns</title>
<para>Further, when evaluating a hypervisor platform the supportability of the hardware the hypervisor will run on should be considered. Additionally, consider the additional features available in the hardware and how those features are supported by the hypervisor you chose as part of the OpenStack deployment. To that end, hypervisors will each have their own hardware compatibility lists (HCLs). When selecting compatible hardware it is important to know in advance which hardware-based virtualization technologies are important from a security perspective.</para>
<informaltable rules="all" width="80%"><colgroup><col/><col/><col/></colgroup>
@@ -308,14 +313,14 @@
</section>
<section xml:id="ch051_vss-intro-idp396976">
<title>Hypervisor vs. Baremetal</title>
<title>Hypervisor vs. baremetal</title>
<para>To wrap up our discussion around hypervisor selection, it is important to call out the differences between using LXC (Linux Containers) or Baremetal systems vs using a hypervisor like KVM. Specifically, the focus of this security guide will be largely based on having a hypervisor and virtualization platform. However, should your implementation require the use of a baremetal or LXC environment, you will want to pay attention to the particular differences in regard to deployment of that environment. In particular, you will need to provide your end users with assurances that the node has been properly sanitized of their data prior to re-provisioning. Additionally, prior to reusing a node, you will need to provide assurances that the hardware has not been tampered or otherwise compromised.</para>
<para>It should be noted that while OpenStack has a baremetal project, a discussion of the particular security implications of running baremetal is beyond the scope of this book.</para>
<para>Finally, due to the time constraints around a book sprint, the team chose to use KVM as the hypervisor in our example implementations and architectures.</para>
<note><para>There is an OpenStack Security Note pertaining to the <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1098582">use of LXC in Nova</link>.</para></note>
<note><para>There is an OpenStack Security Note pertaining to the <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1098582">use of LXC in nova</link>.</para></note>
</section>
<section xml:id="ch051_vss-intro-idp401408">
<title>Additional Security Features</title>
<title>Additional security features</title>
<para>Another thing to look into when selecting a hypervisor platform is the availability of specific security features. In particular, we are referring to features like Xen Server's XSM or Xen Security Modules, sVirt, Intel TXT, and AppArmor. The presence of these features will help increase your security profile as well as provide a good foundation.</para>
<para>The following table calls out these features by common hypervisor platforms.</para>

39
doc/security-guide/ch052_devices.xml
View File

@@ -1,9 +1,14 @@
<?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="ch052_devices"><?dbhtml stop-chunking?>
<title>Hardening the Virtualization Layers</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch052_devices">
<?dbhtml stop-chunking?>
<title>Hardening the virtualization layers</title>
<para>In the beginning of this chapter we discuss the use of both physical and virtual hardware by instances, the associated security risks, and some recommendations for mitigating those risks. We conclude the chapter with a discussion of sVirt, an open source project for integrating SELinux mandatory access controls with the virtualization components.</para>
<section xml:id="ch052_devices-idp479920">
<title>Physical Hardware (PCI Passthrough)</title>
<title>Physical hardware (PCI passthrough)</title>
<para>Many hypervisors offer a functionality known as PCI passthrough. This allows an instance to have direct access to a piece of hardware on the node. For example, this could be used to allow instances to access video cards offering the compute unified device architecture (CUDA) for high performance computation. This feature carries two types of security risks: direct memory access and hardware infection.</para>
<para>Direct memory access (DMA) is a feature that permits certain hardware devices to access arbitrary physical memory addresses in the host computer. Often video cards have this capability. However, an instance should not be given arbitrary physical memory access because this would give it full view of both the host system and other instances running on the same node. Hardware vendors use an input/output memory management unit (IOMMU) to manage DMA access in these situations. Therefore, cloud architects should ensure that the hypervisor is configured to utilize this hardware feature.</para>
<itemizedlist><listitem>
@@ -17,11 +22,25 @@
<para>The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
</note>
<para>A hardware infection occurs when an instance makes a malicious modification to the firmware or some other part of a device. As this device is used by other instances, or even the host OS, the malicious code can spread into these systems. The end result is that one instance can run code outside of its security domain. This is a potential problem in any hardware sharing scenario. The problem is specific to this scenario because it is harder to reset the state of physical hardware than virtual hardware.</para>
<para>Solutions to the hardware infection problem are domain specific. The strategy is to identify how an instance can modify hardware state then determine how to reset any modifications when the instance is done using the hardware. For example, one option could be to re-flash the firmware after use. Clearly there is a need to balance hardware longevity with security as some firmwares will fail after a large number of writes. TPM technology, described in <literal>link:Management/Node Bootstrapping</literal>, provides a solution for detecting unauthorized firmware changes. Regardless of the strategy selected, it is important to understand the risks associated with this kind of hardware sharing so that they can be properly mitigated for a given deployment scenario.</para>
<para>
Solutions to the hardware infection problem are domain
specific. The strategy is to identify how an instance can modify
hardware state then determine how to reset any modifications
when the instance is done using the hardware. For example, one
option could be to re-flash the firmware after use. Clearly
there is a need to balance hardware longevity with security as
some firmwares will fail after a large number of writes. TPM
technology, described in <xref
linkend="ch013_node-bootstrapping-idp44768"/>, provides a
solution for detecting unauthorized firmware changes. Regardless
of the strategy selected, it is important to understand the
risks associated with this kind of hardware sharing so that they
can be properly mitigated for a given deployment scenario.
</para>
<para>Additionally, due to the risk and complexities associated with PCI passthrough, it should be disabled by default. If enabled for a specific need, you will need to have appropriate processes in place to ensure the hardware is clean before re-issue.</para>
</section>
<section xml:id="ch052_devices-idp488320">
<title>Virtual Hardware (QEMU)</title>
<title>Virtual hardware (QEMU)</title>
<para>When running a virtual machine, virtual hardware is a
software layer that provides the hardware interface for the
virtual machine. Instances use this functionality to provide
@@ -44,7 +63,7 @@
using mandatory access controls, such as sVirt, SELinux, or
AppArmor.</para>
<section xml:id="ch052_devices-idp490976">
<title>Minimizing the Qemu Code base</title>
<title>Minimizing the QEMU code base</title>
<para>One classic security principle is to remove any unused components from your system. QEMU provides support for many different virtual hardware devices. However, only a small number of devices are needed for a given instance. Most instances will use the virtio devices. However, some legacy instances will need access to specific hardware, which can be specified using glance metadata:</para>
<screen><prompt>$</prompt> <userinput>glance image-update \
--property hw_disk_bus=ide \
@@ -54,7 +73,7 @@
<para>A cloud architect should decide what devices to make available to cloud users. Anything that is not needed should be removed from QEMU. This step requires recompiling QEMU after modifying the options passed to the QEMU configure script. For a complete list of up-to-date options simply run <literal>./configure --help</literal> from within the QEMU source directory. Decide what is needed for your deployment, and disable the remaining options.</para>
</section>
<section xml:id="ch052_devices-idp494336">
<title>Compiler Hardening</title>
<title>Compiler hardening</title>
<para>The next step is to harden QEMU using compiler hardening options. Modern compilers provide a variety of compile time options to improve the security of the resulting binaries. These features, which we will describe in more detail below, include relocation read-only (RELRO), stack canaries, never execute (NX), position independent executable (PIE), and address space layout randomization (ASLR).</para>
<para>Many modern linux distributions already build QEMU with compiler hardening enabled, so you may want to verify your existing executable before proceeding with the information below. One tool that can assist you with this verification is called <link xlink:href="http://www.trapkit.de/tools/checksec.html"><literal>checksec.sh</literal></link>.</para>
<itemizedlist><listitem>
@@ -86,12 +105,12 @@
</itemizedlist>
</section>
<section xml:id="ch052_devices-idp508032">
<title>Mandatory Access Controls</title>
<title>Mandatory access controls</title>
<para>Compiler hardening makes it more difficult to attack the QEMU process. However, if an attacker does succeed, we would like to limit the impact of the attack. Mandatory access controls accomplish this by restricting the privileges on QEMU process to only what is needed. This can be accomplished using sVirt / SELinux or AppArmor. When using sVirt, SELinux is configured to run every QEMU process under a different security context. AppArmor can be configured to provide similar functionality. We provide more details on sVirt in the instance isolation section below.</para>
</section>
</section>
<section xml:id="ch052_devices-idp510512">
<title>sVirt: SELinux + Virtualization</title>
<title>sVirt: SELinux and virtualization</title>
<para>With unique kernel-level architecture and National
Security Agency (NSA) developed security mechanisms, KVM
provides foundational isolation technologies for multi tenancy.
@@ -135,7 +154,7 @@
</inlinemediaobject></para>
<para>As shown above, sVirt isolation is provided regardless of the guest Operating System running inside the virtual machine -- Linux or Windows VMs can be used. Additionally, many Linux distributions provide SELinux within the operating system, allowing the virtual machine to protect internal virtual resources from threats.</para>
<section xml:id="ch052_devices-idp523744">
<title>Labels and Categories</title>
<title>Labels and categories</title>
<para>KVM-based virtual machine instances are labelled with their own SELinux data type, known as svirt_image_t. Kernel level protections prevent unauthorized system processes, such as malware, from manipulating the virtual machine image files on disk. When virtual machines are powered off, images are stored as svirt_image_t as shown below:</para>
<programlisting>system_u:object_r:svirt_image_t:SystemLow image1
system_u:object_r:svirt_image_t:SystemLow image2

13
doc/security-guide/ch053_case-studies-instance-isolation.xml
View File

@@ -1,15 +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="ch053_case-studies-instance-isolation"><?dbhtml stop-chunking?>
<title>Case Studies: Instance Isolation</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch053_case-studies-instance-isolation">
<?dbhtml stop-chunking?>
<title>Case studies: instance isolation</title>
<para>In this case study we discuss how Alice and Bob would ensure that their instances are properly isolated. First we consider hypervisor selection, and then techniques for hardening QEMU and applying mandatory access controls.</para>
<section xml:id="ch053_case-studies-instance-isolation-idp480000">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>Alice chooses Xen for the hypervisor in her cloud due to a strong internal knowledge base and a desire to use the Xen security modules (XSM) for fine-grained policy enforcement.</para>
<para>Alice is willing to apply a relatively large amount of resources to software packaging and maintenance. She will use these resources to build a highly customized version of QEMU that has many components removed, thereby reducing the attack surface. She will also ensure that all compiler hardening options are enabled for QEMU. Alice accepts that these decisions will increase long-term maintenance costs.</para>
<para>Alice writes XSM policies (for Xen) and SELinux policies (for Linux domain 0, and device domains) to provide stronger isolation between the instances. Alice also uses the Intel TXT support in Xen to measure the hypervisor launch in the TPM.</para>
</section>
<section xml:id="ch053_case-studies-instance-isolation-idp482832">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>Bob is very concerned about instance isolation since the users in a public cloud represent anyone with a credit card, meaning they are inherently untrusted. Bob has just started hiring the team that will deploy the cloud, so he can tailor his candidate search for specific areas of expertise. With this in mind, Bob chooses a hypervisor based on its technical features, certifications, and community support. KVM has an EAL 4+ common criteria rating, with a labeled security protection profile (LSPP) to provide added assurance for instance isolation. This, combined with the strong support for KVM within the OpenStack community drives Bob's decision to use KVM.</para>
<para>Bob weighs the added cost of repackaging QEMU and decides that he cannot commit those resources to the project. Fortunately, his Linux distribution has already enabled the compiler hardening options. So he decides to use this QEMU package. Finally, Bob leverages sVirt to manage the SELinux polices associated with the virtualization stack.</para>
</section>

46
doc/security-guide/ch055_security-services-for-instances.xml
View File

@@ -1,6 +1,11 @@
<?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="ch055_security-services-for-instances"><?dbhtml stop-chunking?>
<title>Security Services for Instances</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch055_security-services-for-instances">
<?dbhtml stop-chunking?>
<title>Security services for instances</title>
<para>One of the virtues of running instances in a virtualized environment is that it opens up new opportunities for security controls that are not typically available when deploying onto bare metal. There are several technologies that can be applied to the virtualization stack that bring improved information assurance for cloud tenants.</para>
<para>Deployers or users of OpenStack with strong security requirements may want to consider deploying these technologies. Not all are applicable in every situation, indeed in some cases technologies may be ruled out for use in a cloud because of prescriptive business requirements. Similarly some technologies inspect instance data such as run state which may be undesirable to the users of the system.</para>
<para>In this chapter we explore these technologies and describe the situations where they can be used to enhance security for instances or underlying instances. We also seek to highlight where privacy concerns may exist. These include data pass through, introspection, or providing a source of entropy. In this section we highlight the following additional security services:</para>
@@ -18,14 +23,14 @@
</listitem>
</itemizedlist>
<section xml:id="ch055_security-services-for-instances-idp122544">
<title>Entropy To Instances</title>
<title>Entropy to instances</title>
<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>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>
<title>Scheduling instances to nodes</title>
<para>Before an instance is created, a host for the image instantiation must be selected. This selection is performed by the <systemitem class="service">nova-scheduler</systemitem> which determines how to dispatch compute and volume requests.</para>
<para>The filter scheduler is the default scheduler for OpenStack Compute,
although other schedulers exist (see the section <link
@@ -52,7 +57,7 @@
<para><emphasis role="bold">Tenant Driven Whole Host Reservation</emphasis></para>
<para>There currently exists a <link xlink:href="https://blueprints.launchpad.net/nova/+spec/whole-host-allocation">blueprint for whole host reservation</link> - This would allow a tenant to exclusively reserve hosts for only it's instances, incurring extra costs.</para>
<section xml:id="ch055_security-services-for-instances-idp140080">
<title>Host Aggregates</title>
<title>Host aggregates</title>
<para>While not a filter in themselves, host aggregates allow
administrators to assign key-value pairs to groups of
machines. This allows cloud administrators, not users, to
@@ -76,17 +81,26 @@
<para>The GroupAntiAffinityFilter ensures that each instance in a group is on a different host. To take advantage of this filter, the requester must pass a scheduler hint, using <literal>group</literal> as the key and a list of instance uuids as the value.</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp148000">
<title>Trusted Compute Pools</title>
<title>Trusted compute pools</title>
<para>There exists a scheduler filter which integrates with the <link xlink:href="https://github.com/OpenAttestation/OpenAttestation">Open Attestation Project</link> (OATS) to define scheduler behavior according to the attestation of PCRs received from a system using Intel TXT.</para>
<para>It is unclear if this feature is compatible with AMD's similar SEM, although the OpenAttestation agent relies on the vendor-agnostic <link xlink:href="http://trousers.sourceforge.net/">TrouSerS library</link>.</para>
</section>
</section>
<section xml:id="ch055_security-services-for-instances-idp150416">
<title>Trusted Images</title>
<title>Trusted images</title>
<para>With regards to images, users will be working with pre-installed images or images that they upload themselves. In both cases, users will want to ensure that the image they are ultimately running has not been tampered with. This requires some source of truth such as a checksum for the known good version of an image as well as verification of the running image. This section describes the current best practices around image handling, while also calling out some of the existing gaps in this space.</para>
<section xml:id="ch055_security-services-for-instances-idp151952">
<title>Image Creation Process</title>
<para>The OpenStack Documentation provides guidance on how to create and upload an image to Glance. Additionally it is assumed that you have a process by which you install and harden operating systems. Thus, the following items will provide additional guidance on how to ensure your images are built securely prior to upload. There are a variety of options for obtaining images. Each has specific steps that help validate the image's provenance.</para>
<title>Image creation process</title>
<para>
The OpenStack Documentation provides guidance on how to
create and upload an image to the Image
Service. Additionally it is assumed that you have a process
by which you install and harden operating systems. Thus, the
following items will provide additional guidance on how to
ensure your images are built securely prior to upload. There
are a variety of options for obtaining images. Each has
specific steps that help validate the image's provenance.
</para>
<para>The first option is to obtain boot media from a trusted source.</para>
<screen><prompt>$</prompt> <userinput>mkdir -p /tmp/download_directorycd /tmp/download_directory</userinput>
<prompt>$</prompt> <userinput>wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/ubuntu-12.04.2-server-amd64.iso</userinput>
@@ -136,14 +150,14 @@
<para>If subscribing to a public cloud service, you should check with the cloud provider for an outline of the process used to produce their default images. If the provider allows you to upload your own images, you will want to ensure that you are able to verify that your image was not modified before you spin it up. To do this, refer to the following section on Image Provenance.</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp166272">
<title>Image Provenance and Validation</title>
<title>Image provenance and validation</title>
<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 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">
<title>Instance Migrations</title>
<title>Instance migrations</title>
<para>
OpenStack and the underlying virtualization layers provide for
the live migration of images between OpenStack nodes allowing
@@ -162,7 +176,7 @@
<listitem><para>Start the guest</para> </listitem>
</orderedlist>
<section xml:id="ch055_security-services-for-instances-idp177552">
<title>Live Migration Risks</title>
<title>Live migration risks</title>
<para>At various stages of the live migration process the contents of an instances run time memory and disk are transmitted over the network in plain text. Thus there are several risks that need to be addressed when using live migration. The following in-exhaustive list details some of these risks:</para>
<itemizedlist><listitem>
<para><emphasis>Denial of Service (DoS)</emphasis> : If something fails during the migration process, the instance could be lost.</para>
@@ -179,7 +193,7 @@
</itemizedlist>
</section>
<section xml:id="ch055_security-services-for-instances-idp183744">
<title>Live Migration Mitigations</title>
<title>Live migration mitigations</title>
<para>There are several methods to mitigate some of the risk associated with live migrations, the following list details some of these:</para>
<itemizedlist><listitem>
<para>Disable Live Migration</para>
@@ -192,17 +206,17 @@
</listitem>
</itemizedlist>
<section xml:id="ch055_security-services-for-instances-idp187568">
<title>Disable Live Migration</title>
<title>Disable live migration</title>
<para>At this time, live migration is enabled in OpenStack by default. Live migrations can be disabled by adding the following lines to the nova policy.json file:</para>
<programlisting>"compute_extension:admin_actions:migrate": "!",
"compute_extension:admin_actions:migrateLive": "!",</programlisting>
</section>
<section xml:id="ch055_security-services-for-instances-idp189488">
<title>Migration Network</title>
<title>Migration network</title>
<para>As a general practice, live migration traffic should be restricted to the management security domain. Indeed live migration traffic, due to its plain text nature and the fact that you are transferring the contents of disk and memory of a running instance, it is recommended you further separate live migration traffic onto a dedicated network. Isolating the traffic to a dedicated network can reduce the risk of exposure.</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp191072">
<title>Encrypted Live Migration</title>
<title>Encrypted live migration</title>
<para>If your use case involves keeping live migration enabled, then libvirtd can provide tunneled, encrypted live migrations. That said, this feature is not currently exposed in OpenStack Dashboard, nor the nova-client commands and can only be accessed through manual configuration of libvirtd. Encrypted live migration modifies the live migration process by first copying the instance data from the running hypervisor to libvirtd. From there an encrypted tunnel is created between the libvirtd processes on both hosts. Finally, the destination libvirtd process copies the instance back to the underlying hypervisor.</para>
</section>
</section>

23
doc/security-guide/ch056_case-studies-instance-management.xml
View File

@@ -1,17 +1,30 @@
<?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="ch056_case-studies-instance-management"><?dbhtml stop-chunking?>
<title>Case Studies: Instance Management</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch056_case-studies-instance-management">
<?dbhtml stop-chunking?>
<title>Case studies: instance management</title>
<para>In this case study we discuss how Alice and Bob would architect their clouds with respect to instance entropy, scheduling instances, trusted images, and instance migrations.</para>
<section xml:id="ch056_case-studies-instance-management-idp44448">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>Alice has a need for lots of high quality entropy in the instances. For this reason, she decides to purchase hardware with Intel Ivy Bridge chip sets that support the RdRand instruction on each compute node. Using the entropy gathering daemon (EGD) and LibVirt's EGD support, Alice ensures that this entropy pool is distributed to the instances on each compute node.</para>
<para>For instance scheduling, Alice uses the trusted compute pools to ensure that all cloud workloads are deployed to nodes that presented a proper boot time attestation. Alice decides to disable user permissions for image uploading to help ensure that the images used in the cloud are generated in a known and trusted manner by the cloud administrators.</para>
<para>Finally, Alice disables instance migrations as this feature is less critical for the high performance application workloads expected to run in this cloud. This helps avoid the various security concerns related to instance migrations.</para>
</section>
<section xml:id="ch056_case-studies-instance-management-idp47664">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>Bob is aware that entropy will be a concern for some of his customers, such as those in the financial industry. However, due to the added cost and complexity, Bob has decided to forgo integrating hardware entropy into the first iteration of his cloud. He adds hardware entropy as a fast-follow to do for a later improvement for the second generation of his cloud architecture.</para>
<para>Bob is interested in ensuring that customers receive a high quality of service. He is concerned that providing too much explicit user control over instance scheduling could negatively impact the quality of service. So he disables this feature. Bob provides images in the cloud from a known trusted source for users to use. Additionally, he also allows users to upload their own images. However, users cannot generally share their images. This helps prevent a user from sharing a malicious image, which could negatively impact the security of other users in the cloud.</para>
<para>For migrations, Bob wants to enable secure instance migrations in order to support rolling upgrades with minimal user downtime. Bob ensures that all migrations occur on an isolated VLAN. He plans to defer implementing encrypted migrations until this is better supported in Nova client tools. However, he makes a note to track this carefully and switch to encrypted migrations as soon as possible.</para>
<para>
For migrations, Bob wants to enable secure instance migrations
in order to support rolling upgrades with minimal user
downtime. Bob ensures that all migrations occur on an isolated
VLAN. He plans to defer implementing encrypted migrations
until this is better supported in <command>nova</command>
client tools. However, he makes a note to track this carefully
and switch to encrypted migrations as soon as possible.
</para>
</section>
</chapter>

11
doc/security-guide/ch058_forensicsincident-response.xml
View File

@@ -1,6 +1,11 @@
<?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="ch058_forensicsincident-response"><?dbhtml stop-chunking?>
<title>Forensics and Incident Response</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch058_forensicsincident-response">
<?dbhtml stop-chunking?>
<title>Forensics and incident response</title>
<para>A lot of activity goes on within a cloud environment. It is a mix of hardware, operating systems, virtual machine managers, the OpenStack services, cloud-user activity such as creating instances and attaching storage, the network underlying the whole, and finally end-users using the applications running on the various instances.</para>
<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>
@@ -8,7 +13,7 @@
<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>
<title>Monitoring use cases</title>
<para>Monitoring events is more pro-active and provides real-time detection and response. There are several tools to aid in monitoring.</para>
<para>In the case of an OpenStack cloud instance, we need to monitor the hardware, the OpenStack services, and the cloud resource usage. The last stems from wanting to be elastic, to scale to the dynamic needs of the users.</para>
<para>Here are a few important use cases to consider when implementing log aggregation, analysis and monitoring. These use cases can be implemented and monitored through various commercial and open source tools, homegrown scripts, etc. These tools and scripts can generate events that can then be sent to the administrators through email or integrated dashboard. It is important to consider additional use cases that may apply to your specific network and what you may consider anomalous behavior.</para>

13
doc/security-guide/ch059_case-studies-monitoring-logging.xml
View File

@@ -1,13 +1,18 @@
<?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="ch059_case-studies-monitoring-logging"><?dbhtml stop-chunking?>
<title>Case Studies: Monitoring and Logging</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch059_case-studies-monitoring-logging">
<?dbhtml stop-chunking?>
<title>Case studies: monitoring and logging</title>
<para>In this case study we discuss how Alice and Bob would address monitoring and logging in the public vs a private cloud. In both instances, time synchronization and a centralized store of logs become extremely important for performing proper assessments and troubleshooting of anomalies. Just collecting logs is not very useful, a robust monitoring system must be built to generate actionable events.</para>
<section xml:id="ch059_case-studies-monitoring-logging-idp194928">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>In the private cloud, Alice has a better understanding of the tenants requirements and accordingly can add appropriate oversight and compliance on monitoring and logging. Alice should identify critical services and data and ensure that logging is turned at least on those services and is being aggregated to a central log server. She should start with simple and known use cases and implement correlation and alerting to limit the number of false positives. To implement correlation and alerting, she sends the log data to her organization's existing SIEM tool. Security monitoring should be an ongoing process and she should continue to define use cases and alerts as she has better understanding of the network traffic activity and usage over time.</para>
</section>
<section xml:id="ch059_case-studies-monitoring-logging-idm1936">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>When it comes to logging, as a public cloud provider, Bob is interested in logging both for situational awareness as well as compliance. That is, compliance that Bob as a provider is subject to as well as his ability to provide timely and relevant logs or reports on the behalf of his customers for their compliance audits. With that in mind, Bob configures all of his instances, nodes, and infrastructure devices to perform time synchronization with an external, known good time device. Additionally, Bob's team has built a Django based web applications for his customers to perform self-service log retrieval from Bob's SIEM tool. Bob also uses this SIEM tool along with a robust set of alerts and integration with his CMDB to provide operational awareness to both customers and cloud administrators.</para>
</section>
</chapter>

11
doc/security-guide/ch061_compliance-overview.xml
View File

@@ -1,6 +1,11 @@
<?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="ch061_compliance-overview"><?dbhtml stop-chunking?>
<title>Compliance Overview</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch061_compliance-overview">
<?dbhtml stop-chunking?>
<title>Compliance overview</title>
<para>An OpenStack deployment may require compliance activities for many purposes, such as regulatory and legal requirements, customer need, privacy considerations, and security best practices. Compliance, when done correctly, unifies and strengthens the other security topics discussed in this guide. This chapter has several objectives:</para>
<itemizedlist><listitem>
<para>Review common security principles.</para>
@@ -16,7 +21,7 @@
</listitem>
</itemizedlist>
<section xml:id="ch061_compliance-overview-idp48672">
<title>Security Principles</title>
<title>Security principles</title>
<para>Industry standard security principles provide a baseline for compliance certifications and attestations. If these principles are considered and referenced throughout an OpenStack deployment, certification activities may be simplified.</para>
<orderedlist><listitem>
<para><emphasis>Layered Defenses</emphasis>: Identify where risks exist in a cloud architecture and apply controls to mitigate the risks. In areas of significant concern, layered defences provide multiple complementary controls to further mitigate risk. For example, to ensure adequate isolation between cloud tenants, we recommend hardening QEMU, using a hypervisor with SELinux support, enforcing mandatory access control policies, and reducing the overall attack surface. The foundational principle is to harden an area of concern with multiple layers of defense such that if any one layer is compromised, other layers will exist to offer protection and minimize exposure.</para>

47
doc/security-guide/ch062_audit-guidance.xml
View File

@@ -1,16 +1,39 @@
<?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="ch062_audit-guidance"><?dbhtml stop-chunking?>
<title>Understanding the Audit Process</title>
<para>Information system security compliance is reliant on the completion of two foundational processes:</para>
<orderedlist><listitem>
<para><emphasis role="bold">Implementation and Operation of Security Controls</emphasis>Aligning the information system with in-scope standards and regulations involves internal tasks which must be conducted before a formal assessment. Auditors may be involved at this state to conduct gap analysis, provide guidance, and increase the likelihood of successful certification.</para>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch062_audit-guidance">
<?dbhtml stop-chunking?>
<title>Understanding the audit process</title>
<para>Information system security compliance is reliant on the
completion of two foundational processes:</para>
<orderedlist>
<listitem>
<para>
<emphasis role="bold">Implementation and Operation of
Security Controls.</emphasis> Aligning the information
system with in-scope standards and regulations involves
internal tasks which must be conducted before a formal
assessment. Auditors may be involved at this state to
conduct gap analysis, provide guidance, and increase the
likelihood of successful certification.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Independent Verification and Validation</emphasis>Demonstration to a neutral third-party that system security controls are implemented and operating effectively, in compliance with in-scope standards and regulations, is required before many information systems achieve certified status. Many certifications require periodic audits to ensure continued certification, considered part of an overarching continuous monitoring practice.</para>
<listitem>
<para>
<emphasis role="bold">Independent verification and
validation.</emphasis> Demonstration to a neutral
third-party that system security controls are implemented
and operating effectively, in compliance with in-scope
standards and regulations, is required before many
information systems achieve certified status. Many
certifications require periodic audits to ensure continued
certification, considered part of an overarching continuous
monitoring practice.</para>
</listitem>
</orderedlist>
<section xml:id="ch062_audit-guidance-idp48608">
<title>Determining Audit Scope</title>
<title>Determining audit scope</title>
<para>Determining audit scope, specifically what controls are needed and how to design or modify an OpenStack deployment to satisfy them, should be the initial planning step.</para>
<para>When scoping OpenStack deployments for compliance purposes, consider prioritizing controls around sensitive services, such as command and control functions and the base virtualization technology. Compromises of these facilities may impact an OpenStack environment in its entirety.</para>
<para>Scope reduction helps ensure OpenStack architects establish high quality security controls which are tailored to a particular deployment, however it is paramount to ensure these practices do not omit areas or features from security hardening. A common example is applicable to PCI-DSS guidelines, where payment related infrastructure may be scrutinized for security issues, but supporting services are left ignored, and vulnerable to attack.</para>
@@ -20,12 +43,12 @@
<para>These control mappings will help identify common control criteria across certifications, and provide visibility to both auditors and auditees on problem areas within control sets for particular compliance certifications and attestations.</para>
</section>
<section xml:id="ch062_audit-guidance-idp55568">
<title>Internal Audit</title>
<title>Internal audit</title>
<para>Once a cloud is deployed, it is time for an internal audit. This is the time compare the controls you identified above with the design, features, and deployment strategies utilized in your cloud. The goal is to understand how each control is handled and where gaps exist. Document all of the findings for future reference.</para>
<para>When auditing an OpenStack cloud it is important to appreciate the multi-tenant environment inherent in the OpenStack architecture. Some critical areas for concern include data disposal, hypervisor security, node hardening, and authentication mechanisms.</para>
</section>
<section xml:id="ch062_audit-guidance-idp57712">
<title>Prepare for External Audit</title>
<title>Prepare for external audit</title>
<para>Once the internal audit results look good, it is time to prepare for an external audit. There are several key actions to take at this stage, these are outlined below:</para>
<itemizedlist><listitem>
<para>Maintain good records from your internal audit. These will prove useful during the external audit so you can be prepared to answer questions about mapping the compliance controls to a particular deployment.</para>
@@ -40,11 +63,11 @@
<para>Selecting an auditor can be challenging. Ideally, you are looking for someone with experience in cloud compliance audits. OpenStack experience is another big plus. Often it is best to consult with people who have been through this process for referrals. Cost can vary greatly depending on the scope of the engagement and the audit firm considered.</para>
</section>
<section xml:id="ch062_audit-guidance-idp62672">
<title>External Audit</title>
<title>External audit</title>
<para>This is the formal audit process. Auditors will test security controls in scope for a specific certification, and demand evidentiary requirements to prove that these controls were also in place for the audit window (for example SOC 2 audits generally evaluate security controls over a 6-12 months period). Any control failures are logged, and will be documented in the external auditors final report. Dependent on the type of OpenStack deployment, these reports may be viewed by customers, so it is important to avoid control failures. This is why audit preparation is so important.</para>
</section>
<section xml:id="ch062_audit-guidance-idp65008">
<title>Compliance Maintenance</title>
<title>Compliance maintenance</title>
<para>The process doesn't end with a single external audit. Most certifications require continual compliance activities which means repeating the audit process periodically. We recommend integrating automated compliance verification tools into a cloud to ensure that it is compliant at all times. This should be in done in addition to other security monitoring tools. Remember that the goal is both security <emphasis>and</emphasis> compliance. Failing on either of these fronts will significantly complicate future audits.</para>
</section>
</chapter>

27
doc/security-guide/ch063_compliance-activities.xml
View File

@@ -1,29 +1,34 @@
<?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="ch063_compliance-activities"><?dbhtml stop-chunking?>
<title>Compliance Activities</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch063_compliance-activities">
<?dbhtml stop-chunking?>
<title>Compliance activities</title>
<para>There are a number of standard activities that will greatly assist with the compliance process. In this chapter we outline some of the most common compliance activities. These are not specific to OpenStack, however we provide references to relevant sections in this book as useful context.</para>
<section xml:id="ch063_compliance-activities-idp44544">
<title>Information Security Management System (ISMS)</title>
<title>Information Security Management system (ISMS)</title>
<para>An Information Security Management System (ISMS) is a comprehensive set of policies and processes that an organization creates and maintains to manage risk to information assets. The most common ISMS for cloud deployments is <link xlink:href="http://www.27000.org/iso-27001.htm">ISO/IEC 27001/2</link>, which creates a solid foundation of security controls and practices for achieving more stringent compliance certifications.</para>
</section>
<section xml:id="ch063_compliance-activities-idp46224">
<title>Risk Assessment</title>
<title>Risk assessment</title>
<para>A Risk Assessment framework identifies risks within an organization or service, and specifies ownership of these risks, along with implementation and mitigation strategies. Risks apply to all areas of the service, from technical controls to environmental disaster scenarios and human elements, for example a malicious insider (or rogue employee). Risks can be rated using a variety of mechanisms, for example likelihood vs impact. An OpenStack deployment risk assessment can include control gaps that are described in this book.</para>
</section>
<section xml:id="ch063_compliance-activities-idp47920">
<title>Access &amp; Log Reviews</title>
<title>Access and log reviews</title>
<para>Periodic access and log reviews are required to ensure authentication, authorization, and accountability in a service deployment. Specific guidance for OpenStack on these topics are discussed in-depth in the logging section.</para>
</section>
<section xml:id="ch063_compliance-activities-idp49392">
<title>Backup and Disaster Recovery</title>
<title>Backup and disaster recovery</title>
<para>Disaster Recovery (DR) and Business Continuity Planning (BCP) plans are common requirements for ISMS and compliance activities. These plans must be periodically tested as well as documented. In OpenStack key areas are found in the management security domain, and anywhere that single points of failure (SPOFs) can be identified. See the section on secure backup and recovery for additional details.</para>
</section>
<section xml:id="ch063_compliance-activities-idp51008">
<title>Security Training</title>
<title>Security training</title>
<para>Annual, role-specific, security training is a mandatory requirement for almost all compliance certifications and attestations. To optimise the effectiveness of security training, a common method is to provide role specific training, for example to developers, operational personnel, and non-technical employees. Additional cloud security or OpenStack security training based on this hardening guide would be ideal.</para>
</section>
<section xml:id="ch063_compliance-activities-idp52592">
<title>Security Reviews</title>
<title>Security reviews</title>
<para>As OpenStack is a popular open source project, much of the
codebase and architecture has been scrutinized by individual
contributors, organizations and enterprises. This can be
@@ -40,15 +45,15 @@
Trustworthy Computing Initiative.</para>
</section>
<section xml:id="ch063_compliance-activities-idp54592">
<title>Vulnerability Management</title>
<title>Vulnerability management</title>
<para>Security updates are critical to any IaaS deployment, whether private or public. Vulnerable systems expand attack surfaces, and are obvious targets for attackers. Common scanning technologies and vulnerability notification services can help mitigate this threat. It is important that scans are authenticated and that mitigation strategies extend beyond simple perimeter hardening. Multi-tenant architectures such as OpenStack are particularly prone to hypervisor vulnerabilities, making this a critical part of the system for vulnerability management. See the section on instance isolation for additional details.</para>
</section>
<section xml:id="ch063_compliance-activities-idp56416">
<title>Data Classification</title>
<title>Data classification</title>
<para>Data Classification defines a method for classifying and handling information, often to protect customer information from accidental or deliberate theft, loss, or inappropriate disclosure. Most commonly this involves classifying information as sensitive or non-sensitive, or as personally identifiable information (PII). Depending on the context of the deployment various other classifying criteria may be used (government, health-care etc). The underlying principle is that data classifications are clearly defined and in-use. The most common protective mechanisms include industry standard encryption technologies. See the data security section for additional details.</para>
</section>
<section xml:id="ch063_compliance-activities-idp58256">
<title>Exception Process</title>
<title>Exception process</title>
<para>An exception process is an important component of an ISMS. When certain actions are not compliant with security policies that an organization has defined, they must be logged. Appropriate justification, description and mitigation details need to be included, and signed off by appropriate authorities. OpenStack default configurations may vary in meeting various compliance criteria, areas that fail to meet compliance requirements should be logged, with potential fixes considered for contribution to the community.</para>
</section>
</chapter>

20
doc/security-guide/ch064_certifications-compliance-statements.xml
View File

@@ -5,7 +5,7 @@
version="5.0"
xml:id="ch064_certifications-compliance-statements">
<?dbhtml stop-chunking?>
<title>Certification &amp; Compliance Statements</title>
<title>Certification and compliance statements</title>
<para>Compliance and security are not exclusive, and must be
addressed together. OpenStack deployments are unlikely to satisfy
compliance requirements without security hardening. The listing
@@ -14,7 +14,7 @@
certifications and standards.</para>
<section
xml:id="ch064_certifications-compliance-statements-idp44896">
<title>Commercial Standards</title>
<title>Commercial standards</title>
<para>For commercial deployments of OpenStack, it is recommended
that SOC 1/2 combined with ISO 2700 1/2 be considered as a
starting point for OpenStack certification activities. The
@@ -206,7 +206,7 @@
</section>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp8448">
<title>Government Standards</title>
<title>Government standards</title>
<section
xml:id="ch064_certifications-compliance-statements-idp9088">
<title>FedRAMP</title>
@@ -257,7 +257,7 @@
<itemizedlist>
<listitem>
<para><emphasis role="bold">System
Categorization</emphasis>The information system will
categorization:</emphasis> The information system will
receive a security category as defined in Federal
Information Processing Standards Publication 199 (FIPS
199). These categories reflect the potential impact of
@@ -265,7 +265,7 @@
</listitem>
<listitem>
<para><emphasis role="bold">Control
Selection</emphasis>Based upon system security category as
selection:</emphasis>Based upon system security category as
defined in FIPS 199, an organization utilizes FIPS 200 to
identify specific security control requirements for the
information system. For example, if a system is
@@ -273,11 +273,11 @@
to mandate “secure passwords.”</para>
</listitem>
<listitem>
<para><emphasis role="bold">Control Tailoring</emphasis>Once
system security controls are identified, an OpenStack
architect will utilize NIST 800-53 to extract tailored
control selection. For example, specification of what
constitutes a “secure password.”</para>
<para><emphasis role="bold">Control tailoring:</emphasis>
Once system security controls are identified, an OpenStack
architect will utilize NIST 800-53 to extract tailored
control selection. For example, specification of what
constitutes a “secure password.”</para>
</listitem>
</itemizedlist>
</section>

6
doc/security-guide/ch065_privacy.xml
View File

@@ -1,5 +1,9 @@
<?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="ch065_privacy"><?dbhtml stop-chunking?>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0" xml:id="ch065_privacy">
<?dbhtml stop-chunking?>
<title>Privacy</title>
<para>Privacy is an increasingly important element of a compliance program. Businesses are being held to a higher standard by their customers, who have increased interest in understanding how their data is treated from a privacy perspective.</para>
<para>An OpenStack deployment will likely need to demonstrate compliance with an organization’s Privacy Policy, with the U.S. – E.U. Safe Harbor framework, the ISO/IEC 29100:2011 privacy framework or with other privacy-specific guidelines. In the U.S. the AICPA has <link xlink:href="http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/generallyacceptedprivacyprinciples/">defined 10 privacy areas of focus</link>, OpenStack deployments within a commercial environment may desire to attest to some or all of these principles.</para>

13
doc/security-guide/ch066_case-studies-compliance.xml
View File

@@ -1,16 +1,21 @@
<?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="ch066_case-studies-compliance"><?dbhtml stop-chunking?>
<title>Case Studies: Compliance</title>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://docbook.org/ns/docbook"
version="5.0"
xml:id="ch066_case-studies-compliance">
<?dbhtml stop-chunking?>
<title>Case studies: compliance</title>
<para>In this case study we discuss how Alice and Bob would address common compliance requirements. The preceding chapter refers to a wide variety of compliance certifications and standards. Alice will address compliance in a private cloud, while Bob will be focused on compliance for a public cloud.</para>
<section xml:id="ch066_case-studies-compliance-idp44592">
<title>Alice's Private Cloud</title>
<title>Alice's private cloud</title>
<para>Alice is building an OpenStack private cloud for the United States government, specifically to provide elastic compute environments for signal processing. Alice has researched government compliance requirements, and has identified that her private cloud will be required to certify against FISMA and follow the FedRAMP accreditation process, which is required for all federal agencies, departments and contractors to become a Certified Cloud Provider (CCP). In this particular scenario for signal processing, the FISMA controls required will most likely be FISMA High, which indicates possible "severe or catastrophic adverse effects" should the information system become compromised. In addition to FISMA Moderate controls Alice must ensure her private cloud is FedRAMP certified, as this is a requirement for all agencies that currently utilize, or host federal information within a cloud environment.</para>
<para>To meet these strict government regulations Alice undertakes a number of activities. Scoping of requirements is particularly important due to the volume of controls that must be implemented, which will be defined in NIST Publication 800-53.</para>
<para>All technology within her private cloud must be FIPS certified technology, as mandated within NIST 800-53 and FedRAMP. As the U.S. Department of Defense is involved, Security Technical Implementation Guides (STIGs) will come into play, which are the configuration standards for DOD IA and IA-enabled devices / systems. Alice notices a number of complications here as there is no STIG for OpenStack, so she must address several underlying requirements for each OpenStack service; for example, the networking SRG and Application SRG will both be applicable (<link xlink:href="http://iase.disa.mil/srgs/index.html">list of SRGs</link>). Other critical controls include ensuring that all identities in the cloud use PKI, that SELinux is enabled, that encryption exists for all wire-level communications, and that continuous monitoring is in place and clearly documented. Alice is not concerned with object encryption, as this will be the tenants responsibility rather than the provider.</para>
<para>If Alice has adequately scoped and executed these compliance activities, she may begin the process to become FedRAMP compliant by hiring an approved third-party auditor. Typically this process takes up to 6 months, after which she will receive an Authority to Operate and can offer OpenStack cloud services to the government.</para>
</section>
<section xml:id="ch066_case-studies-compliance-idp49712">
<title>Bob's Public Cloud</title>
<title>Bob's public cloud</title>
<para>Bob is tasked with compliance for a new OpenStack public
cloud deployment, that is focused on providing cloud services to
both small developers and startups, as well as large