openstack/openstack-manuals
Code Issues Proposed changes

Removes security guide from this repo

Browse Source 
The Security Guide is in openstack/security-doc.

Adjust central pom.xml and test-languages.sh.

Change-Id: I2213a40da494a0d62c65e4a3d35074fab3e909f4
This commit is contained in:
Anne Gentle
2014-06-29 07:33:42 -05:00
committed by Andreas Jaeger
parent 278f3e1e9b
commit 10a6ad0a4f
148 changed files with 4 additions and 29738 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
doc/pom.xml
View File

@@ -16,7 +16,6 @@
<module>high-availability-guide</module>
<module>image-guide</module>
<module>install-guide</module>
<module>security-guide</module>
<module>user-guide</module>
<module>user-guide-admin</module>
</modules>

127
doc/security-guide/bk-openstack-sec-guide.xml
View File

@@ -1,127 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<book version="5.0" xml:id="os-security-guide"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>OpenStack Security Guide</title>
<info>
<author>
<personname>
<firstname/>
<surname/>
</personname>
<affiliation>
<orgname>OpenStack Foundation</orgname>
</affiliation>
</author>
<copyright>
<year>2013</year>
<holder>OpenStack Foundation</holder>
</copyright>
<releaseinfo>current</releaseinfo>
<productname>OpenStack</productname>
<pubdate/>
<legalnotice role="cc-by">
<annotation>
<remark>Copyright details are filled in by the
template.</remark>
</annotation>
</legalnotice>
<abstract>
<para>This book provides best practices and conceptual
information about securing an OpenStack cloud.</para>
</abstract>
<revhistory>
<!-- ... continue adding more revisions here as you change this document using the markup shown below... -->
<revision>
<date>2013-12-02</date>
<revdescription>
<itemizedlist>
<listitem>
<para>Chapter on Object Storage added.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2013-10-17</date>
<revdescription>
<itemizedlist>
<listitem>
<para>Havana release.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2013-07-02</date>
<revdescription>
<itemizedlist>
<listitem>
<para>Initial creation...</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
</revhistory>
</info>
<xi:include href="../common/ch_preface.xml"/>
<xi:include href="ch001_acknowledgements.xml"/>
<xi:include href="ch002_why-and-how-we-wrote-this-book.xml"/>
<xi:include href="ch004_book-introduction.xml"/>
<xi:include href="ch005_security-domains.xml"/>
<xi:include href="ch006_introduction-to-case-studies.xml"/>
<xi:include href="ch008_system-roles-types.xml"/>
<xi:include href="ch009_case-studies.xml"/>
<xi:include href="ch011_management-introduction.xml"/>
<xi:include href="ch012_configuration-management.xml"/>
<xi:include href="ch013_node-bootstrapping.xml"/>
<xi:include
href="ch014_best-practices-for-operator-mode-access.xml"/>
<xi:include href="ch015_case-studies-management.xml"/>
<xi:include
href="ch017_threat-models-confidence-and-confidentiality.xml"/>
<xi:include href="ch018_case-studies-pkissl.xml"/>
<xi:include href="ch020_ssl-everywhere.xml"/>
<xi:include href="ch021_paste-and-middleware.xml"/>
<xi:include href="ch022_case-studies-api-endpoints.xml"/>
<xi:include href="ch024_authentication.xml"/>
<xi:include href="ch025_web-dashboard.xml"/>
<xi:include href="ch026_compute.xml"/>
<xi:include href="ch027_storage.xml"/>
<xi:include href="ch028_case-studies-identity-management.xml"/>
<xi:include href="ch030_state-of-networking.xml"/>
<xi:include href="ch031_neutron-architecture.xml"/>
<xi:include href="ch032_networking-best-practices.xml"/>
<xi:include href="ch033_securing-neutron-services.xml"/>
<xi:include
href="ch034_tenant-secure-networking-best-practices.xml"/>
<xi:include href="ch035_case-studies-networking.xml"/>
<xi:include href="ch037_risks.xml"/>
<xi:include href="ch038_transport-security.xml"/>
<xi:include href="ch039_case-studies-messaging.xml"/>
<xi:include href="ch041_database-backend-considerations.xml"/>
<xi:include href="ch042_database-overview.xml"/>
<xi:include href="ch043_database-transport-security.xml"/>
<xi:include href="ch044_case-studies-database.xml"/>
<xi:include href="ch046_data-residency.xml"/>
<xi:include href="ch047_data-encryption.xml"/>
<xi:include href="ch048_key-management.xml"/>
<xi:include href="ch049_case-studies-tenant-data.xml"/>
<xi:include href="ch051_vss-intro.xml"/>
<xi:include href="ch052_devices.xml"/>
<xi:include href="ch053_case-studies-instance-isolation.xml"/>
<xi:include href="ch055_security-services-for-instances.xml"/>
<xi:include href="ch056_case-studies-instance-management.xml"/>
<xi:include href="ch058_forensicsincident-response.xml"/>
<xi:include href="ch059_case-studies-monitoring-logging.xml"/>
<xi:include href="ch061_compliance-overview.xml"/>
<xi:include href="ch062_audit-guidance.xml"/>
<xi:include href="ch063_compliance-activities.xml"/>
<xi:include href="ch064_certifications-compliance-statements.xml"/>
<xi:include href="ch065_privacy.xml"/>
<xi:include href="ch066_case-studies-compliance.xml"/>
<xi:include href="../common/app_support.xml"/>
<glossary role="auto"/>
</book>

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

@@ -1,19 +0,0 @@
<?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"
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>
<inlinemediaobject>
<imageobject role="html">
<imagedata contentdepth="900" contentwidth="600" fileref="static/book-sprint-all-logos.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/book-sprint-all-logos.png" format="PNG" scalefit="1" width="90%"/>
</imageobject>
</inlinemediaobject>
</para>
</chapter>

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

@@ -1,132 +0,0 @@
<?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"
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>
<section xml:id="ch002_why-and-how-we-wrote-this-book-idp117696">
<title>Objectives</title>
<itemizedlist><listitem>
<para>Identify the security domains in OpenStack</para>
</listitem>
<listitem>
<para>Provide guidance to secure your OpenStack deployment</para>
</listitem>
<listitem>
<para>Highlight security concerns and potential mitigations in present day OpenStack</para>
</listitem>
<listitem>
<para>Discuss upcoming security features</para>
</listitem>
<listitem>
<para>To provide a community driven facility for knowledge capture and dissemination</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch002_why-and-how-we-wrote-this-book-idp123024">
<title>How</title>
<para>As with the OpenStack Operations Guide, we followed the book sprint methodology. The book sprint process allows for rapid development and production of large bodies of written work. Coordinators from the OpenStack Security Group re-enlisted the services of Adam Hyde as facilitator. Corporate support was obtained and the project was formally announced during the OpenStack summit in Portland, Oregon.</para>
<para>The team converged in Annapolis, MD due to the close proximity of some key members of the group. This was a remarkable collaboration between public sector intelligence community members, silicon valley startups and some large, well-known technology companies. The book sprint ran during the last week in June 2013 and the first edition was created in five days.</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="450" contentwidth="540" fileref="static/group.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/group.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>The team included:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Bryan D. Payne</emphasis>, Nebula</para>
<para>Dr. Bryan D. Payne is the Director of Security Research at Nebula and co-founder of the OpenStack Security Group (OSSG). Prior to joining Nebula, he worked at Sandia National Labs, the National Security Agency, BAE Systems, and IBM Research. He graduated with a Ph.D. in Computer Science from the Georgia Tech College of Computing, specializing in systems security.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Robert Clark</emphasis>, HP</para>
<para>Robert Clark is the Lead Security Architect for HP Cloud Services and co-founder of the OpenStack Security Group (OSSG). Prior to being recruited by HP, he worked in the UK Intelligence Community. Robert has a strong background in threat modeling, security architecture and virtualization technology. Robert has a master's degree in Software Engineering from the University of Wales.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Keith Basil</emphasis>, Red Hat</para>
<para>Keith Basil is a Principal Product Manager for Red Hat OpenStack and is focused on Red Hat's OpenStack product management, development and strategy. Within the US public sector, Basil brings previous experience from the design of an authorized, secure, high-performance cloud architecture for Federal civilian agencies and contractors.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Cody Bunch</emphasis>, Rackspace</para>
<para>Cody Bunch is a Private Cloud architect with Rackspace. Cody has co-authored an update to "The OpenStack Cookbook" as well as books on VMware automation.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Malini Bhandaru</emphasis>, Intel</para>
<para>Malini Bhandaru is a security architect at Intel. She has a varied background, having worked on platform power and performance at Intel, speech products at Nuance, remote monitoring and management at ComBrio, and web commerce at Verizon. She has a Ph.D. in Artificial Intelligence from the University of Massachusetts, Amherst.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Gregg Tally</emphasis>, Johns Hopkins University Applied Physics Laboratory</para>
<para>Gregg Tally is the Chief Engineer at JHU/APL's Cyber Systems Group within the Asymmetric Operations Department. He works primarily in systems security engineering. Previously, he has worked at SPARTA, McAfee, and Trusted Information Systems where he was involved in cyber security research projects.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Eric Lopez</emphasis>, VMware</para>
<para>Eric Lopez is Senior Solution Architect at VMware's Networking and Security Business Unit where he helps customers implement OpenStack and VMware NSX (formerly known as Nicira's Network Virtualization Platform). Prior to joining VMware (through the company's acquisition of Nicira), he worked for Q1 Labs, Symantec, Vontu, and Brightmail. He has a B.S in Electrical Engineering/Computer Science and Nuclear Engineering from U.C. Berkeley and MBA from the University of San Francisco.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Shawn Wells</emphasis>, Red Hat</para>
<para>Shawn Wells is the Director, Innovation Programs at Red Hat, focused on improving the process of adopting, contributing to, and managing open source technologies within the U.S. Government. Additionally, Shawn is an upstream maintainer of the SCAP Security Guide project which forms virtualization and operating system hardening policy with the U.S. Military, NSA, and DISA. Formerly an NSA civilian, Shawn developed SIGINT collection systems utilizing large distributed computing infrastructures.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Ben de Bont</emphasis>, HP</para>
<para>Ben de Bont is the CSO for HP Cloud Services. Prior to his current role Ben led the information security group at MySpace and the incident response team at MSN Security. Ben holds a master's degree in Computer Science from the Queensland University of Technology.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Nathanael Burton</emphasis>, National Security Agency</para>
<para>Nathanael Burton is a Computer Scientist at the National Security Agency. He has worked for the Agency for over 10 years working on distributed systems, large-scale hosting, open source initiatives, operating systems, security, storage, and virtualization technology. He has a B.S. in Computer Science from Virginia Tech.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Vibha Fauver</emphasis></para>
<para>Vibha Fauver, GWEB, CISSP, PMP, has over fifteen years of experience in Information Technology. Her areas of specialization include software engineering, project management and information security. She has a B.S. in Computer &amp; Information Science and a M.S. in Engineering Management with specialization and a certificate in Systems Engineering.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Eric Windisch</emphasis>, Cloudscaling</para>
<para>Eric Windisch is a Principal Engineer at Cloudscaling where he has been contributing to OpenStack for over two years. Eric has been in the trenches of hostile environments, building tenant isolation and infrastructure security through more than a decade of experience in the web hosting industry. He has been building cloud computing infrastructure and automation since 2007.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Andrew Hay</emphasis>, CloudPassage</para>
<para>Andrew Hay is the Director of Applied Security Research at CloudPassage, Inc. where he leads the security research efforts for the company and its server security products purpose-built for dynamic public, private, and hybrid cloud hosting environments.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Adam Hyde</emphasis></para>
<para>Adam facilitated this Book Sprint. He also founded the Book Sprint methodology and is the most experienced Book Sprint facilitator around. Adam founded FLOSS Manuals—a community of some 3,000 individuals developing Free Manuals about Free Software. He is also the founder and project manager for Booktype, an open source project for writing, editing, and publishing books online and in print.</para>
</listitem>
</itemizedlist>
<para>During the sprint we also had help from Anne Gentle, Warren Wang, Paul McMillan, Brian Schott and Lorin Hochstein.</para>
<para>This Book was produced in a 5 day book sprint. A book
sprint is an intensely collaborative, facilitated process which
brings together a group to produce a book in 3-5 days. It is a
strongly facilitated process with a specific methodology founded
and developed by Adam Hyde. For more information visit the book
sprint web page at
<link xlink:href="http://www.booksprints.net">http://www.booksprints.net</link>.
</para>
<para>After initial publication, the following added new content:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Rodney D. Beede</emphasis>,
Seagate Technology
</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.
in Computer Science from the University of Colorado.
</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch002_why-and-how-we-wrote-this-book-idp150816">
<title>How to contribute to this book</title>
<para>The initial work on this book was conducted in an overly
air-conditioned room that served as our group office for the
entirety of the documentation sprint.</para>
<para>Learn more about how to contribute to the OpenStack
docs: <link xlink:href="http://wiki.openstack.org/Documentation/HowTo">http://wiki.openstack.org/Documentation/HowTo</link>.
</para>
</section>
</chapter>

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

@@ -1,237 +0,0 @@
<?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"
version="5.0"
xml:id="ch004_book-introduction">
<?dbhtml stop-chunking?>
<title>Introduction to OpenStack</title>
<para>This guide provides security insight into OpenStack
deployments. The intended audience is cloud architects, deployers,
and administrators. In addition, cloud users will find the guide
both educational and helpful in provider selection, while auditors
will find it useful as a reference document to support their
compliance certification efforts. This guide is also recommended
for anyone interested in cloud security.</para>
<para>Each OpenStack deployment embraces a wide variety of
technologies, spanning Linux distributions, database systems,
messaging queues, OpenStack components themselves, access control
policies, logging services, security monitoring tools, and much
more. It should come as no surprise that the security issues
involved are equally diverse, and their in-depth analysis would
require several guides. We strive to find a balance, providing
enough context to understand OpenStack security issues and their
handling, and provide external references for further information.
The guide could be read from start to finish or sampled as
necessary like a reference.</para>
<para>We briefly introduce the kinds of clouds: private, public, and
hybrid before presenting an overview of the OpenStack components
and their related security concerns in the remainder of the
chapter.</para>
<section xml:id="ch004_book-introduction-idp117824">
<title>Cloud types</title>
<para>OpenStack is a key enabler in adoption of cloud technology
and has several common deployment use cases. These are commonly
known as Public, Private, and Hybrid models. The following
sections use the National Institute of Standards and Technology
(NIST) <link
xlink:href="http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf"
>definition of cloud</link> to introduce these different types
of cloud as they apply to OpenStack.</para>
<section xml:id="ch004_book-introduction-idp119328">
<title>Public cloud</title>
<para>According to NIST, a public cloud is one in which the
infrastructure is open to the general public for consumption.
OpenStack public clouds are typically run by a service
provider and can be consumed by individuals, corporations, or
any paying customer. A public cloud provider may expose a full
set of features such as software-defined networking, block
storage, in addition to multiple instance types. Due to the
nature of public clouds, they are exposed to a higher degree
of risk. As a consumer of a public cloud you should validate
that your selected provider has the necessary certifications,
attestations, and other regulatory considerations. As a public
cloud provider, depending on your target customers, you may be
subject to one or more regulations. Additionally, even if not
required to meet regulatory requirements, a provider should
ensure tenant isolation as well as protecting management
infrastructure from external attacks.</para>
</section>
<section xml:id="ch004_book-introduction-idp121488">
<title>Private cloud</title>
<para>At the opposite end of the spectrum is the private cloud.
As NIST defines it, a private cloud is provisioned for
exclusive use by a single organization comprising multiple
consumers, such as business units. It may be owned, managed,
and operated by the organization, a third-party, or some
combination of them, and it may exist on or off premises.
Private cloud use cases are diverse, as such, their individual
security concerns vary.</para>
</section>
<section xml:id="ch004_book-introduction-idp123456">
<title>Community cloud</title>
<para>NIST defines a community cloud as one whose
infrastructure is provisioned for the exclusive use by a
specific community of consumers from organizations that have
shared concerns. For example, mission, security requirements,
policy, and compliance considerations. It may be owned,
managed, and operated by one or more of the organizations in
the community, a third-party, or some combination of them, and
it may exist on or off premises.</para>
</section>
<section xml:id="ch004_book-introduction-idp125312">
<title>Hybrid cloud</title>
<para>A hybrid cloud is defined by NIST as a composition of two
or more distinct cloud infrastructures, such as private, community, or
public, that remain unique entities, but are bound together by
standardized or proprietary technology that enables data and
application portability, such as cloud bursting for load
balancing between clouds. For example an online retailer may
have their advertising and catalogue presented on a public
cloud that allows for elastic provisioning. This would enable
them to handle seasonal loads in a flexible, cost-effective
fashion. Once a customer begins to process their order, they
are transferred to the more secure private cloud backend that
is PCI compliant.</para>
<para>For the purposes of this document, we treat Community and
Hybrid similarly, dealing explicitly only with the extremes of
Public and Private clouds from a security perspective. Your
security measures depend where your deployment falls upon the
private public continuum.</para>
</section>
</section>
<section xml:id="ch004_book-introduction-idp128528">
<title>OpenStack service overview</title>
<para>OpenStack embraces a modular architecture to provide a set
of core services that facilitates scalability and elasticity as
core design tenets. This chapter briefly reviews OpenStack
components, their use cases and security considerations.</para>
<para><inlinemediaobject>
<imageobject role="html">
<imagedata contentdepth="374" contentwidth="976"
fileref="static/marketecture-diagram.png" format="PNG"
scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/marketecture-diagram.png" format="PNG"
scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<section xml:id="ch004_book-introduction-idp134736">
<title>Compute</title>
<para>OpenStack Compute service (nova) provides services to
support the management of virtual machine instances at scale,
instances that host multi-tiered applications, dev/test
environments, "Big Data" crunching Hadoop clusters, and/or
high performance computing.</para>
<para>The Compute service facilitates this management through an
abstraction layer that interfaces with supported hypervisors,
which we address later on in more detail.</para>
<para>Later in the guide, we focus generically on the
virtualization stack as it relates to hypervisors.</para>
<para>For information about the current state of feature
support, see <link
xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
>OpenStack Hypervisor Support Matrix</link>.</para>
<para>The security of Compute is critical for an OpenStack
deployment. Hardening techniques should include support for
strong instance isolation, secure communication between
Compute sub-components, and resiliency of public-facing
<glossterm>API</glossterm> endpoints.</para>
</section>
<section xml:id="ch004_book-introduction-idp138800">
<title>Object Storage</title>
<para>The OpenStack Object Storage service (swift) provides
support for storing and retrieving arbitrary data in the
cloud. The Object Storage service provides both a native API
and an Amazon Web Services S3 compatible API. The service
provides a high degree of resiliency through data replication
and can handle petabytes of data.</para>
<para>It is important to understand that object storage differs
from traditional file system storage. It is best used for
static data such as media files (MP3s, images, videos),
virtual machine images, and backup files.</para>
<para>Object security should focus on access control and
encryption of data in transit and at rest. Other concerns may
relate to system abuse, illegal or malicious content storage,
and cross authentication attack vectors.</para>
</section>
<section xml:id="ch004_book-introduction-idp141536">
<title>Block Storage</title>
<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
instances, to their release.</para>
<para>Security considerations for block storage are similar to
that of object storage.</para>
</section>
<section xml:id="ch004_book-introduction-idp143424">
<title>OpenStack Networking</title>
<para>The OpenStack Networking service (neutron, previously
called quantum) provides various networking services to cloud
users (tenants) such as IP address management,
<glossterm>DNS</glossterm>, <glossterm>DHCP</glossterm>,
load balancing, and security groups (network access rules,
like firewall policies). It provides a framework for software
defined networking (SDN) that allows for pluggable integration
with various networking solutions.</para>
<para>OpenStack Networking allows cloud tenants to manage their
guest network configurations. Security concerns with the
networking service include network traffic isolation,
availability, integrity and confidentiality.</para>
</section>
<section xml:id="ch004_book-introduction-idp145600">
<title>Dashboard</title>
<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
commonly deployed in a public facing manner with all the usual
security concerns of public web portals.</para>
</section>
<section xml:id="ch004_book-introduction-idp147104">
<title>Identity service</title>
<para>The OpenStack Identity service (keystone) is a <emphasis
role="bold">shared service</emphasis> that provides
authentication and authorization services throughout the
entire cloud infrastructure. The Identity service has
pluggable support for multiple forms of authentication.</para>
<para>Security concerns here pertain to trust in authentication,
management of authorization tokens, and secure
communication.</para>
</section>
<section xml:id="ch004_book-introduction-idp149712">
<title>Image Service</title>
<para>The OpenStack Image Service (glance) provides disk image
management services. The Image Service provides image
discovery, registration, and delivery services to the
Compute service, as needed.</para>
<para>Trusted processes for managing the life cycle of disk
images are required, as are all the previously mentioned
issues with respect to data security.</para>
</section>
<section xml:id="ch004_book-introduction-idp152400">
<title>Other supporting technology</title>
<para>OpenStack relies on messaging for internal communication
between several of its services. By default, OpenStack uses
message queues based on the Advanced Message Queue Protocol
(<glossterm baseform="Advanced Message Queuing Protocol (AMQP)">AMQP
</glossterm>). Similar to most OpenStack services, it supports
pluggable components. Today the implementation backend could be
<glossterm>RabbitMQ</glossterm>,
<glossterm>Qpid</glossterm>, or
<glossterm>ZeroMQ</glossterm>.</para>
<para>As most management commands flow through the message
queueing system, it is a primary security concern for any
OpenStack deployment. Message queueing security is discussed
in detail later in this guide.</para>
<para>Several of the components use databases though it is not
explicitly called out. Securing the access to the databases
and their contents is yet another security concern, and
consequently discussed in more detail later in this
guide.</para>
</section>
</section>
</chapter>

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

@@ -1,180 +0,0 @@
<?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"
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>
<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>
<para>Public</para>
</listitem>
<listitem>
<para>Guest</para>
</listitem>
<listitem>
<para>Management</para>
</listitem>
<listitem>
<para>Data</para>
</listitem>
</orderedlist>
<para>We selected these security domains because they can be mapped independently or combined to represent the majority of the possible areas of trust within a given OpenStack deployment. For example, some deployment topologies combine both guest and data domains onto one physical network versus others, which have these networks physically separated. In each case, the cloud operator should be aware of the appropriate security concerns. Security domains should be mapped out against your specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid.</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="298" contentwidth="338" fileref="static/untrusted_trusted.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/untrusted_trusted.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<section xml:id="ch005_security-domains-idp50384">
<title>Public</title>
<para>The public security domain is an entirely untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks over which you have no authority. Any data that transits this domain with confidentiality or integrity requirements should be protected using compensating controls.</para>
<para>This domain should always be considered <emphasis>untrusted</emphasis>.</para>
</section>
<section xml:id="ch005_security-domains-idp52768">
<title>Guest</title>
<para>Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud but not services that support the operation of the cloud, such as API calls.</para>
<para>Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to VMs should consider this domain to be <emphasis>untrusted</emphasis>. Private cloud providers may want to consider this network as internal and therefore <emphasis>trusted</emphasis> only if they have controls in place to assert that they trust instances and all their tenants.</para>
</section>
<section xml:id="ch005_security-domains-idp55632">
<title>Management</title>
<para>The management security domain is where services interact. Sometimes referred to as the "control plane", the networks in this domain transport confidential data such as configuration parameters, usernames, and passwords. Command and Control traffic typically resides in this domain, which necessitates strong integrity requirements. Access to this domain should be highly restricted and monitored. At the same time, this domain should still employ all of the security best practices described in this guide.</para>
<para>In most deployments this domain is considered <emphasis>trusted</emphasis>. However, when considering an OpenStack deployment, there are many systems that bridge this domain with others, potentially reducing the level of trust you can place on this domain. See <xref linkend="ch005_security-domains-idp61360" /> for more information.</para>
</section>
<section xml:id="ch005_security-domains-idp59216">
<title>Data</title>
<para>The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. Much of the data that crosses this network has high integrity and confidentiality requirements and depending on the type of deployment there may also be strong availability requirements.</para>
<para>The trust level of this network is heavily dependent on deployment decisions and as such we do not assign this any default level of trust.</para>
</section>
</section>
<section xml:id="ch005_security-domains-idp61360">
<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"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/bridging_security_domains_1.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>The diagram above shows a compute node bridging the data and management domains, as such the compute node should be configured to meet the security requirements of the management domain. Similarly the API Endpoint in this diagram is bridging the untrusted public domain and the management domain, and should be configured to protect against attacks from the public domain propagating through to the management domain.</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="418" contentwidth="559" fileref="static/bridging_domains_clouduser.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/bridging_domains_clouduser.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>In some cases deployers may want to consider securing a bridge to a higher standard than any of the domains in which it resides. Given the above example of an API endpoint, an adversary could potentially target the API endpoint from the public domain, leveraging it in the hopes of compromising or gaining access to the management domain.</para>
<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>
<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>
<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>
</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>
<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>
<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>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="403" contentwidth="472" fileref="static/threat_actors.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/threat_actors.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
</section>
<section xml:id="ch005_security-domains-idp111680">
<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>
</section>
<section xml:id="ch005_security-domains-idp116736">
<title>Outbound attacks and reputational risk</title>
<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 or entitled access, such as 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. The issue is more
pressing 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>
<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"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/high-capability.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>The prescriptive defense for each form of attack is beyond the scope of this document. The above diagram can assist you in making an informed decision about which types of threats, and threat actors, should be protected against. For commercial public cloud deployments this might include prevention against serious crime. For those deploying private clouds for government use, more stringent protective mechanisms should be in place, including carefully protected facilities and supply chains. In contrast those standing up basic development or test environments will likely require less restrictive controls (middle of the spectrum).</para>
</section>
</section>
</chapter>

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

@@ -1,34 +0,0 @@
<?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"
version="5.0"
xml:id="ch006_introduction-to-case-studies">
<?dbhtml stop-chunking?>
<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>
<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
for this cloud are very high. It must have no direct access to
the internet: its API endpoints, compute instances, and other
resources must be exposed to only systems within the
department's network, which is entirely air-gapped from all
other networks. The cloud can access other network services on
the organization's intranet such as the authentication and
logging services.</para>
</section>
<section xml:id="ch006_introduction-to-case-studies-idp46720">
<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
utility computing and storage, but the primary focus is
enterprise customers. Data privacy concerns are a big priority
for Bob as they are seen as a major barrier to large-scale
adoption of the cloud by organizations.</para>
</section>
</chapter>

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

@@ -1,114 +0,0 @@
<?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"
version="5.0"
xml:id="ch008_system-roles-types">
<?dbhtml stop-chunking?>
<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
often have compliance requirements which may require an overall
System Security Plan to inventory and document the architecture of
a given system. There are common challenges across the industry
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 and types</title>
<para>The two broadly defined types of
nodes that generally make up an OpenStack installation are:</para>
<itemizedlist>
<listitem>
<para>Infrastructure nodes. The nodes that run the cloud
related services such as the OpenStack Identity Service, the
message queuing service, storage, networking, and other
services required to support the operation of the
cloud.</para>
</listitem>
<listitem>
<para>Compute, storage, or other
resource nodes. Provide storage capacity or
virtual machines for your cloud.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch008_system-roles-types-idp48496">
<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,
networks, services, and software often provides the bird's-eye
view needed to thoroughly cover and consider security concerns,
attack vectors and possible security domain bridging points. A
system inventory may need to capture ephemeral resources such as
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>
<para>Clouds without stringent compliance requirements for
written documentation might benefit from having a
Configuration Management Database
(<glossterm>CMDB</glossterm>). CMDBs are normally used for
hardware asset tracking and overall life-cycle management. By
leveraging a CMDB, an organization can quickly identify cloud
infrastructure hardware. For example, compute nodes, storage
nodes, and network devices that exist on the network but that might
not be adequately protected and/or forgotten. OpenStack
provisioning system might provide some CMDB-like functions
especially if auto-discovery features of hardware attributes
are available.</para>
</section>
<section xml:id="ch008_system-roles-types-idp53536">
<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
and supporting sub-components; and, supporting infrastructure
software such as load-balancers, reverse proxies, and network
address translators. Having an authoritative list like this
may be critical toward understanding total system impact due
to a compromise or vulnerability of a specific class of
software.</para>
</section>
</section>
<section xml:id="ch008_system-roles-types-idp55328">
<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
boundaries. Multiple diagrams may be needed to provide complete
visual coverage of the system. A network topology document
should include virtual networks created on behalf of tenants by
the system along with virtual machine instances and gateways
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
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.
Firewall configuration, service port conflicts, security
remediation areas, and compliance requirements become easier to
manage when you have concise information available. Consider the
following table:</para>
<para><inlinemediaobject>
<imageobject role="html">
<imagedata contentdepth="166" contentwidth="967"
fileref="static/services-protocols-ports.png" format="PNG"
scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/services-protocols-ports.png" format="PNG"
scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>Referencing a table of services, protocols and ports can
help in understanding the relationship between OpenStack
components. It is highly recommended that OpenStack deployments
have information similar to this on record.</para>
</section>
</chapter>

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

@@ -1,19 +0,0 @@
<?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"
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>
<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>
<para>In this case, Bob will approach these steps the same as Alice.</para>
</section>
</chapter>

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

@@ -1,12 +0,0 @@
<?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"
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>
</chapter>

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

@@ -1,324 +0,0 @@
<?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"
version="5.0"
xml:id="ch012_configuration-management">
<?dbhtml stop-chunking?>
<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.
This involves smart use of configuration management tools, which
are discussed below. This also involves knowing when an upgrade is
necessary.</para>
<section xml:id="ch012_configuration-management-idp44720">
<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"
>OpenStack Announce mailing list</link>. The security
notifications are also posted through the downstream packages
for example through Linux distributions that you may be
subscribed to as part of the package updates.</para>
<para>The OpenStack components are only a small fraction of the
software in a cloud. It is important to keep up to date with all
of these other components, too. While the specific data sources
will be deployment specific, the key idea is to ensure that a
cloud administrator subscribes to the necessary mailing lists
for receiving notification of any related security updates.
Often this is as simple as tracking an upstream Linux
distribution.</para>
<note>
<para>OpenStack releases security information through two
channels. <itemizedlist>
<listitem>
<para>OpenStack Security Advisories (OSSA) are created by
the OpenStack Vulnerability Management Team (VMT). They
pertain to security holes in core OpenStack services.
More information on the VMT can be found here: <link
xlink:href="https://wiki.openstack.org/wiki/Vulnerability_Management"
>https://wiki.openstack.org/wiki/Vulnerability_Management</link></para>
</listitem>
<listitem>
<para>OpenStack Security Notes (OSSN) are created by the
OpenStack Security Group (OSSG) to support the work of
the VMT. OSSN address issues in supporting software and
common deployment configurations. They're referenced
throughout this guide. Security Notes are archived at
<link xlink:href="https://launchpad.net/ossn/"
>https://launchpad.net/ossn/</link></para>
</listitem>
</itemizedlist>
</para>
</note>
<section xml:id="ch012_configuration-management-idp48592">
<title>Triage</title>
<para>After you are notified of a security update, the next step
is to determine how critical this update is to a given cloud
deployment. In this case, it is useful to have a pre-defined
policy. Existing vulnerability rating systems such as the
common vulnerability scoring system (CVSS) v2 do not properly
account for cloud deployments.</para>
<para>In this example we introduce a scoring matrix that places
vulnerabilities in three categories: Privilege Escalation,
Denial of Service and Information Disclosure. Understanding
the type of vulnerability and where it occurs in your
infrastructure will enable you to make reasoned response
decisions.</para>
<para>Privilege Escalation describes the ability of a user to
act with the privileges of some other user in a system,
bypassing appropriate authorization checks. For example, a
standard Linux user running code or performing an operation
that allows them to conduct further operations with the
privileges of the root users on the system.</para>
<para>Denial of Service refers to an exploited vulnerability
that may cause service or system disruption. This includes
both distributed attacks to overwhelm network resources, and
single-user attacks that are typically caused through resource
allocation bugs or input induced system failure flaws.</para>
<para>Information Disclosure vulnerabilities reveal information
about your system or operations. These vulnerabilities range
from debugging information disclosure, to exposure of critical
security data, such as authentication credentials and
passwords.</para>
<informaltable rules="all" width="80%">
<colgroup>
<col/>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<tbody>
<tr>
<td><para> </para></td>
<td colspan="4"><para><emphasis>Attacker position /
Privilege level</emphasis></para></td>
</tr>
<tr>
<td><para><emphasis role="bold"> </emphasis></para></td>
<td><para><emphasis role="bold"
>External</emphasis></para></td>
<td><para><emphasis role="bold">Cloud
user</emphasis></para></td>
<td><para><emphasis role="bold">Cloud
admin</emphasis></para></td>
<td><para><emphasis role="bold">Control
plane</emphasis></para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Privilege elevation (3
levels)</emphasis></para></td>
<td><para>Critical</para></td>
<td><para>n/a</para></td>
<td><para>n/a</para></td>
<td><para>n/a</para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Privilege elevation (2
levels)</emphasis></para></td>
<td><para>Critical</para></td>
<td><para>Critical</para></td>
<td><para>n/a</para></td>
<td><para>n/a</para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Privilege elevation (1
level)</emphasis></para></td>
<td><para>Critical</para></td>
<td><para>Critical</para></td>
<td><para>Critical</para></td>
<td><para>n/a</para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Denial of
service</emphasis></para></td>
<td><para>High</para></td>
<td><para>Medium</para></td>
<td><para>Low</para></td>
<td><para>Low</para></td>
</tr>
<tr>
<td><para><emphasis role="bold">Information
disclosure</emphasis></para></td>
<td><para>Critical / high</para></td>
<td><para>Critical / high</para></td>
<td><para>Medium / low</para></td>
<td><para>Low</para></td>
</tr>
</tbody>
</informaltable>
<para>This table illustrates a generic approach to
measuring the impact of a vulnerability based on where it
occurs in your deployment and the effect. For example, a
single level privilege escalation on a Compute API node
potentially allows a standard user of the API to escalate to
have the same privileges as the root user on the node.</para>
<para>We suggest that cloud administrators use this table as a
model to help define which actions to take for the various
security levels. For example, a critical-level security update
might require the cloud to be upgraded on a specified time
line, whereas a low-level update might be more relaxed.</para>
</section>
<section xml:id="ch012_configuration-management-idp100864">
<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
cloud should be as close to the production cloud as possible,
in terms of software and hardware. Updates should be tested
thoroughly in terms of performance impact, stability,
application impact, and more. Especially important is to
verify that the problem theoretically addressed by the update,
such as a specific vulnerability, is actually fixed.</para>
</section>
<section xml:id="ch012_configuration-management-idp102976">
<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
below.</para>
</section>
</section>
<section xml:id="ch012_configuration-management-idp104464">
<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.
Automation also helps with continuous integration and
testing.</para>
<para>When building an OpenStack cloud it is strongly recommended
to approach your design and implementation with a configuration
management tool or framework in mind. Configuration management
allows you to avoid the many pitfalls inherent in building,
managing, and maintaining an infrastructure as complex as
OpenStack. By producing the manifests, cookbooks, or templates
required for a configuration management utility, you are able to
satisfy a number of documentation and regulatory reporting
requirements. Further, configuration management can also
function as part of your BCP and DR plans wherein you can
rebuild a node or service back to a known state in a DR event or
given a compromise.</para>
<para>Additionally, when combined with a version control system
such as Git or SVN, you can track changes to your environment
over time and re-mediate unauthorized changes that may occur.
For example, a <filename>nova.conf</filename> file or other
configuration file falls out of compliance with your standard,
your configuration management tool can revert or replace the
file and bring your configuration back into a known state.
Finally a configuration management tool can also be used to
deploy updates; simplifying the security patch process. These
tools have a broad range of capabilities that are useful in this
space. The key point for securing your cloud is to choose a tool
for configuration management and use it.</para>
<para>There are many configuration management solutions; at the
time of this writing there are two in the marketplace that are
robust in their support of OpenStack environments:
<glossterm>Chef</glossterm> and <glossterm>Puppet</glossterm>.
A non-exhaustive listing of tools in this space is provided
below:</para>
<itemizedlist>
<listitem>
<para>Chef</para>
</listitem>
<listitem>
<para>Puppet</para>
</listitem>
<listitem>
<para>Salt Stack</para>
</listitem>
<listitem>
<para>Ansible</para>
</listitem>
</itemizedlist>
<section xml:id="ch012_configuration-management-idp8400">
<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
stored in a version controlled repository such as git.</para>
</section>
</section>
<section xml:id="ch012_configuration-management-idp10160">
<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>
<itemizedlist>
<listitem>
<para>Ensure only authenticated users and backup clients
have access to the backup server.</para>
</listitem>
<listitem>
<para>Use data encryption options for storage and
transmission of backups.</para>
</listitem>
<listitem>
<para>Use a dedicated and hardened backup servers. The logs
for the backup server must be monitored daily and
accessible by only few individuals.</para>
</listitem>
<listitem>
<para>Test data recovery options regularly. One of the
things that can be restored from secured backups is the
images. In case of a compromise, the best practice would
be to terminate running instances immediately and then
relaunch the instances from the images in the secured
backup repository.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch012_configuration-management-idp128032">
<title>References</title>
<itemizedlist>
<listitem>
<para><citetitle>OpenStack Operations Guide</citetitle> on
<link
xlink:href="http://docs.openstack.org/openstack-ops/content/backup_and_recovery.html"
>backup and recovery</link></para>
</listitem>
<listitem>
<para><link
xlink:href="http://www.sans.org/reading_room/whitepapers/backup/security-considerations-enterprise-level-backups_515"
>http://www.sans.org/reading_room/whitepapers/backup/security-considerations-enterprise-level-backups_515</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.music-piracy.com/?p=494"
>OpenStack Security Primer</link></para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="ch012_configuration-management-idp131856">
<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
satisfied for a given system configuration. These tools help to
bridge the gap from security configuration guidance
documentation (for example, the STIG and NSA Guides) to a
specific system installation. For example, <link
xlink:href="https://fedorahosted.org/scap-security-guide/"
>SCAP</link> can compare a running system to a pre-defined
profile. SCAP outputs a report detailing which controls in the
profile were satisfied, which ones failed, and which ones were
not checked.</para>
<para>Combining configuration management and security auditing
tools creates a powerful combination. The auditing tools will
highlight deployment concerns. And the configuration management
tools simplify the process of changing each system to address
the audit concerns. Used together in this fashion, these tools
help to maintain a cloud that satisfies security requirements
ranging from basic hardening to compliance validation.</para>
<para>Configuration management and security auditing tools will
introduce another layer of complexity into the cloud. This
complexity brings additional security concerns with it. We view
this as an acceptable risk trade-off, given their security
benefits. Securing the operational use of these tools is beyond
the scope of this guide.</para>
</section>
</chapter>

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

@@ -1,399 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter [
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
%openstack;
]>
<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="ch013_node-bootstrapping">
<?dbhtml stop-chunking?>
<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.
This process begins with secure bootstrapping and is maintained
through configuration management and security monitoring. This
chapter provides recommendations on how to approach the integrity
life-cycle process.</para>
<section xml:id="ch013_node-bootstrapping-idp44768">
<title>Secure bootstrapping</title>
<para>Nodes in the cloud&mdash;including compute, storage, network,
service, and hybrid nodes&mdash;should have an automated
provisioning process. This ensures that nodes are provisioned
consistently and correctly. This also facilitates security
patching, upgrading, bug fixing, and other critical changes.
Since this process installs new software that runs at the
highest privilege levels in the cloud, it is important to verify
that the correct software is installed. This includes the
earliest stages of the boot process.</para>
<para>There are a variety of technologies that enable verification
of these early boot stages. These typically require hardware
support such as the trusted platform module (TPM), Intel Trusted
Execution Technology (TXT), dynamic root of trust measurement
(DRTM), and Unified Extensible Firmware Interface (UEFI) secure
boot. In this book, we will refer to all of these collectively
as <emphasis>secure boot technologies</emphasis>. We recommend
using secure boot, while acknowledging that many of the pieces
necessary to deploy this require advanced technical skills in
order to customize the tools for each environment. Utilizing
secure boot will require deeper integration and customization
than many of the other recommendations in this guide. TPM
technology, while common in most business class laptops and
desktops for several years, and is now becoming available in
servers together with supporting BIOS. Proper planning is
essential to a successful secure boot deployment.</para>
<para>A complete tutorial on secure boot deployment is beyond the
scope of this book. Instead, here we provide a framework for how
to integrate secure boot technologies with the typical node
provisioning process. For additional details, cloud architects
should refer to the related specifications and software
configuration manuals.</para>
<section xml:id="ch013_node-bootstrapping-idp48720">
<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
receiving various boot stages&mdash;that is progressively more
complex software to execute&mdash; from a server.</para>
<para><inlinemediaobject>
<imageobject role="html">
<imagedata contentdepth="203" contentwidth="274"
fileref="static/node-provisioning-pxe.png" format="PNG"
scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/node-provisioning-pxe.png" format="PNG"
scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>We recommend using a separate, isolated network within the
management security domain for provisioning. This network will
handle all PXE traffic, along with the subsequent boot stage
downloads depicted above. Note that the node boot process
begins with two insecure operations: DHCP and TFTP. Then the
boot process downloads over SSL the remaining information
required to deploy the node. This information might include an
initramfs and a kernel. This concludes by downloading the
remaining information needed to deploy the node. This may be
an operating system installer, a basic install managed by
<link xlink:href="http://www.opscode.com/chef/">Chef</link>
or <link xlink:href="https://puppetlabs.com/">Puppet</link>,
or even a complete file system image that is written directly
to disk.</para>
<para>While utilizing SSL during the PXE boot process is
somewhat more challenging, common PXE firmware projects, such
as iPXE, provide this support. Typically this involves
building the PXE firmware with knowledge of the allowed SSL
certificate chain(s) so that it can properly validate the
server certificate. This raises the bar for an attacker by
limiting the number of insecure, plain text network
operations.</para>
</section>
<section xml:id="ch013_node-bootstrapping-idp58144">
<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
the process, and stop the boot if code is incorrect.
<emphasis>Boot attestation</emphasis> will record which code
is run at each step, and provide this information to another
machine as proof that the boot process completed as expected.
In both cases, the first step is to measure each piece of code
before it is run. In this context, a measurement is
effectively a SHA-1 hash of the code, taken before it is
executed. The hash is stored in a platform configuration
register (PCR) in the TPM.</para>
<para>Note: SHA-1 is used here because this is what the TPM
chips support.</para>
<para>Each TPM has at least 24 PCRs. The TCG Generic Server
Specification, v1.0, March 2005, defines the PCR assignments
for boot-time integrity measurements. The table below shows a
typical PCR configuration. The context indicates if the values
are determined based on the node hardware (firmware) or the
software provisioned onto the node. Some values are influenced
by firmware versions, disk sizes, and other low-level
information. Therefore, it is important to have good practices
in place around configuration management to ensure that each
system deployed is configured exactly as desired.</para>
<informaltable rules="all" width="80%">
<colgroup>
<col/>
<col/>
<col/>
</colgroup>
<tbody>
<tr>
<td><para><emphasis role="bold"
>Register</emphasis></para></td>
<td><para><emphasis role="bold">What is
measured</emphasis></para></td>
<td><para><emphasis role="bold"
>Context</emphasis></para></td>
</tr>
<tr>
<td><para>PCR-00</para></td>
<td><para>Core Root of Trust Measurement (CRTM), BIOS
code, Host platform extensions</para></td>
<td><para>Hardware</para></td>
</tr>
<tr>
<td><para>PCR-01</para></td>
<td><para>Host platform configuration</para></td>
<td><para>Hardware</para></td>
</tr>
<tr>
<td><para>PCR-02</para></td>
<td><para>Option ROM code</para></td>
<td><para>Hardware</para></td>
</tr>
<tr>
<td><para>PCR-03</para></td>
<td><para>Option ROM configuration and data</para></td>
<td><para>Hardware</para></td>
</tr>
<tr>
<td><para>PCR-04</para></td>
<td><para>Initial Program Loader (IPL) code. For example,
master boot record.</para></td>
<td><para>Software</para></td>
</tr>
<tr>
<td><para>PCR-05</para></td>
<td><para>IPL code configuration and data</para></td>
<td><para>Software</para></td>
</tr>
<tr>
<td><para>PCR-06</para></td>
<td><para>State transition and wake events</para></td>
<td><para>Software</para></td>
</tr>
<tr>
<td><para>PCR-07</para></td>
<td><para>Host platform manufacturer control</para></td>
<td><para>Software</para></td>
</tr>
<tr>
<td><para>PCR-08</para></td>
<td><para>Platform specific, often kernel, kernel
extensions, and drivers</para></td>
<td><para>Software</para></td>
</tr>
<tr>
<td><para>PCR-09</para></td>
<td><para>Platform specific, often Initramfs</para></td>
<td><para>Software</para></td>
</tr>
<tr>
<td><para>PCR-10 to PCR-23</para></td>
<td><para>Platform specific</para></td>
<td><para>Software</para></td>
</tr>
</tbody>
</informaltable>
<para>At the time of this writing, very few clouds are using
secure boot technologies in a production environment. As a
result, these technologies are still somewhat immature. We
recommend planning carefully in terms of hardware selection.
For example, ensure that you have a TPM and Intel TXT support.
Then verify how the node hardware vendor populates the PCR
values. For example, which values will be available for
validation. Typically the PCR values listed under the software
context in the table above are the ones that a cloud architect
has direct control over. But even these may change as the
software in the cloud is upgraded. Configuration management
should be linked into the PCR policy engine to ensure that the
validation is always up to date.</para>
<para>Each manufacturer must provide the BIOS and firmware code
for their servers. Different servers, hypervisors, and
operating systems will choose to populate different PCRs. In
most real world deployments, it will be impossible to validate
every PCR against a known good quantity ("golden
measurement"). Experience has shown that, even within a single
vendor's product line, the measurement process for a given PCR
may not be consistent. We recommend establishing a baseline
for each server and monitoring the PCR values for unexpected
changes. Third-party software may be available to assist in
the TPM provisioning and monitoring process, depending upon
your chosen hypervisor solution.</para>
<para>The initial program loader (IPL) code will most likely be
the PXE firmware, assuming the node deployment strategy
outlined above. Therefore, the secure boot or boot attestation
process can measure all of the early stage boot code, such as,
bios, firmware, and the like, the PXE firmware, and the node
kernel. Ensuring that each node has the correct versions of
these pieces installed provides a solid foundation on which to
build the rest of the node software stack.</para>
<para>Depending on the strategy selected, in the event of a
failure the node will either fail to boot or it can report the
failure back to another entity in the cloud. For secure boot,
the node will fail to boot and a provisioning service within
the management security domain must recognize this and log the
event. For boot attestation, the node will already be running
when the failure is detected. In this case the node should be
immediately quarantined by disabling its network access. Then
the event should be analyzed for the root cause. In either
case, policy should dictate how to proceed after a failure. A
cloud may automatically attempt to re-provision a node a
certain number of times. Or it may immediately notify a cloud
administrator to investigate the problem. The right policy
here will be deployment and failure mode specific.</para>
</section>
<section xml:id="ch013_node-bootstrapping-idp3728">
<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
specifics on these steps are outside of the scope of this
book. We recommend following the guidance from a hardening
guide specific to your operating system. For example, the
<link xlink:href="http://iase.disa.mil/stigs/">security
technical implementation guides</link> (STIG) and the <link
xlink:href="http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/"
>NSA guides</link> are useful starting places.</para>
<para>The nature of the nodes makes additional hardening
possible. We recommend the following additional steps for
production nodes:</para>
<itemizedlist>
<listitem>
<para>Use a read-only file system where possible. Ensure
that writeable file systems do not permit execution. This
can be handled through the mount options provided in
<filename>/etc/fstab</filename>.</para>
</listitem>
<listitem>
<para>Use a mandatory access control policy to contain the
instances, the node services, and any other critical
processes and data on the node. See the discussions on
sVirt / SELinux and AppArmor below.</para>
</listitem>
<listitem>
<para>Remove any unnecessary software packages. This should
result in a very stripped down installation because a
compute node has a relatively small number of
dependencies.</para>
</listitem>
</itemizedlist>
<para>Finally, the node kernel should have a mechanism to
validate that the rest of the node starts in a known good
state. This provides the necessary link from the boot
validation process to validating the entire system. The steps
for doing this will be deployment specific. As an example, a
kernel module could verify a hash over the blocks comprising
the file system before mounting it using <link
xlink:href="https://code.google.com/p/cryptsetup/wiki/DMVerity"
>dm-verity</link>.</para>
</section>
</section>
<section xml:id="ch013_node-bootstrapping-idp11376">
<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
each of these areas are different. By checking both, we achieve
higher assurance that the system is operating as desired. We
discuss configuration management in the management section, and
security monitoring below.</para>
<section xml:id="ch013_node-bootstrapping-idp135504">
<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.
Some are open source projects that are freely available, while
others are commercial. Typically these tools analyze data from
a variety of sources and produce security alerts based on rule
sets and/or training. Typical capabilities include log
analysis, file integrity checking, policy monitoring, and
rootkit detection. More advanced -- often custom -- tools can
validate that in-memory process images match the on-disk
executable and validate the execution state of a running
process.</para>
<para>One critical policy decision for a cloud architect is what
to do with the output from a security monitoring tool. There
are effectively two options. The first is to alert a human to
investigate and/or take corrective action. This could be done
by including the security alert in a log or events feed for
cloud administrators. The second option is to have the cloud
take some form of remedial action automatically, in addition
to logging the event. Remedial actions could include anything
from re-installing a node to performing a minor service
configuration. However, automated remedial action can be
challenging due to the possibility of false positives.</para>
<para>False positives occur when the security monitoring tool
produces a security alert for a benign event. Due to the
nature of security monitoring tools, false positives will most
certainly occur from time to time. Typically a cloud
administrator can tune security monitoring tools to reduce the
false positives, but this may also reduce the overall
detection rate at the same time. These classic trade-offs must
be understood and accounted for when setting up a security
monitoring system in the cloud.</para>
<para>The selection and configuration of a host-based intrusion
detection tool is highly deployment specific. We recommend
starting by exploring the following open source projects which
implement a variety of host-based intrusion detection and file
monitoring features.</para>
<itemizedlist>
<listitem>
<para><link xlink:href="http://www.ossec.net/"
>OSSEC</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://la-samhna.de/samhain/"
>Samhain</link></para>
</listitem>
<listitem>
<para><link
xlink:href="http://sourceforge.net/projects/tripwire/"
>Tripwire</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://aide.sourceforge.net/"
>AIDE</link></para>
</listitem>
</itemizedlist>
<para>Network intrusion detection tools complement the
host-based tools. OpenStack doesn't have a specific network
IDS built-in, but OpenStack Networking
provides a plug-in mechanism to enable different technologies
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>
<para>Similar to host-based tools, the selection and
configuration of a network-based intrusion detection tool is
deployment specific. <link xlink:href="http://www.snort.org/"
>Snort</link> is the leading open source networking
intrusion detection tool, and a good starting place to learn
more.</para>
<para>There are a few important security considerations for
network and host-based intrusion detection systems.</para>
<itemizedlist>
<listitem>
<para>It is important to consider the placement of the
Network IDS on the cloud (for example, adding it to the
network boundary and/or around sensitive networks). The
placement depends on your network environment but make
sure to monitor the impact the IDS may have on your
services depending on where you choose to add it.
Encrypted traffic, such as SSL, cannot generally be
inspected for content by a Network IDS. However, the
Network IDS may still provide some benefit in identifying
anomalous unencrypted traffic on the network.</para>
</listitem>
<listitem>
<para>In some deployments it may be required to add
host-based IDS on sensitive components on security domain
bridges. A host-based IDS may detect anomalous activity
by compromised or unauthorized processes on the component.
The IDS should transmit alert and log information on the
Management network.</para>
</listitem>
</itemizedlist>
</section>
</section>
</chapter>

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

@@ -1,203 +0,0 @@
<?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"
version="5.0"
xml:id="ch014_best-practices-for-operator-mode-access">
<?dbhtml stop-chunking?>
<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>
</listitem>
<listitem>
<para>OpenStack API</para>
</listitem>
<listitem>
<para>Secure shell (SSH)</para>
</listitem>
<listitem>
<para>OpenStack management utilities such as
<systemitem class="service">nova-manage</systemitem> and
<systemitem class="service">glance-manage</systemitem></para>
</listitem>
<listitem>
<para>Out-of-band management interfaces, such as IPMI</para>
</listitem>
</itemizedlist>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp49280">
<title>Dashboard</title>
<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 through calls to the OpenStack API.
</para>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp50608">
<title>Capabilities</title>
<itemizedlist><listitem>
<para>As a cloud administrator, the dashboard provides an overall view of the size and state of your cloud. You can create users and tenants/projects, assign users to tenant/projects and set limits on the resources available for them.</para>
</listitem>
<listitem>
<para>The dashboard provides tenant-users a self-service portal to provision their own resources within the limits set by administrators.</para>
</listitem>
<listitem>
<para>The dashboard provides GUI support for routers and load-balancers. For example, the dashboard now implements all of the main Networking features.</para>
</listitem>
<listitem>
<para>It is an extensible <glossterm>Django</glossterm> web application that allows easy plug-in of third-party products and services, such as billing, monitoring, and additional management tools.</para>
</listitem>
<listitem>
<para>The dashboard can also be branded for service providers and other commercial vendors.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp56400">
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The dashboard requires cookies and JavaScript to be enabled in the web browser.</para>
</listitem>
<listitem>
<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>
</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-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>
</itemizedlist>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp62384">
<title>References</title>
<para><link xlink:href="https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly"><citetitle>Grizzly Release Notes</citetitle></link></para>
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp63760">
<title>OpenStack API</title>
<para>The OpenStack API is a RESTful web service endpoint to
access, provision and automate cloud-based resources. Operators
and users typically access the API through command-line
utilities (for example, <command>nova</command> or
<command>glance</command>), language-specific libraries, or
third-party tools.</para>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp65328">
<title>Capabilities</title>
<itemizedlist><listitem>
<para>To the cloud administrator, the API provides an
overall view of the size and state of the cloud deployment
and allows the creation of users, tenants/projects,
assigning users to tenants/projects, and specifying
resource quotas on a per tenant/project basis.</para>
</listitem>
<listitem>
<para>The API provides a tenant interface for provisioning, managing, and accessing their resources.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp68272">
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The API service should be configured for SSL to ensure data is encrypted.</para>
</listitem>
<listitem>
<para>As a web service, OpenStack API is susceptible to familiar web site attack vectors such as denial of service attacks.</para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp71184">
<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>
<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>
<para>Once the SSH host key is generated, the host key fingerprint should be stored in a secure and queriable location. One particularly convenient solution is DNS using SSHFP resource records as defined in RFC-4255. For this to be secure, it is necessary that DNSSEC be deployed.</para>
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp76272">
<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
class="service">nova</systemitem>, <systemitem
class="service">glance</systemitem>). In addition to the
standard CLI client, most of the services have a management
command-line utility which makes direct calls to the database. These
dedicated management utilities are slowly being
deprecated.</para>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp77728">
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The dedicated management utilities (*-manage) in some cases use the direct database connection.</para>
</listitem>
<listitem>
<para>Ensure that the .rc file which has your credential information is secured.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp80496">
<title>References</title>
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/user-guide/content/section_cli_overview.html">command-line clients overview</link></para>
<para><citetitle>OpenStack End User Guide</citetitle> section <link xlink:href="http://docs.openstack.org/user-guide/content/cli_openrc.html">Download and source the OpenStack RC file</link></para>
</section>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp82336">
<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
specification to remotely manage, diagnose, and reboot servers
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>
<itemizedlist><listitem>
<para>Use strong passwords and safeguard them, or use client-side SSL authentication.</para>
</listitem>
<listitem>
<para>Ensure that the network interfaces are on their own private(management or a separate) network. Segregate management domains with firewalls or other network gear.</para>
</listitem>
<listitem>
<para>If you use a web interface to interact with the
<glossterm>BMC</glossterm>/IPMI, always use the SSL
interface, such as https or port 443. This SSL interface
should <emphasis role="bold">NOT</emphasis> use
self-signed certificates, as is often default, but should
have trusted certificates using the correctly defined
fully qualified domain names (FQDNs).</para>
</listitem>
<listitem>
<para>Monitor the traffic on the management network. The
anomalies might be easier to track than on the busier
compute nodes.</para>
</listitem>
</itemizedlist>
<para>Out of band management interfaces also often include graphical machine console access. It is often possible, although not necessarily default, that these interfaces are encrypted. Consult with your system software documentation for encrypting these interfaces.</para>
</section>
<section xml:id="ch014_best-practices-for-operator-mode-access-idp89920">
<title>References</title>
<para><link xlink:href="https://isc.sans.edu/diary/IPMI%3A+Hacking+servers+that+are+turned+%22off%22/13399">Hacking servers that are turned off</link></para>
</section>
</section>
</chapter>

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

@@ -1,37 +0,0 @@
<?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"
version="5.0"
xml:id="ch015_case-studies-management">
<?dbhtml stop-chunking?>
<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>
</listitem>
<listitem>
<para>Self service</para>
</listitem>
<listitem>
<para>Data replication and recovery</para>
</listitem>
<listitem>
<para>SLA and security monitoring</para>
</listitem>
</itemizedlist>
<section xml:id="ch015_case-studies-management-idp48432">
<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>
<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>
</chapter>

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

@@ -1,127 +0,0 @@
<?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"
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>
<para>
Public Key Infrastructure (PKI) is a set of hardware, software,
policies, and procedures required to operate a secure system
that provides authentication, non-repudiation, confidentiality,
and integrity. The core components of PKI are:</para>
<variablelist>
<varlistentry>
<term>End entity</term>
<listitem>
<para>User, process, or system that is the subject of a
certificate.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Certification Authority (<glossterm>CA</glossterm>)</term>
<listitem>
<para>Defines certificate policies, management, and issuance
of certificates.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Registration Authority (RA)</term>
<listitem>
<para>An optional system to which a CA delegates certain
management functions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Repository</term>
<listitem>
<para>
Where the end entity certificates and certificate
revocation lists are stored and looked up - sometimes
referred to as the <emphasis role="italic">certificate
bundle</emphasis>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Relying party</term>
<listitem>
<para>The endpoint that is trusting that the CA is valid.</para>
</listitem>
</varlistentry>
</variablelist>
<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>
<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>
<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>
<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>
</listitem>
<listitem>
<para><link xlink:href="https://www.owasp.org/index.php/Guide_to_Cryptography">OWASP Guide to Cryptography</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">OWASP Transport Layer Protection Cheat Sheet</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.ieee-security.org/TC/SP2013/papers/4977a511.pdf">SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate trust model enhancements</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf">The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.openssl.org/docs/fips/fipsnotes.html">OpenSSL and FIPS 140-2</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch017_threat-models-confidence-and-confidentiality-idp64128">
<title>Summary</title>
<para>
Given the complexity of the OpenStack components and the
number of deployment possibilities, you must take care to
ensure that each component gets the appropriate configuration
of SSL certificates, keys, and CAs. Subsequent sections discuss
the following services:
</para>
<itemizedlist>
<listitem>
<para>Compute API endpoints</para>
</listitem>
<listitem>
<para>Identity API endpoints</para>
</listitem>
<listitem>
<para>Networking API endpoints</para>
</listitem>
<listitem>
<para>Storage API endpoints</para>
</listitem>
<listitem>
<para>Messaging server</para>
</listitem>
<listitem>
<para>Database server</para>
</listitem>
<listitem>
<para>Dashboard</para>
</listitem>
</itemizedlist>
<para>
This guide uses the term SSL as a shorthand to refer to these
recommendations for SSL/TLS protocols.</para>
</section>
</chapter>

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

@@ -1,18 +0,0 @@
<?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"
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>
<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>
<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>

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

@@ -1,262 +0,0 @@
<?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"
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>
<para><link xlink:href="http://www.apsis.ch/pound">Pound</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://github.com/bumptech/stud">Stud</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://nginx.org/">nginx</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.apache.org/">Apache httpd</link></para>
</listitem>
<listitem>
<para>Hardware appliance SSL acceleration proxies</para>
</listitem>
</itemizedlist>
<para>It is important to be mindful of the size of requests that will be processed by any chosen SSL proxy.</para>
<section xml:id="ch020_ssl-everywhere-idp44384">
<title>Examples</title>
<para>Below we provide some sample recommended configuration settings for enabling SSL in some of the more popular web servers/SSL terminators. Note that we have SSL v3 enabled in some of these examples as this will be required in many deployments for client compatibility.</para>
<para>Before we delve into the configurations, we briefly discuss the ciphers' configuration element and its format. A more exhaustive treatment on available ciphers and the OpenSSL cipher list format can be found at: <link xlink:href="https://www.openssl.org/docs/apps/ciphers.html">ciphers</link>.</para>
<programlisting>
ciphers = "HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"
</programlisting>
<para>or</para>
<programlisting>
ciphers = "kEECDH:kEDH:kRSA:HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"
</programlisting>
<para>Cipher string options are separated by ":", while "!" provides negation of the immediately following element. Element order indicates preference unless overridden by qualifiers such as HIGH. Let us take a closer look at the elements in the above sample strings.</para>
<variablelist>
<varlistentry>
<term><code>kEECDH:kEDH</code></term>
<listitem>
<para>Ephemeral Elliptic Curve Diffie-Hellman (abbreviated as EECDH and ECDHE).</para>
<para>Ephemeral Diffie-Hellman (abbreviated either as EDH or DHE) uses prime field groups.</para>
<para>Both approaches provide <link xlink:href="http://en.wikipedia.org/wiki/Forward_secrecy">Perfect Forward Secrecy (PFS)</link>.</para>
<para>Ephemeral Elliptic Curves require the server to be configured with a named curve, and provide better security than prime field groups and at lower computational cost. However, prime field groups are more widely implemented, and thus typically both are included in list.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>kRSA</code></term>
<listitem>
<para>Cipher suites using the <link xlink:href="http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29">RSA</link> exchange, authentication or either respectively.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>HIGH</code></term>
<listitem>
<para>Selects highest possible security cipher in the negotiation phase. These typically have keys of length 128 bits or longer.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>!RC4</code></term>
<listitem>
<para>No RC4. RC4 has flaws in the context of TLS/SSL V3. See <link xlink:href="cr.yp.to/streamciphers/rc4biases-20130708.pdf"> On the Security of RC4 in TLS and WPA</link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>!MD5</code></term>
<listitem>
<para>No MD5. MD5 is not collision resistant, and thus not acceptable for Message Authentication Codes (MAC) or signatures.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>!aNULL:!eNULL</code></term>
<listitem>
<para>Disallows clear text</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>!EXP</code></term>
<listitem>
<para>Disallows export encryption algorithms, which by design tend to were weak, typically using 40 and 56 bit keys.</para>
<para>US Export restrictions on cryptography systems have been lifted and no longer need to be supported.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>!LOW:!MEDIUM</code></term>
<listitem>
<para>Disallows low (keys 56 or 64 bits long) and medium (128 bit long keys) ciphers because of their vulnerability to brute force attacks (example 2-DES). This constraint leaves acceptable Triple Data Encryption Standard (Triple DES) also known as Triple Data Encryption Algorithm (TDEA) and the Advanced Encryption Standard (AES), each of which has keys greater than equal to 128 bits and thus more secure.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><code>Protocols</code></term>
<listitem>
<para>Protocols are enabled/disabled through SSL_CTX_set_options. We recommend disabling SSLv2 and enabling TLS or SSLv3 (which was standardised as TLS with a few changes).</para>
</listitem>
</varlistentry>
</variablelist>
<section xml:id="ch020_ssl-everywhere-idp45712">
<title>Pound - with AES-NI acceleration</title>
<programlisting>## see pound(8) for details
daemon 1
######################################################################
## global options:
User "swift"
Group "swift"
#RootJail "/chroot/pound"
## Logging: (goes to syslog by default)
## 0 no logging
## 1 normal
## 2 extended
## 3 Apache-style (common log format)
LogLevel 0
## turn on dynamic scaling (off by default)
# Dyn Scale 1
## check backend every X secs:
Alive 30
## client timeout
#Client 10
## allow 10 second proxy connect time
ConnTO 10
## use hardware-acceleration card supported by openssl(1):
SSLEngine "aesni"
# poundctl control socket
Control "/var/run/pound/poundctl.socket"
######################################################################
## listen, redirect and ... to:
## redirect all swift requests on port 443 to local swift proxy
ListenHTTPS
Address 0.0.0.0
Port 443
Cert "/etc/pound/cert.pem"
## Certs to accept from clients
## CAlist "CA_file"
## Certs to use for client verification
## VerifyList "Verify_file"
## Request client cert - don't verify
## Ciphers "AES256-SHA"
## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
NoHTTPS11 0
## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
xHTTP 1
Service
BackEnd
Address 127.0.0.1
Port 80
End
End
End</programlisting>
</section>
<section xml:id="ch020_ssl-everywhere-idp50320">
<title>Stud</title>
<para>This stud example enables SSL v3 for client compatibility. The ciphers line can be tweaked based on your needs, however this is a reasonable starting place.</para>
<programlisting># SSL x509 certificate file.
pem-file = "
# SSL protocol.
ssl = on
# List of allowed SSL ciphers.
# OpenSSL's high-strength ciphers which require authentication
# NOTE: forbids clear text, use of RC4 or MD5 or LOW and MEDIUM strength ciphers
ciphers = "HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"
# Enforce server cipher list order
prefer-server-ciphers = on
# Number of worker processes
workers = 4
# Listen backlog size
backlog = 1000
# TCP socket keepalive interval in seconds
keepalive = 3600
# Chroot directory
chroot = ""
# Set uid after binding a socket
user = "www-data"
# Set gid after binding a socket
group = "www-data"
# Quiet execution, report only error messages
quiet = off
# Use syslog for logging
syslog = on
# Syslog facility to use
syslog-facility = "daemon"
# Run as daemon
daemon = off
# Report client address using SENDPROXY protocol for haproxy
# Disabling this until we upgrade to HAProxy 1.5
write-proxy = off</programlisting>
</section>
</section>
<section xml:id="ch020_ssl-everywhere-idp53424">
<title>nginx</title>
<para>This nginx example requires TLS v1.1 or v1.2 for maximum security. The ssl_ciphers line can be tweaked based on your needs, however this is a reasonable starting place.</para>
<programlisting>server {
listen : ssl;
ssl_certificate ;
ssl_certificate_key ;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM
server_name _;
keepalive_timeout 5;
location / {
}
}</programlisting>
<section xml:id="ch020_ssl-everywhere-idp55264">
<title>Apache</title>
<programlisting>&lt;VirtualHost &lt;ip address&gt;:80&gt;
ServerName &lt;site FQDN&gt;
RedirectPermanent / https://&lt;site FQDN&gt;/
&lt;/VirtualHost&gt;
&lt;VirtualHost &lt;ip address&gt;:443&gt;
ServerName &lt;site FQDN&gt;
SSLEngine On
SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2,
SSLCipherSuite HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM
SSLCertificateFile /path/&lt;site FQDN&gt;.crt
SSLCACertificateFile /path/&lt;site FQDN&gt;.crt
SSLCertificateKeyFile /path/&lt;site FQDN&gt;.key
WSGIScriptAlias / &lt;WSGI script location&gt;
WSGIDaemonProcess horizon user=&lt;user&gt; group=&lt;group&gt; processes=3 threads=10
Alias /static &lt;static files location&gt;
&lt;Directory &lt;WSGI dir&gt;&gt;
# For http server 2.2 and earlier:
Order allow,deny
Allow from all
# Or, in Apache http server 2.4 and later:
# Require all granted
&lt;/Directory&gt;
&lt;/VirtualHost&gt;</programlisting>
<para>Compute API SSL endpoint in Apache, which you must pair with
a short WSGI script.</para>
<programlisting>&lt;VirtualHost &lt;ip address&gt;:8447&gt;
ServerName &lt;site FQDN&gt;
SSLEngine On
SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2,
SSLCipherSuite HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM
SSLCertificateFile /path/&lt;site FQDN&gt;.crt
SSLCACertificateFile /path/&lt;site FQDN&gt;.crt
SSLCertificateKeyFile /path/&lt;site FQDN&gt;.key
WSGIScriptAlias / &lt;WSGI script location&gt;
WSGIDaemonProcess osapi user=&lt;user&gt; group=&lt;group&gt; processes=3 threads=10
&lt;Directory &lt;WSGI dir&gt;&gt;
# For http server 2.2 and earlier:
Order allow,deny
Allow from all
# Or, in Apache http server 2.4 and later:
# Require all granted
&lt;/Directory&gt;
&lt;/VirtualHost&gt;</programlisting>
</section>
</section>
<section xml:id="ch020_ssl-everywhere-idp59152">
<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>
</section>
</chapter>

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

@@ -1,142 +0,0 @@
<?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"
version="5.0"
xml:id="ch021_paste-and-middleware">
<?dbhtml stop-chunking?>
<title>API endpoint configuration recommendations</title>
<para>
This chapter provides recommendations security enhancements for
both public and private-facing API endpoints.</para>
<section xml:id="ch021_paste-and-middleware-idp38176">
<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. These services might 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>
<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 \
--region RegionOne \
--service-id=1ff4ece13c3e48d8a6461faebd9cd38f \
--publicurl='https://public-ip:8776/v1/%(tenant_id)s' \
--internalurl='https://management-ip:8776/v1/%(tenant_id)s' \
--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>
<para>
You can force some services 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>
<programlisting language="ini">[DEFAULT]
cinder_catalog_info='volume:cinder:internalURL'
glance_protocol='https'
neutron_url='https://neutron-host:9696'
neutron_admin_auth_url='https://neutron-host:9696'
s3_host='s3-host'
s3_use_ssl=True</programlisting>
</section>
<section xml:id="ch021_paste-and-middleware-idp47184">
<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>
<para>
Most API endpoints and other HTTP services in OpenStack use
the Python Paste Deploy library. From a securtiy perspective,
this library enables 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 might have
unpredictable security impact.</para>
<para>
Commonly, implementers add middleware to extend OpenStack's
base functionality. We recommend implementers make careful
consideration of the potential exposure introduced by the
addition of non-standard software components to their HTTP
request pipeline.</para>
<para>For more information about Paste Deploy, see
<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 and policy</title>
<para>
As much as possible, you should isolate 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. Other parts of this guide cover system
compartmentalization in more detail.</para>
</section>
<section xml:id="ch021_paste-and-middleware-idp55232">
<title>Network policy</title>
<para>
Because API endpoints typically bridge multiple security
domains, you must pay particular attention to the
compartmentalization of the API processes. See <xref
linkend="ch005_security-domains-idp61360"/> for additional
information in this area.</para>
<para>
With careful modeling, you can use network ACLs and IDS
technologies 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>
To enforce policies, you can configure services, host-based
firewalls (such as iptables), local policy (SELinux or
AppArmor), and optionally global network policy.</para>
</section>
<section xml:id="ch021_paste-and-middleware-idp58704">
<title>Mandatory access controls</title>
<para>
You should isolate API endpoint processes 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 severely limit access to resources and provide
earlier alerting on such events.</para>
</section>
</section>
</chapter>

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

@@ -1,50 +0,0 @@
<?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"
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
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 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>

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

@@ -1,306 +0,0 @@
<?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"
version="5.0"
xml:id="ch024_authentication">
<?dbhtml stop-chunking?>
<title>Identity</title>
<para>The OpenStack Identity service (keystone) supports multiple
methods of authentication, including username &amp; password,
LDAP, and external authentication methods. Upon successful
authentication, The Identity Service provides the user with an
authorization token used for subsequent service requests.</para>
<para>Transport Layer Security TLS/SSL provides authentication
between services and persons using X.509 certificates. Although
the default mode for SSL is server-side only authentication,
certificates may also be used for client authentication.</para>
<section xml:id="ch024_authentication-idp195568">
<title>Authentication</title>
<section xml:id="ch024_authentication-idp196256">
<title>Invalid login attempts</title>
<para>The Identity Service does not provide a method to limit
access to accounts after repeated unsuccessful login attempts.
Repeated failed login attempts are likely brute-force attacks
(Refer figure Attack-types). This is a more significant issue
in Public clouds.</para>
<para>Prevention is possible by using an external authentication
system that blocks out an account after some configured number
of failed login attempts. The account then may only be
unlocked with further side-channel intervention.</para>
<para>If prevention is not an option, detection can be used to
mitigate damage.Detection involves frequent review of access
control logs to identify unauthorized attempts to access
accounts. Possible remediation would include reviewing the
strength of the user password, or blocking the network source
of the attack through firewall rules. Firewall rules on the
keystone server that restrict the number of connections could
be used to reduce the attack effectiveness, and thus dissuade
the attacker.</para>
<para>In addition, it is useful to examine account activity for
unusual login times and suspicious actions, with possibly
disable the account. Oftentimes this approach is taken by
credit card providers for fraud detection and alert.</para>
</section>
<section xml:id="ch024_authentication-idp241008">
<title>Multi-factor authentication</title>
<para>Employ multi-factor authentication for network access to
privileged user accounts. The Identity Service supports
external authentication services through the Apache web server
that can provide this functionality. Servers may also enforce
client-side authentication using certificates.</para>
<para>This recommendation provides insulation from brute force,
social engineering, and both spear and mass phishing attacks
that may compromise administrator passwords.</para>
</section>
</section>
<section xml:id="ch024_authentication-idp243184">
<title>Authentication methods</title>
<section xml:id="ch024_authentication-idp243824">
<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
OpenStack services to reduce the risk of a compromise of the
stored credentials.</para>
<para>
When you use a user name and password to authenticate,
Identity does not enforce policies on password strength,
expiration, or failed authentication attempts as recommended
by NIST Special Publication 800-118 (draft). Organizations
that desire to enforce stronger password policies should
consider using 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>
<para>Authentication and authorization policy in OpenStack may
be delegated to an external LDAP server. A typical use case is
an organization that seeks to deploy a private cloud and
already has a database of employees, the users. This may be in
an LDAP system. Using LDAP as a source of authority
authentication, requests to Identity Service are delegated to
the LDAP service, which will authorize or deny requests based
on locally set policies. A token is generated on successful
authentication.</para>
<para>Note that if the LDAP system has attributes defined for
the user such as admin, finance, HR etc, these must be mapped
into roles and groups within Identity for use by the various
OpenStack services. The <filename>/etc/keystone.conf</filename>
file maps LDAP attributes to Identity attributes.</para>
<para>The Identity Service <emphasis role="bold">MUST
NOT</emphasis> be allowed to write to LDAP services used for
authentication outside of the OpenStack deployment as this
would allow a sufficiently privileged keystone user to make
changes to the LDAP directory. This would allow privilege
escalation within the wider organization or facilitate
unauthorized access to other information and resources. In
such a deployment, user provisioning would be out of the realm
of the OpenStack deployment.</para>
<note>
<para>There is an <link
xlink:href="https://bugs.launchpad.net/ossn/+bug/1168252"
>OpenStack Security Note (OSSN) regarding keystone.conf
permissions</link>.</para>
<para>There is an <link
xlink:href="https://bugs.launchpad.net/ossn/+bug/1155566"
>OpenStack Security Note (OSSN) regarding potential DoS
attacks</link>.</para>
</note>
</section>
<section xml:id="ch024_authentication-idp251520">
<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
requirements. Although passwords are the most common form of
authentication, they can be compromised through numerous
methods, including keystroke logging and password compromise.
External authentication services can provide alternative forms
of authentication that minimize the risk from weak
passwords.</para>
<para>These include:</para>
<itemizedlist>
<listitem>
<para>Password policy enforcement: Requires user passwords
to conform to minimum standards for length, diversity of
characters, expiration, or failed login attempts.</para>
</listitem>
<listitem>
<para>Multi-factor authentication: The authentication
service requires the user to provide information based on
something they have, such as a one-time password token or
X.509 certificate, and something they know, such as a
password.</para>
</listitem>
<listitem>
<para>Kerberos</para>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="ch024_authentication-idp256832">
<title>Authorization</title>
<para>The Identity Service supports the notion of groups and
roles. Users belong to groups. A group has a list of roles.
OpenStack services reference the roles of the user attempting to
access the service. The OpenStack policy enforcer middleware
takes into consideration the policy rule associated with each
resource and the user's group/roles and tenant association to
determine if he/she has access to the requested resource.</para>
<para>The Policy enforcement middleware enables fine-grained
access control to OpenStack resources. Only admin users can
provision new users and have access to various management
functionality. The cloud tenant would be able to only spin up
instances, attach volumes, etc.</para>
<section xml:id="ch024_authentication-idp259168">
<title>Establish formal access control policies</title>
<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
regulatory or legal requirements for the organization. Future
modifications to access control configuration should be done
consistently with the formal policies. The policies should
include the conditions and processes for creating, deleting,
disabling, and enabling accounts, and for assigning privileges
to the accounts. Periodically review the policies and ensure
that configuration is in compliance with approved
policies.</para>
</section>
<section xml:id="ch024_authentication-idp261600">
<title>Service authorization</title>
<para>As described in the <link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/index.html"
><citetitle>OpenStack Cloud Administrator
Guide</citetitle></link>, cloud administrators must define
a user for each service, with a role of Admin. This service
user account provides the service with the authorization to
authenticate users.</para>
<para>The Compute and Object Storage services can be configured
to use either the "tempAuth" file or Identity Service to store
authentication information. The "tempAuth" solution MUST NOT
be deployed in a production environment since it stores
passwords in plain text.</para>
<para>The Identity Service supports client authentication for
SSL which may be enabled. SSL client authentication provides
an additional authentication factor, in addition to the
username / password, that provides greater reliability on user
identification. It reduces the risk of unauthorized access
when user names and passwords may be compromised. However,
there is additional administrative overhead and cost to issue
certificates to users that may not be feasible in every
deployment.</para>
<note>
<para>We recommend that you use client authentication with SSL
for the authentication of services to the Identity
Service.</para>
</note>
<para>The cloud administrator should protect sensitive
configuration files for unauthorized modification. This can be
achieved with mandatory access control frameworks such as
SELinux, including <filename>/etc/keystone.conf</filename> and
X.509 certificates.</para>
<para>For client authentication with SSL, you need to issue
certificates. These certificates can be signed by an external
authority or by the cloud administrator. OpenStack services by
default check the signatures of certificates and connections
fail if the signature cannot be checked. If the administrator
uses self-signed certificates, the check might need to be
disabled. To disable these certificates, set
<code>insecure=False</code> in the
<code>[filter:authtoken]</code> section in the
<filename>/etc/nova/api.paste.ini</filename> file. This
setting also disables certificates for other
components.</para>
</section>
<section xml:id="ch024_authentication-idp267040">
<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
the risk from passwords that may be compromised. This
recommendation is in compliance with NIST 800-53 IA-2(1)
guidance in the use of multi factor authentication for network
access to privileged accounts.</para>
</section>
<section xml:id="ch024_authentication-idp268960">
<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
security policies and requirements.</para>
</section>
</section>
<section xml:id="ch024_authentication-idp270544">
<title>Policies</title>
<para>Each OpenStack service has a policy file in JSON format,
called <filename>policy.json</filename>. The policy
file specifies rules, and the rule that governs each resource. A
resource could be API access, the ability to attach to a volume,
or to fire up instances.</para>
<para>The policies can be updated by the cloud administrator to
further control access to the various resources. The middleware
could also be further customized. Note that your users must be
assigned to groups/roles that you refer to in your
policies.</para>
<para>Below is a snippet of the Block Storage service
<filename>policy.json</filename> file.</para>
<programlisting language="json"><xi:include href="../common/samples/authentication.json" parse="text"/></programlisting>
<para>Note the <emphasis role="bold">default</emphasis> rule
specifies that the user must be either an admin or the owner of
the volume. It essentially says only the owner of a volume or
the admin may create/delete/update volumes. Certain other
operations such as managing volume types are accessible only to
admin users.</para>
</section>
<section xml:id="ch024_authentication-idp276176">
<title>Tokens</title>
<para>Once a user is authenticated, a token is generated and used
internally in OpenStack for authorization and access. The
default token <emphasis role="bold">lifespan</emphasis>
is<emphasis role="bold"> 24 hours</emphasis>. It is
recommended that this value be set lower but caution needs to be
taken as some internal services will need sufficient time to
complete their work. The cloud may not provide services if
tokens expire too early. An example of this would be the time
needed by the Compute service to transfer a disk image onto the
hypervisor for local caching.</para>
<para>The following example shows a PKI token. Note that, in
practice, the token id value is about 3500 bytes. We shorten it
in this example.</para>
<programlisting language="json"><xi:include href="../common/samples/token.json" parse="text"/></programlisting>
<para>Note that the token is often passed within the structure of
a larger context of an Identity Service response. These
responses also provide a catalog of the various OpenStack
services. Each service is listed with its name, access endpoints
for internal, admin, and public access.</para>
<para>The Identity Service supports token revocation. This
manifests as an API to revoke a token, to list revoked tokens
and individual OpenStack services that cache tokens to query for
the revoked tokens and remove them from their cache and append
the same to their list of cached revoked tokens.</para>
</section>
<section xml:id="ch024_authentication-idp287584">
<title>Future</title>
<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
account-like container. In addition, multiple users can be
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
policy definitions to access the various service
resources.</para>
<para>Where a rule may specify access to only admin users and
users belonging to the tenant, the mapping may be trivial. In
other scenarios the cloud administrator may need to approve the
mapping routines per tenant.</para>
</section>
</chapter>

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

@@ -1,259 +0,0 @@
<?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"
version="5.0"
xml:id="ch025_web-dashboard">
<?dbhtml stop-chunking?>
<title>Dashboard</title>
<para>Horizon is the OpenStack dashboard that provides users a self-service
portal to provision their own resources within the limits set by
administrators. These include provisioning users, defining instance flavors,
uploading VM images, managing networks, setting up security groups, starting
instances, and accessing the instances through a console.</para>
<para>The dashboard is based on the Django web framework, therefore
secure deployment practices for Django apply directly to horizon.
This guide provides a popular set of Django security
recommendations, further information can be found by reading the
<link
xlink:href="https://docs.djangoproject.com/en/1.5/#security"
>Django deployment and security documentation</link>.</para>
<para>The dashboard ships with reasonable default security settings,
and has good <link
xlink:href="http://docs.openstack.org/developer/horizon/topics/deployment.html"
>deployment and configuration documentation</link>.</para>
<section xml:id="ch025_web-dashboard-idp237648">
<title>Basic web server configuration</title>
<para>The dashboard should be deployed as a Web Services Gateway
Interface (WSGI) application behind an HTTPS proxy such as
Apache or nginx. If Apache is not already in use, we recommend
nginx since it is lighter weight and easier to configure
correctly.</para>
<para>When using nginx, we recommend <link
xlink:href="http://docs.gunicorn.org/en/latest/deploy.html"
>gunicorn</link> as the wsgi host with an appropriate number
of synchronous workers. We strongly advise against deployments
using fastcgi, scgi, or uWSGI. We strongly advise against the
use of synthetic performance benchmarks when choosing a wsgi
server.</para>
<para>When using Apache, we recommend <link
xlink:href="https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/modwsgi/"
>mod_wsgi</link> to host dashboard.</para>
</section>
<section xml:id="ch025_web-dashboard-idp240704">
<title>HTTPS</title>
<para>
Deploy the dashboard behind a secure
<glossterm>HTTPS</glossterm> server by using a valid, trusted
certificate from a recognized certificate authority
(CA). Private organization-issued certificates are only
appropriate when the root of trust is pre-installed in all user
browsers.</para>
<para>Configure HTTP requests to the dashboard domain to redirect
to the fully qualified HTTPS URL.</para>
</section>
<section xml:id="ch025_web-dashboard-idp242624">
<title>HTTP Strict Transport Security (HSTS)</title>
<para>It is highly recommended to use HTTP Strict Transport
Security (HSTS).</para>
<note>
<para>If you are using an HTTPS proxy in front of your web
server, rather than using an HTTP server with HTTPS
functionality, follow the <link
xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#secure-proxy-ssl-header"
>Django documentation on modifying the SECURE_PROXY_SSL_HEADER
variable</link>.</para>
</note>
<para>See the chapter on PKI/SSL Everywhere for more specific
recommendations and server configurations for HTTPS
configurations, including the configuration of HSTS.</para>
</section>
<section xml:id="ch025_web-dashboard-idp245456">
<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
directly served from Apache or nginx and already benefits from
web host caching.</para>
</section>
<section xml:id="ch025_web-dashboard-idp246880">
<title>Domain names</title>
<para>Many organizations typically deploy web applications at
subdomains of an overarching organization domain. It is natural
for users to expect a domain of the form
<uri>openstack.example.org</uri>. In this context, there are
often many other applications deployed in the same second-level
namespace, often serving user-controlled content. This name
structure is convenient and simplifies name server
maintenance.</para>
<para>We strongly recommend deploying horizon to a
<emphasis>second-level domain</emphasis>, such as
<uri>https://example.com</uri>, and advise against deploying
horizon on a <emphasis>shared subdomain</emphasis> of any level,
for example <uri>https://openstack.example.org</uri> or
<uri>https://horizon.openstack.example.org</uri>. We also
advise against deploying to bare internal domains like
<uri>https://horizon/</uri>.</para>
<para>This recommendation is based on the limitations browser
same-origin-policy. The recommendations in this guide cannot
effectively protect users against known attacks if dashboard is
deployed on a domain which also hosts user-generated content,
such as scripts, images, or uploads of any kind, even if the
user-generated content is on a different subdomain. This
approach is used by most major web presences, such as
googleusercontent.com, fbcdn.com, github.io, and twimg.com, to
ensure that user generated content stays separate from cookies
and security tokens.</para>
<para>Additionally, if you decline to follow this recommendation
above about second-level domains, it is vital that you avoid the
cookie backed session store and employ HTTP Strict Transport
Security (HSTS). When deployed on a subdomain, dashboard's
security is only as strong as the weakest application deployed
on the same second-level domain.</para>
</section>
<section xml:id="ch025_web-dashboard-idp251760">
<title>Static media</title>
<para>Dashboard's static media should be deployed to a subdomain
of the dashboard domain and served by the web server. The use of
an external content delivery network (CDN) is also acceptable.
This subdomain should not set cookies or serve user-provided
content. The media should also be served with HTTPS.</para>
<para>Django media settings are documented at <link
xlink:href="https://docs.djangoproject.com/en/1.5/ref/settings/#static-root"
>https://docs.djangoproject.com/en/1.5/ref/settings/#static-root</link>.</para>
<para>Dashboard's default configuration uses <link
xlink:href="http://django-compressor.readthedocs.org/"
>django_compressor</link> to compress and minify css and
JavaScript content before serving it. This process should be
statically done before deploying dashboard, rather than using
the default in-request dynamic compression and copying the
resulting files along with deployed code or to the CDN server.
Compression should be done in a non-production build
environment. If this is not practical, we recommend disabling
resource compression entirely. Online compression dependencies
(less, nodejs) should not be installed on production
machines.</para>
</section>
<section xml:id="ch025_web-dashboard-idp255696">
<title>Secret key</title>
<para>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
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 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 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
tampered with, but the data itself is not encrypted other than
the encryption provided by HTTPS.</para>
<para>If your architecture allows it, we recommend using
<emphasis>django.contrib.sessions.backends.cache</emphasis> as
your session backend with memcache as the cache. Memcache must
not be exposed publicly, and should communicate over a secured
private channel. If you choose to use the signed cookies
backend, refer to the Django documentation understand the
security trade-offs.</para>
<para>For further details, consult the <link
xlink:href="https://docs.djangoproject.com/en/1.5/topics/http/sessions/#configuring-the-session-engine"
>Django session backend documentation</link>.</para>
</section>
<section xml:id="ch025_web-dashboard-idp262288">
<title>Allowed hosts</title>
<para>Configure the ALLOWED_HOSTS setting with the domain or
domains where the dashboard is available. Failure to configure this
setting (especially if not following the recommendation above
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"
>Django documentation on settings</link>.</para>
</section>
<section xml:id="ch025_web-dashboard-idp264272">
<title>Cookies</title>
<para>Session Cookies should be set to HTTPONLY:</para>
<programlisting>SESSION_COOKIE_HTTPONLY = True</programlisting>
<para>Never configure CSRF or session cookies to have a wild card
domain with a leading dot. Horizon's session and CSRF cookie
should be secured when deployed with HTTPS:</para>
<programlisting>Code CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True</programlisting>
</section>
<section xml:id="ch025_web-dashboard-idp266976">
<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
password manager. Organizations which forbid the browser
password manager should enforce this policy at the desktop
level.</para>
</section>
<section xml:id="ch025_web-dashboard-idp268448">
<title>Cross Site Request Forgery (CSRF)</title>
<para>Django has a dedicated middleware for <link
xlink:href="https://docs.djangoproject.com/en/1.5/ref/contrib/csrf/#how-it-works"
>cross-site request forgery</link> (CSRF).</para>
<para>Dashboard is designed to discourage developers from
introducing cross-site scripting vulnerabilities with custom
dashboards. However, it is important to audit custom dashboards,
especially ones that are javascript-heavy for inappropriate use
of the @csrf_exempt decorator. Dashboards which do not follow
these recommended security settings should be carefully
evaluated before restrictions are relaxed.</para>
</section>
<section xml:id="ch025_web-dashboard-idp270608">
<title>Cross Site Scripting (XSS)</title>
<para>Unlike many similar systems, OpenStack dashboard allows the
entire Unicode character set in most fields. This means
developers have less latitude to make escaping mistakes that
open attack vectors for cross-site scripting (XSS).</para>
<para>Dashboard provides tools for developers to avoid creating
XSS vulnerabilities, but they only work if developers use them
correctly. Audit any custom dashboards, paying particular
attention to use of the mark_safe function, use of is_safe with
custom template tags, the safe template tag, anywhere auto escape
is turned off, and any JavaScript which might evaluate
improperly escaped data.</para>
</section>
<section xml:id="ch025_web-dashboard-idp272832">
<title>Cross Origin Resource Sharing (CORS)</title>
<para>Configure your web server to send a restrictive CORS header
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>
<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
implemented a plan to prevent resource exhaustion and denial of
service.</para>
</section>
<section xml:id="ch025_web-dashboard-idp276864">
<title>Upgrading</title>
<para>Django security releases are generally well tested and
aggressively backwards compatible. In almost all cases, new
major releases of Django are also fully backwards compatible
with previous releases. Dashboard implementers are strongly
encouraged to run the latest stable release of Django with
up-to-date security releases.</para>
</section>
<section xml:id="ch025_web-dashboard-idp278672">
<title>Debug</title>
<para>Make sure DEBUG is set to False in production. In Django,
DEBUG displays stack traces and sensitive web server state
information on any exception.</para>
</section>
</chapter>

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

@@ -1,113 +0,0 @@
<?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"
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>
<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
<glossterm>SPICE</glossterm>. Below we provide some details on
the differences between these options.</para>
<section xml:id="ch026_compute-idp46336">
<title>Virtual Network Computer (VNC)</title>
<para>OpenStack can be configured to provide remote desktop console access to instances for tenants and/or administrators using the Virtual Network Computer (VNC) protocol.</para>
</section>
<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>
</listitem>
<listitem>
<para>The <command>nova</command> command-line utility can
return a URL for the VNC console for access by the
<systemitem class="service">nova</systemitem> Java VNC
client. This requires the <systemitem
class="service">nova-xvpvncproxy</systemitem> service to
bridge from the public network to the management
network.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch026_compute-idp51760">
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The <systemitem
class="service">nova-novncproxy</systemitem> and
<systemitem class="service">nova-xvpvncproxy</systemitem>
services by default open public-facing ports that are
token authenticated.</para>
</listitem>
<listitem>
<!-- TODO - check if havana had this feature -->
<para>By default, the remote desktop traffic is not encrypted. Havana is expected to have VNC connections secured by Kerberos.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch026_compute-idp54592">
<title>References</title>
<para><link xlink:href="http://blog.malchuk.ru/2013/05/21/47">Secure Connections to VNC ports</link></para>
</section>
<section xml:id="ch026_compute-idp55824">
<title>Simple Protocol for Independent Computing Environments (SPICE)</title>
<para>As an alternative to VNC, OpenStack provides remote desktop access to guest virtual machines using the Simple Protocol for Independent Computing Environments (SPICE) protocol.</para>
<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 <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>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch026_compute-idm4576">
<title>Limitations</title>
<itemizedlist><listitem>
<para>Although SPICE has many advantages over VNC, the spice-html5 browser integration currently doesn't really allow admins to take advantage of any of the benefits. To take advantage of SPICE features like multi-monitor, USB pass through, etc. admins are recommended to use a standalone SPICE client within the Management Network.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch026_compute-idp83168">
<title>Security considerations</title>
<itemizedlist><listitem>
<para>The <systemitem
class="service">nova-spicehtml5proxy</systemitem>
service by default opens public-facing ports that are
token authenticated.</para>
</listitem>
<listitem>
<para>The functionality and integration are still evolving. We will access the features in the next release and make recommendations.</para>
</listitem>
<listitem>
<para>As is the case for VNC, at this time we recommend using SPICE from the management network in addition to limiting use to few individuals.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch026_compute-idp86912">
<title>References</title>
<para><link xlink:href="http://docs.openstack.org/trunk/config-reference/content/spice-console.html">SPICE Console</link></para>
<para><link xlink:href="https://bugzilla.redhat.com/show_bug.cgi?id=913607">Red Hat bug 913607</link></para>
<para><link xlink:href="http://openstack.redhat.com/forum/discussion/67/resolved-spice-support-in-rdo-grizzly/p1">SPICE support in RDO Grizzly</link></para>
</section>
</section>
</section>
</chapter>

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

@@ -1,380 +0,0 @@
<?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"
version="5.0"
xml:id="ch027_storage">
<?dbhtml stop-chunking?>
<title>Object Storage</title>
<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
authentication mechanism.</para>
<para>A consumer can store objects, modify them, or access them
using the HTTP protocol and REST APIs. Backend components of
Object Storage use different protocols for keeping the
information synchronized in a redundant cluster of services.
For more details on the API and the backend components see the
<link
xlink:href="http://docs.openstack.org/api/openstack-object-storage/1.0/content/"
>OpenStack Storage documentation</link>.</para>
<para>For this document the components will be grouped into the
following primary groups:</para>
<orderedlist>
<listitem>
<para>Proxy services</para>
</listitem>
<listitem>
<para>Auth services</para>
</listitem>
<listitem>
<para>Storage services</para>
<itemizedlist>
<listitem>
<para>Account service</para>
</listitem>
<listitem>
<para>Container service</para>
</listitem>
<listitem>
<para>Object service</para>
</listitem>
</itemizedlist>
</listitem>
</orderedlist>
<figure>
<title>An example diagram from the OpenStack Object Storage
Administration Guide (2013)</title>
<mediaobject>
<imageobject>
<imagedata contentdepth="329" contentwidth="494"
fileref="static/swift_network_diagram-1.png"
format="PNG" scalefit="1"/>
</imageobject>
</mediaobject>
</figure>
<note>
<para>An Object Storage environment does not have to
necessarily be on the Internet and could also be a private
cloud with the "Public Switch" being part of the
organization's internal network infrastructure.</para>
</note>
<section xml:id="ch027_storage-idpA">
<title>First thing to secure – the network</title>
<para>The first aspect of a secure architecture design for
Object Storage is in the networking component. The Storage
service nodes use rsync between each other for copying
data to provide replication and high availability. In
addition, the proxy service communicates with the Storage
service when relaying data back and forth between the
end-point client and the cloud environment.</para>
<caution>
<para>None of these use any type of encryption or
authentication at this layer/tier.</para>
</caution>
<para>This is why you see a "Private Switch" or private
network ([V]LAN) in architecture diagrams. This data
domain should be separate from other OpenStack data
networks as well. For further discussion on security
domains please see <xref linkend="ch005_security-domains"
/>.</para>
<tip>
<para><emphasis>Rule:</emphasis> Use a private (V)LAN
network segment for your Storage services in the data
domain.</para>
</tip>
<para>This necessitates that the Proxy service nodes have dual
interfaces (physical or virtual):</para>
<orderedlist>
<listitem>
<para>One as a "public" interface for consumers to
reach</para>
</listitem>
<listitem>
<para>Another as a "private" interface with access to
the storage nodes</para>
</listitem>
</orderedlist>
<para>The following figure demonstrates one possible network
architecture.</para>
<figure>
<title>Object Storage network architecture with a
management node (OSAM)</title>
<mediaobject>
<imageobject role="html">
<imagedata contentdepth="913" contentwidth="1264"
fileref="static/swift_network_diagram-2.png"
format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/swift_network_diagram-2.png"
format="PNG" scalefit="1" width="100%"/>
</imageobject>
</mediaobject>
</figure>
</section>
<!-- First thing to secure – The Network -->
<section xml:id="ch027_storage-idpC1">
<title>Securing services – general</title>
<section xml:id="ch027_storage-idpC12">
<title>Service runas user</title>
<para>It is recommended that you configure each service to
run under a non-root (UID 0) service account. One
recommendation is the username "swift" with primary
group "swift."</para>
</section>
<section xml:id="ch027_storage-idpC123">
<title>File permissions</title>
<para>The <filename>/etc/swift</filename> directory
contains information about the ring topology and
environment configuration. The following permissions are
recommended:</para>
<screen><prompt>#</prompt> <userinput>chown -R root:swift /etc/swift/*</userinput>
<prompt>#</prompt> <userinput>find /etc/swift/ -type f -exec chmod 640 {} \;</userinput>
<prompt>#</prompt> <userinput>find /etc/swift/ -type d -exec chmod 750 {} \;</userinput></screen>
<para>This restricts only root to be able to modify
configuration files while allowing the services to
read them through their group membership in
the swift group.</para>
</section>
</section>
<!-- Securing Services – General -->
<section xml:id="ch027_storage-idpD1">
<title>Securing storage services</title>
<para>The following are the default listening ports for the
various storage services:</para>
<informaltable>
<thead>
<tr>
<td>Service name</td>
<td>Port</td>
<td>Type</td>
</tr>
</thead>
<tbody>
<tr>
<td>Account service</td>
<td>6002</td>
<td>TCP</td>
</tr>
<tr>
<td>Container service</td>
<td>6001</td>
<td>TCP</td>
</tr>
<tr>
<td>Object service</td>
<td>6000</td>
<td>TCP</td>
</tr>
<tr>
<td>Rsync</td>
<td>873</td>
<td>TCP</td>
</tr>
</tbody>
</informaltable>
<para>Authentication does not happen at this level in Object
Storage. If someone was able to connect to a Storage
service node on one of these ports they could access or
modify data without authentication. In order to secure
against this issue you should follow the recommendations
given previously about using a private storage
network.</para>
<section xml:id="ch027_storage-idpD12">
<title>Object storage "account" terminology</title>
<para>An Object Storage "Account" is not a user account or
credential. The following explains the
relations:</para>
<informaltable>
<tbody>
<tr>
<td>OpenStack Object Storage Account</td>
<td>Collection of containers; not user
accounts or authentication. Which users
are associated with the account and how
they may access it depends on the
authentication system used. See
authentication systems later. Referred to
in this document as OSSAccount.</td>
</tr>
<tr>
<td>OpenStack Object Storage Containers</td>
<td>Collection of objects. Metadata on the
container is available for ACLs. The
meaning of ACLs is dependent on the
authentication system used.</td>
</tr>
<tr>
<td>OpenStack Object Storage Objects</td>
<td>The actual data objects. ACLs at the
object level are also possible with
metadata. It is dependent on the
authentication system used.</td>
</tr>
</tbody>
</informaltable>
<tip>
<para>
<?dbhtml bgcolor="#DDFADE" ?><?dbfo bgcolor="#DDFADE" ?>
Another way of thinking about the above would be:
A single shelf (Account) holds zero or more ->
buckets (Containers) which each hold zero or more
-> objects. A garage (Object Storage cloud
environment) may have multiple shelves (Accounts)
with each shelf belonging to zero or more
users.</para>
</tip>
<para>At each level you may have ACLs that dictate who has
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
are also possible. Please see the Object Storage
Authentication section for more information.</para>
</section>
</section>
<!-- Securing Storage Services -->
<section xml:id="ch027_storage-idpE1">
<title>Securing proxy services</title>
<para>A Proxy service node should have at least two interfaces
(physical or virtual): one public and one
private. Firewalls or service binding might protect the
public interface. The public facing service is an HTTP web
server that processes end-point client requests,
authenticates them, and performs the appropriate
action. The private interface does not require any
listening services but is instead used to establish
outgoing connections to storage service nodes on the
private storage network.</para>
<section xml:id="ch027_storage-idpE12">
<title>Use SSL/TLS</title>
<para>The built-in or included web server that comes with
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
current work around is to not use the built-in web
server but an alternative web server instead that
supports sending both the public server certificate as
well as the CA signing authorities intermediate
certificate(s). This allows for end-point clients that
have the CA root certificate in their trust store to
be able to successfully validate your cloud
environment's SSL certificate and chain. An example of
how to do this with mod_wsgi and Apache is given
below. Also consult the <link
xlink:href="http://docs.openstack.org/developer/swift/apache_deployment_guide.html"
>Apache Deployment Guide</link></para>
<screen><prompt>#</prompt> <userinput>apt-get install libapache2-mod-wsgi</userinput></screen>
<para>Modify file
<filename>/etc/apache2/envvars</filename>
with</para>
<programlisting>export APACHE_RUN_USER=swift
export APACHE_RUN_GROUP=swift</programlisting>
<para>An alternative is to modify your Apache conf file
with</para>
<programlisting>User swift
Group swift</programlisting>
<para>Create a <filename>swift</filename> directory in
your Apache document root:</para>
<screen><prompt>#</prompt> <userinput>mkdir /var/www/swift/</userinput></screen>
<para>Create the file
<filename>$YOUR_APACHE_DOC_ROOT/swift/proxy-server.wsgi</filename>:</para>
<programlisting>from swift.common.wsgi import init_request_processor application, conf, logger, log_name = \
init_request_processor('/etc/swift/proxy-server.conf','proxy-server')</programlisting>
</section>
<section xml:id="ch027_storage-idpF1">
<title>HTTP listening port</title>
<para>You should run your Proxy service web server as a
non-root (no UID 0) user such as "swift" mentioned
before. The use of a port greater than 1024 is
required to make this easy and avoid running any part
of the web container as root. Doing so is not a burden
as end-point clients are not typically going to type
in the URL manually into a web browser to browse
around in the object storage. Additionally, for
clients using the HTTP REST API and performing
authentication they will normally automatically grab
the full REST API URL they are to use as provided by
the authentication response. OpenStack’s REST API
allows for a client to authenticate to one URL and
then be told to use a completely different URL for the
actual service. Example: Client authenticates to
<uri>https://identity.cloud.example.org:55443/v1/auth</uri>
and gets a response with their authentication key and
Storage URL (the URL of the proxy nodes or load
balancer) of
<uri>https://swift.cloud.example.org:44443/v1/AUTH_8980</uri>.</para>
<para>The method for configuring your web server to start
and run as a non-root user varies by web server and
OS.</para>
</section>
<section xml:id="ch027_storage-idpG1">
<title>Load balancer</title>
<para>If the option of using Apache is not feasible or for
performance you wish to offload your SSL work you may
employ a dedicated network device load balancer. This
is also the common way to provide redundancy and load
balancing when using multiple proxy nodes.</para>
<para>If you choose to offload your SSL ensure that the
network link between the load balancer and your proxy
nodes is on a private (V)LAN segment such that other
nodes on the network (possibly compromised) cannot
wiretap (sniff) the unencrypted traffic. If such a
breach were to occur the attacker could gain access to
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
different URL in the responses to end-clients so they
use your load balancer instead of an individual Proxy
service node.</para>
</section>
</section>
<!-- Securing Proxy Services -->
<section xml:id="ch027_storage-idpH1">
<title>Object storage authentication</title>
<para>Object Storage uses wsgi to provide a middleware for
authentication of end-point clients. The authentication
provider defines what roles and user types exist. Some use
traditional username and password credentials while others
may leverage API key tokens or even client-side x.509 SSL
certificates. Custom providers can be integrated in using
the wsgi model.</para>
<section xml:id="ch027_storage-idpH12">
<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
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,
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/"
>http://gholt.github.io/swauth/</link>.</para>
</section>
</section>
<!-- Object Storage Authentication -->
<section xml:id="ch027_storage-idpI1">
<title>Other notable items</title>
<para>In <filename>/etc/swift/swift.conf</filename> on every
service node there is a
<option>swift_hash_path_suffix</option> setting. This is
provided to reduce the chance of hash collisions for objects
being stored and avert one user overwriting the data of
another user.</para>
<para>This value should be initially set with a
cryptographically secure random number generator and
consistent across all service nodes. Ensure that it is
protected with proper ACLs and that you have a backup copy
to avoid data loss.</para>
</section>
</chapter>

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

@@ -1,66 +0,0 @@
<?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"
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
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>
<para>
Because Bob must support authentication for the general
public, he decides to use use user name and 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 through 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
<option>HORIZON_IMAGES_ALLOW_UPLOAD</option> to prevent resource
exhaustion.</para>
<para>Bob decides to use VNC for his virtual console for its
maturity and security features.</para>
</section>
</chapter>

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

@@ -1,21 +0,0 @@
<?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"
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 through 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>
</chapter>

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

@@ -1,176 +0,0 @@
<?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"
version="5.0"
xml:id="ch031_neutron-architecture">
<?dbhtml stop-chunking?>
<title>Networking architecture</title>
<para>
OpenStack Networking is a standalone service that often deploys
several processes across a number of nodes. These processes
interact with each other and other OpenStack services. The main
process of the OpenStack Networking service is <systemitem
class="service">neutron-server</systemitem>, a Python daemon that
exposes the OpenStack Networking API and passes tenant requests to
a suite of plug-ins for additional processing.</para>
<para>
The OpenStack Networking components are:</para>
<variablelist>
<varlistentry>
<term>neutron server (<systemitem
class="service">neutron-server</systemitem> and <systemitem
class="service">neutron-*-plugin</systemitem>)</term>
<listitem>
<para>
This service runs on the network node to service the
Networking API and its extensions. It also enforces the
network model and IP addressing of each port. The
neutron-server and plugin agents require access to a
database for persistent storage and access to a message
queue for inter-communication.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>plugin agent (<systemitem class="service">neutron-*-agent</systemitem>)
</term>
<listitem>
<para>Runs on each compute node to manage local virtual
switch (vswitch) configuration. The plug-in that you use
determine which agents run. This service requires message
queue access. <emphasis>Optional depending on
plugin.</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term>DHCP agent (<systemitem class="service">neutron-dhcp-agent</systemitem>)
</term>
<listitem>
<para>
Provides DHCP services to tenant networks. This agent is
the same across all plug-ins and is responsible for
maintaining DHCP configuration. The <systemitem
class="service">neutron-dhcp-agent</systemitem> requires
message queue access.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>L3 agent (<systemitem class="service">neutron-l3-agent</systemitem>)
</term>
<listitem>
<para>
Provides L3/NAT forwarding for external network access of
VMs on tenant networks. Requires message queue
access. <emphasis>Optional depending on
plug-in.</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term>network provider services (SDN server/services)</term>
<listitem>
<para>
Provide additional networking services to tenant
networks. These SDN services might interact with the
<systemitem class="service">neutron-server</systemitem>,
<systemitem class="service">neutron-plugin</systemitem>,
and/or plugin-agents through REST APIs or other
communication channels.</para>
</listitem>
</varlistentry>
</variablelist>
<para>
The following figure shows an architectural and networking
flow diagram of the OpenStack Networking components:</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="319" contentwidth="536"
fileref="static/sdn-connections.png"
format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/sdn-connections.png" format="PNG"
scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject>
</para>
<section xml:id="ch031_neutron-architecture-idp61360">
<title>OpenStack Networking service placement on physical servers</title>
<para>
This guide focuses 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>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="364" contentwidth="536"
fileref="static/1aa-network-domains-diagram.png"
format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/1aa-network-domains-diagram.png"
format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject>
</para>
<para>A standard OpenStack Networking setup has up to four
distinct physical data center networks:</para>
<variablelist>
<varlistentry>
<term>Management network</term>
<listitem>
<para>
Used for internal communication between OpenStack
Components. The IP addresses on this network should be
reachable only within the data center and is
considered the Management Security Domain.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Guest network</term>
<listitem>
<para>
Used for VM data communication within the cloud
deployment. The IP addressing requirements of this
network depend on the OpenStack Networking plug-in in
use and the network configuration choices of the
virtual networks made by the tenant. This network is
considered the Guest Security Domain.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>External network</term>
<listitem>
<para>
Used to provide VMs with Internet access in some
deployment scenarios. The IP addresses on this network
should be reachable by anyone on the Internet and is
considered to be in the Public Security Domain.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>API network</term>
<listitem>
<para>
Exposes all OpenStack APIs, including the OpenStack
Networking API, to tenants. The IP addresses on this
network should be reachable by anyone on the
Internet. This may be the same network as the external
network, as it is possible to create a subnet for the
external network that uses IP allocation ranges to use
only less than the full range of IP addresses in an IP
block. This network is considered the Public Security
Domain.</para>
</listitem>
</varlistentry>
</variablelist>
<para>
For additional information see the <link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html">Networking
chapter</link> in the <citetitle>OpenStack Cloud
Administrator Guide</citetitle>.</para>
</section>
</section>
</chapter>

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

@@ -1,128 +0,0 @@
<?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"
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>
<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>
<para>VLANs are realized as packets on a specific physical network containing IEEE 802.1Q headers with a specific VLAN ID (VID) field value. VLAN networks sharing the same physical network are isolated from each other at L2, and can even have overlapping IP address spaces. Each distinct physical network supporting VLAN networks is treated as a separate VLAN trunk, with a distinct space of VID values. Valid VID values are 1 through 4094.</para>
<para>VLAN configuration complexity depends on your OpenStack design requirements. In order to allow OpenStack Networking to efficiently use VLANs, you must allocate a VLAN range (one for each tenant) and turn each compute node physical switch port into a VLAN trunk port.</para>
<note>
<para>NOTE: If you intend for your network to support more than 4094 tenants VLAN is probably not the correct option for you as multiple 'hacks' are required to extend the VLAN tags to more than 4094 tenants.</para>
</note>
</section>
<section xml:id="ch032_networking-best-practices-idp50512">
<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>
<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>
<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
through OpenStack Networking.</para>
</section>
<section xml:id="ch032_networking-best-practices-idp59008">
<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>
</section>
<section xml:id="ch032_networking-best-practices-idp62880">
<title>Quality of Service (QoS)</title>
<para>The ability to set QoS on the virtual interface ports of tenant instances is a current deficiency for OpenStack Networking. The application of QoS for traffic shaping and rate-limiting at the physical network edge device is insufficient due to the dynamic nature of workloads in an OpenStack deployment and can not be leveraged in the traditional way. QoS-as-a-Service (QoSaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. QoSaaS is planning to provide the following services:</para>
<itemizedlist><listitem>
<para>Traffic shaping through DSCP markings</para>
</listitem>
<listitem>
<para>Rate-limiting on a per port/network/tenant basis.</para>
</listitem>
<listitem>
<para>Port mirroring (through open source or third-party plug-ins)</para>
</listitem>
<listitem>
<para>Flow analysis (through open source or third-party plug-ins)</para>
</listitem>
</itemizedlist>
<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>
<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">
<title>Firewalls</title>
<para>FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plug-ins in development for extensions in OpenStack Networking to support this.</para>
<para>It is critical during the design of an OpenStack Networking infrastructure to understand the current features and limitations of network services that are available. Understanding where the boundaries of your virtual and physical networks will help you add the required security controls in your environment.</para>
</section>
</section>
<section xml:id="ch032_networking-best-practices-idp74544">
<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
Hyper-V plug-in, Extreme Networks plug-in, Juniper Networks
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>
<para>OpenStack Networking has the following known limitations:</para>
<variablelist>
<varlistentry>
<term>Overlapping IP addresses</term>
<listitem>
<para>
If nodes that run either <systemitem
class="service">neutron-l3-agent</systemitem> or
<systemitem
class="service">neutron-dhcp-agent</systemitem> 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>
<para>
If network namespace support is not present, a further
limitation of the L3 agent is that only a single logical
router is supported.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Multi-host DHCP-agent</term>
<listitem>
<para>
OpenStack Networking supports multiple L3 and DHCP
agents with load balancing. However, tight coupling of
the location of the virtual machine is not
supported.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>No IPv6 support for L3 agents</term>
<listitem>
<para>
The neutron-l3-agent, used by many plug-ins to implement
L3 forwarding, supports only IPv4 forwarding.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</chapter>

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

@@ -1,89 +0,0 @@
<?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"
version="5.0"
xml:id="ch033_securing-neutron-services">
<?dbhtml stop-chunking?>
<title>Securing OpenStack Networking services</title>
<para>
To secure OpenStack Networking, you must understand how 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>
<para>OpenStack dashboard: Public and management</para>
</listitem>
<listitem>
<para>OpenStack Identity: Management</para>
</listitem>
<listitem>
<para>OpenStack compute node: Management and guest</para>
</listitem>
<listitem>
<para>OpenStack network node: Management, guest, and possibly
public depending upon neutron-plugin in use.</para>
</listitem>
<listitem>
<para>SDN services node: Management, guest and possibly
public depending upon product used.</para>
</listitem>
</itemizedlist>
<para>
<inlinemediaobject>
<imageobject role="html">
<imagedata contentdepth="454" contentwidth="682"
fileref="static/1aa-logical-neutron-flow.png"
format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%"
fileref="static/1aa-logical-neutron-flow.png"
format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject>
</para>
<para>To isolate sensitive data communication between the
OpenStack Networking services and other OpenStack core
services, configure these communication channels to only allow
communication over an isolated management network.</para>
<section xml:id="ch033_securing-neutron-services-idp55312">
<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>
<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
bind_host = <replaceable>IP ADDRESS OF SERVER</replaceable>
# Port the bind the API server to
bind_port = 9696</programlisting>
</section>
<section xml:id="ch033_securing-neutron-services-idp58320">
<title>Restrict DB and RPC communication of the OpenStack
Networking services</title>
<para>
Various components of the OpenStack Networking services use
either the messaging queue or database connections to
communicate with other components in OpenStack
Networking.</para>
<para>
It is recommended that you follow the guidelines provided in
the Database Authentication and Access Control chapter in
the Database section for all components that require direct
DB connections.</para>
<para>
It is recommended that you follow the guidelines provided in
the Queue Authentication and Access Control chapter in the
Messaging section for all components that require RPC
communication.</para>
</section>
</section>
</chapter>

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

@@ -1,115 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter [
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
%openstack;
]>
<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>
<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>
<para>A policy engine and its configuration file,
<filename>policy.json</filename>, within OpenStack Networking
provides a method to provide finer grained authorization of
users on tenant networking methods and objects. It is important
that cloud architects and operators evaluate their design and
use cases in providing users and tenants the ability to create,
update, and destroy available network resources as it has a
tangible effect on tenant network availability, network
security, and overall OpenStack security. For a more detailed
explanation of OpenStack Networking policy definition, please
refer to the <link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_networking_auth.html">Authentication
and authorization section</link> in the <citetitle>OpenStack
Cloud Administrator Guide</citetitle>.</para>
<note><para>It is important to review the default networking
resource policy and modify the policy appropriately for your
security posture.</para></note>
<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&mdash;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>
<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,
<filename>nova.conf</filename> 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><option>firewall_driver</option> must be set to
<literal>nova.virt.firewall.NoopFirewallDriver</literal> so
that <systemitem class="service">nova-compute</systemitem>
does not perform iptables-based filtering itself.</para>
</listitem>
<listitem>
<para><option>security_group_api</option> must be set to
<literal>neutron</literal> so that all security group
requests are proxied to the OpenStack Networking
service.</para>
</listitem>
</itemizedlist>
<para>Security groups and security group rules 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. A security group is a container for security group rules. When a virtual interface port is created in OpenStack Networking it is associated with a security group. If a security group is not specified, the port will be associated with a 'default' security group. By default this group will drop all ingress traffic and allow all egress. Rules can be added to this group in order to change the behaviour.</para>
<para>When using the security group API through OpenStack Compute, security groups are applied to all virtual interface ports on an instance. The reason for this is that OpenStack Compute security group APIs are instance based and not virtual interface port based as OpenStack Networking.</para>
</section>
<section xml:id="ch034_tenant-secure-networking-best-practices-idp58016">
<title>Quotas</title>
<para>Quotas provide the ability to limit the number of network
resources available to tenants. You can enforce default quotas
for all tenants. The
<filename>/etc/neutron/neutron.conf</filename> includes these
options for quota:</para>
<programlisting language="ini">[QUOTAS]
# resource name(s) that are supported in quota features
quota_items = network,subnet,port
# default number of resource allowed per tenant, minus for unlimited
#default_quota = -1
# number of networks allowed per tenant, and minus means unlimited
quota_network = 10
# number of subnets allowed per tenant, and minus means unlimited
quota_subnet = 10
# number of ports allowed per tenant, and minus means unlimited
quota_port = 50
# number of security groups allowed per tenant, and minus means unlimited
quota_security_group = 10
# number of security group rules allowed per tenant, and minus means unlimited
quota_security_group_rule = 100
# default driver to use for quota checks
quota_driver = neutron.quota.ConfDriver</programlisting>
<para>
OpenStack Networking also supports per-tenant quotas limit
through a quota extension API. To enable per-tenant quotas,
you must set the <literal>quota_driver</literal> option in
<filename>neutron.conf</filename>.</para>
<programlisting language="ini">quota_driver = neutron.db.quota_db.DbQuotaDriver</programlisting>
</section>
</chapter>

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

@@ -1,47 +0,0 @@
<?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"
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>
<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
tenants, networks and workload type. This environment can be
designed to limit what available network resources are available
to the tenant and what are the various default quotas and
security policies are available. The network policy engine can
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
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>
<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
application are either existing enterprise application or newly
deployed applications. Since Bob's public cloud is a
multi-tenancy enterprise service, the choice to use for L2
isolation in this environment is to use overlay
networking. Another aspect of Bob's cloud is the self-service
aspect where the customer can provision available networking
services as needed. These networking services encompass L2
networks, L3 Routing, Network <glossterm>ACL</glossterm> and
NAT. It is important that per-tenant quota's be implemented in
this environment.</para>
<para>An added benefit with utilizing OpenStack Networking is
when new advanced networking services become available, these
new features can be easily provided to the end customers.</para>
</section>
</chapter>

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

@@ -1,45 +0,0 @@
<?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"
version="5.0"
xml:id="ch037_risks">
<?dbhtml stop-chunking?>
<title>Message queuing architecture</title>
<para>Message queuing services facilitate inter-process
communication in OpenStack. OpenStack supports these message
queuing service back ends:</para>
<itemizedlist>
<listitem>
<para>RabbitMQ</para>
</listitem>
<listitem>
<para>Qpid</para>
</listitem>
<listitem>
<para>ZeroMQ or 0MQ</para>
</listitem>
</itemizedlist>
<para>Both RabbitMQ and Qpid are Advanced Message Queuing Protocol
(AMQP) frameworks, which provide message queues for peer-to-peer
communication. Queue implementations are typically deployed as a
centralized or decentralized pool of queue servers. ZeroMQ
provides direct peer-to-peer communication through TCP
sockets.</para>
<para>Message queues effectively facilitate command and control
functions across OpenStack deployments. Once access to the queue
is permitted no further authorization checks are performed.
Services accessible through the queue do validate the contexts and
tokens within the actual message payload. However, you must note
the expiration date of the token because tokens are potentially
re-playable and can authorize other services in the
infrastructure.</para>
<para>OpenStack does not support message-level confidence, such as
message signing. Consequently, you must secure and authenticate
the message transport itself. For high-availability (HA)
configurations, you must perform queue-to-queue authentication and
encryption.</para>
<para>With ZeroMQ messaging, IPC sockets are used on individual
machines. Because these sockets are vulnerable to attack, ensure
that the cloud operator has secured them.</para>
</chapter>

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

@@ -1,153 +0,0 @@
<?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"
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>
<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>
<para>The following lines should be added to the system-wide
RabbitMQ configuration file, typically
<filename>/etc/rabbitmq/rabbitmq.config</filename>:
</para>
<programlisting>[
{rabbit, [
{tcp_listeners, [] },
{ssl_listeners, [{"&lt;ip address or hostname of management network interface", 5671}] },
{ssl_options, [{cacertfile,"/etc/ssl/cacert.pem"},
{certfile,"/etc/ssl/rabbit-server-cert.pem"},
{keyfile,"/etc/ssl/rabbit-server-key.pem"},
{verify,verify_peer},
{fail_if_no_peer_cert,true}]}
]}
].</programlisting>
<para>Note, the <literal>tcp_listeners</literal> option is set
to <literal>[]</literal> to prevent it from listening an on
non-SSL port. The <literal>ssl_listeners</literal> option
should be restricted to only listen on the management network
for the services.</para>
<para>For more information on RabbitMQ SSL configuration see:</para>
<itemizedlist><listitem>
<para>
<link xlink:href="http://www.rabbitmq.com/configure.html">RabbitMQ Configuration</link>
</para>
</listitem>
<listitem>
<para><link xlink:href="http://www.rabbitmq.com/ssl.html">RabbitMQ SSL</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp46320">
<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>
</listitem>
</itemizedlist>
</section>
</section>
<section xml:id="ch038_transport-security-idp48960">
<title>Queue authentication and access control</title>
<para>RabbitMQ and Qpid offer authentication and access control mechanisms for controlling access to queues. ZeroMQ offers no such mechanisms.</para>
<para>Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. Both RabbitMQ and Qpid offer SASL and other pluggable authentication mechanisms beyond simple usernames and passwords that allow for increased authentication security. While RabbitMQ supports SASL, support in OpenStack does not currently allow for requesting a specific SASL authentication mechanism. RabbitMQ support in OpenStack allows for either username and password authentication over an unencrypted connection or username and password in conjunction with X.509 client certificates to establish the secure SSL connection.</para>
<para>We recommend configuring X.509 client certificates on all the OpenStack service nodes for client connections to the messaging queue and where possible (currently only Qpid) perform authentication with X.509 client certificates. When using usernames and passwords, accounts should be created per-service and node for finer grained auditability of access to the queue.</para>
<para>
Before deployment, consider the SSL libraries that the queuing
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>
<para>On the RabbitMQ server, delete the default
<literal>guest</literal> user:</para>
<screen><prompt>#</prompt> <userinput>rabbitmqctl delete_user quest</userinput></screen>
<para>On the RabbitMQ server, for each OpenStack service or
node that communicates with the message queue set up user
accounts and privileges:</para>
<screen><prompt>#</prompt> <userinput>rabbitmqctl add_user compute01 password</userinput>
<prompt>#</prompt> <userinput>rabbitmqctl set_permissions compute01 ".*"".*"".*"</userinput></screen>
<para>For additional configuration information see:</para>
<itemizedlist><listitem>
<para><link xlink:href="http://www.rabbitmq.com/access-control.html">RabbitMQ Access Control</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.rabbitmq.com/authentication.html">RabbitMQ Authentication</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.rabbitmq.com/plugins.html">RabbitMQ Plugins</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://hg.rabbitmq.com/rabbitmq-auth-mechanism-ssl/file/rabbitmq_v3_1_3/README">RabbitMQ SASL External Auth</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp59648">
<title>OpenStack service configuration: RabbitMQ</title>
<programlisting language="ini">[DEFAULT]
rpc_backend=nova.openstack.common.rpc.impl_kombu
rabbit_use_ssl=True
rabbit_host=
rabbit_port=5671
rabbit_user=compute01
rabbit_password=password
kombu_ssl_keyfile=/etc/ssl/node-key.pem
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>
<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>
</listitem>
<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-Authorization">Apache Qpid Authorization</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch038_transport-security-idp65584">
<title>OpenStack service configuration: Qpid</title>
<programlisting language="ini">
[DEFAULT]
rpc_backend=nova.openstack.common.rpc.impl_qpid
qpid_protocol=ssl
qpid_hostname=&lt;ip or hostname of management network interface of messaging server&gt;
qpid_port=5671qpid_username=compute01
qpid_password=password</programlisting>
<para>Optionally, if using SASL with Qpid specify the SASL mechanisms in use by adding:</para>
<programlisting language="ini">qpid_sasl_mechanisms=&lt;space separated list of SASL mechanisms to use for auth&gt;</programlisting>
</section>
</section>
<section xml:id="ch038_transport-security-idp68512">
<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">
<title>Namespaces</title>
<para>Network namespaces are highly recommended for all services running on OpenStack Compute Hypervisors. This will help prevent against the bridging of network traffic between VM guests and the management network.</para>
<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 through 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>
<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>
<para>Use both mandatory access controls (MACs) and discretionary access controls (DACs) to restrict the configuration for processes to only those processes. This restriction prevents these processes from being isolated from other processes that run on the same machine.(s).</para>
</section>
</section>
</chapter>

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

@@ -1,19 +0,0 @@
<?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"
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>
<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>
<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>
</chapter>

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

@@ -1,34 +0,0 @@
<?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"
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 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>
<para><link xlink:href="https://www.owasp.org/index.php/OWASP_Backend_Security_Project_MySQL_Hardening">OWASP MySQL Hardening</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://dev.mysql.com/doc/refman/5.5/en/pluggable-authentication.html">MySQL Pluggable Authentication</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://downloads.mysql.com/docs/mysql-security-excerpt-5.1-en.pdf">Security in MySQL</link></para>
</listitem>
</itemizedlist>
<para>PostgreSQL:</para>
<itemizedlist><listitem>
<para><link xlink:href="https://www.owasp.org/index.php/OWASP_Backend_Security_Project_PostgreSQL_Hardening">OWASP PostgreSQL Hardening</link></para>
</listitem>
<listitem>
<para><link xlink:href="http://www.ibm.com/developerworks/opensource/library/os-postgresecurity">Total security in a PostgreSQL database</link></para>
</listitem>
</itemizedlist>
</section>
</chapter>

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

@@ -1,123 +0,0 @@
<?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"
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>
<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>
<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"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/databaseusername.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
</section>
<section xml:id="ch042_database-overview-idp53264">
<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>
<para>All database communications be isolated to a management network</para>
</listitem>
<listitem>
<para>Securing communications using SSL</para>
</listitem>
<listitem>
<para>Creating unique database user accounts per OpenStack service endpoint (illustrated below)</para>
</listitem>
</itemizedlist>
<informalfigure>
<mediaobject>
<imageobject role="html">
<imagedata contentdepth="283" contentwidth="355" fileref="static/databaseusernamessl.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/databaseusernamessl.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</mediaobject>
</informalfigure>
</section>
</section>
<section xml:id="ch042_database-overview-idp83456">
<title>Database authentication and access control</title>
<para>Given the risks around access to the database, we strongly recommend that unique database user accounts be created per node needing access to the database. Doing this facilitates better analysis and auditing for ensuring compliance or in the event of a compromise of a node allows you to isolate the compromised host by removing access for that node to the database upon detection. When creating these per service endpoint database user accounts, care should be taken to ensure that they are configured to require SSL. Alternatively, for increased security it is recommended that the database accounts be configured using X.509 certificate authentication in addition to usernames and passwords.</para>
<section xml:id="ch042_database-overview-idp85888">
<title>Privileges</title>
<para>A separate database administrator (DBA) account should be created and protected that has full privileges to create/drop databases, create user accounts, and update user privileges. This simple means of separation of responsibility helps prevent accidental misconfiguration, lowers risk and lowers scope of compromise.</para>
<para>The database user accounts created for the OpenStack services and for each node should have privileges limited to just the database relevant to the service where the node is a member.</para>
</section>
</section>
<section xml:id="ch042_database-overview-idp88080">
<title>Require user accounts to require SSL transport</title>
<section xml:id="ch042_database-overview-idp88784">
<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>
<para>In file <filename>pg_hba.conf</filename>:</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>
<para>
The <literal>md5</literal> parameter defines the
authentication method as a hashed password. We provide a
secure authentication example in the section below.</para>
</section>
</section>
<section xml:id="ch042_database-overview-idp93120">
<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>
<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>
<programlisting>hostssl dbname compute01 hostname cert</programlisting>
</section>
</section>
<section xml:id="ch042_database-overview-idp97536">
<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>
<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>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="304" contentwidth="593" fileref="static/novaconductor.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/novaconductor.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</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>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]
use_local = true</programlisting>
</section>
</chapter>

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

@@ -1,103 +0,0 @@
<?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"
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>
<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>
<para>In <filename>my.cnf</filename>:</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>
<para>In <filename>postgresql.conf</filename>:</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>
<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 through 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>
When installing the certificate and key files, ensure that
the file permissions are restricted, for example
<command>chmod 0600</command>, 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>
<para>The following lines should be added in the system-wide
MySQL configuration file:</para>
<para>In <filename>my.cnf</filename>:</para>
<programlisting>[[mysqld]]
...
ssl-ca=/path/to/ssl/cacert.pem
ssl-cert=/path/to/ssl/server-cert.pem
ssl-key=/path/to/ssl/server-key.pem</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>
<programlisting>ssl-cipher='cipher:list'</programlisting>
</section>
<section xml:id="ch043_database-transport-security-idp50288">
<title>PostgreSQL SSL configuration</title>
<para>
The following lines should be added in the system-wide
PostgreSQL configuration file,
<filename>postgresql.conf</filename>.</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>
<programlisting>ssl-ciphers = 'cipher:list'</programlisting>
<para>The server certificate, key, and certificate authority
(CA) files should be placed in the $PGDATA directory in the
following files:</para>
<itemizedlist><listitem>
<para><filename>$PGDATA/server.crt</filename> - Server
certificate</para>
</listitem>
<listitem>
<para><filename>$PGDATA/server.key</filename> - Private key
corresponding to <filename>server.crt</filename></para>
</listitem>
<listitem>
<para><filename>$PGDATA/root.crt</filename> - Trusted
certificate authorities</para>
</listitem>
<listitem>
<para><filename>$PGDATA/root.crl</filename> - Certificate
revocation list</para>
</listitem>
</itemizedlist>
</section>
</chapter>

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

@@ -1,18 +0,0 @@
<?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"
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>
<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>
<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>

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

@@ -1,156 +0,0 @@
<?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"
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>
</listitem>
<listitem>
<para>Data disposal</para>
</listitem>
</itemizedlist>
<section xml:id="ch046_data-residency-idp46544">
<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>Object Storage objects</para>
</listitem>
<listitem>
<para>Compute instance ephemeral filesystem storage</para>
</listitem>
<listitem>
<para>Compute instance memory</para>
</listitem>
<listitem>
<para>Block Storage volume data</para>
</listitem>
<listitem>
<para>Public keys for Compute Access</para>
</listitem>
<listitem>
<para>Virtual Machine Images in the Image Service</para>
</listitem>
<listitem>
<para>Machine snapshots</para>
</listitem>
<listitem>
<para>Data passed to OpenStack Compute's configuration-drive extension</para>
</listitem>
</itemizedlist>
<para>Metadata stored by an OpenStack cloud includes the following non-exhaustive items:</para>
<itemizedlist><listitem>
<para>Organization name</para>
</listitem>
<listitem>
<para>User's "Real Name"</para>
</listitem>
<listitem>
<para>Number or size of running instances, buckets, objects, volumes, and other quota-related items</para>
</listitem>
<listitem>
<para>Number of hours running instances or storing data</para>
</listitem>
<listitem>
<para>IP addresses of users</para>
</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>
<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>
</blockquote>
<para>General data disposal and sanitization guidelines as adopted from NIST recommended security controls. Cloud operators should:</para>
<orderedlist><listitem>
<para>Track, document and verify media sanitization and disposal actions.</para>
</listitem>
<listitem>
<para>Test sanitation equipment and procedures to verify
proper performance.</para>
</listitem>
<listitem>
<para>Sanitize portable, removable storage devices prior to connecting such devices to the cloud infrastructure.</para>
</listitem>
<listitem>
<para>Destroy cloud system media that cannot be sanitized.</para>
</listitem>
</orderedlist>
<para>In an OpenStack deployment you will need to address the following:</para>
<itemizedlist><listitem>
<para>Secure data erasure</para>
</listitem>
<listitem>
<para>Instance memory scrubbing</para>
</listitem>
<listitem>
<para>Block Storage volume data</para>
</listitem>
<listitem>
<para>Compute instance ephemeral storage</para>
</listitem>
<listitem>
<para>Bare metal server sanitization</para>
</listitem>
</itemizedlist>
<section xml:id="ch046_data-residency-idp73264">
<title>Data not securely erased</title>
<para>Within OpenStack some data may be deleted, but not securely erased in the context of the NIST standards outlined above. This is generally applicable to most or all of the above-defined metadata and information stored in the database. This may be remediated with database and/or system configuration for auto vacuuming and periodic free-space wiping.</para>
</section>
<section xml:id="ch046_data-residency-idp75184">
<title>Instance memory scrubbing</title>
<para>Specific to various hypervisors is the treatment of instance memory. This behavior is not defined in OpenStack Compute, although it is generally expected of hypervisors that they will make a best effort to scrub memory either upon deletion of an instance, upon creation of an instance, or both.</para>
<para>Xen explicitly assigns dedicated memory regions to instances and scrubs data upon the destruction of instances (or domains in Xen parlance). KVM depends more greatly on Linux page management; A complex set of rules related to KVM paging is defined in the <link xlink:href="http://www.linux-kvm.org/page/Memory">KVM documentation</link>.</para>
<para>It is important to note that use of the Xen memory balloon feature is likely to result in information disclosure. We strongly recommended to avoid use of this feature.</para>
<para>For these and other hypervisors, we recommend referring to hypervisor-specific documentation.</para>
</section>
<section xml:id="ch046_data-residency-idp78448">
<title>Cinder volume data</title>
<para>Plugins to OpenStack Block Storage will store data in a variety of ways. Many plug-ins are specific to a vendor or technology, whereas others are more DIY solutions around filesystems such as LVM or ZFS. Methods to securely destroy data will vary from one plugin to another, from one vendor's solution to another, and from one filesystem to another.</para>
<para>Some backends such as ZFS will support copy-on-write to prevent data exposure. In these cases, reads from unwritten blocks will always return zero. Other backends such as LVM may not natively support this, thus the Block Storage plug-in takes the responsibility to override previously written blocks before handing them to users. It is important to review what assurances your chosen volume backend provides and to see what mediations may be available for those assurances not provided.</para>
<para>Finally, while not a feature of OpenStack, vendors and implementors may choose to add or support encryption of volumes. In this case, destruction of data is as simple as throwing away the key.</para>
</section>
<section xml:id="ch046_data-residency-idp81664">
<title>Compute instance ephemeral storage</title>
<para>The creation and destruction of ephemeral storage will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plug-in.</para>
<para>The libvirt plug-in for compute may maintain ephemeral storage directly on a filesystem, or in LVM. Filesystem storage generally will not overwrite data when it is removed, although there is a guarantee that dirty extents are not provisioned to users.</para>
<para>When using LVM backed ephemeral storage, which is block-based, it is necessary that the OpenStack Compute software securely erases blocks to prevent information disclosure. There have in the past been information disclosure vulnerabilities related to improperly erased ephemeral block storage devices.</para>
<para>Filesystem storage is a more secure solution for ephemeral block storage devices than LVM as dirty extents cannot be provisioned to users. However, it is important to be mindful that user data is not destroyed, so it is suggested to encrypt the backing filesystem.</para>
</section>
<section xml:id="ch046_data-residency-idp85040">
<title>Bare metal server sanitization</title>
<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>

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

@@ -1,44 +0,0 @@
<?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"
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>
<para>Often, data encryption relates positively to the ability to reliably destroy tenant and per-instance data, simply by throwing away the keys. It should be noted that in doing so, it becomes of great importance to destroy those keys in a reliable and secure manner.</para>
<para>Opportunities to encrypt data for users are present:</para>
<itemizedlist><listitem>
<para>Object Storage objects</para>
</listitem>
<listitem>
<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>
<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 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>
<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
interested implementors.</para>
<para>Block storage supports a variety of mechanisms for supplying mountable volumes. It is outside the scope of this guide to specify recommendations for each Block Storage backend driver. For the purpose of performance, many storage protocols are unencrypted. Some protocols such as iSCSI can provide authentication and encrypted sessions, it is our recommendation to enable these features.</para>
</section>
</chapter>

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

@@ -1,23 +0,0 @@
<?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"
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>
<section xml:id="ch048_key-management-idp47776">
<title>References:</title>
<itemizedlist><listitem>
<para><link xlink:href="https://github.com/cloudkeep/barbican">Barbican</link></para>
</listitem>
<listitem>
<para><link xlink:href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip">KMIP</link></para>
</listitem>
</itemizedlist>
</section>
</chapter>

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

@@ -1,82 +0,0 @@
<?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"
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>
<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 does not cause
loss of other tenant data. She also has strong regulator
requirements that require documentation of data destruction
activities. Alice does this using the following:
</para>
<itemizedlist>
<listitem>
<para>Establishing procedures to sanitize tenant data when
a program or project ends.</para>
</listitem>
<listitem>
<para>Track the destruction of both the tenant data and
metadata through ticketing in a CMDB.</para>
</listitem>
<listitem><para>For Volume storage:</para>
<itemizedlist>
<listitem>
<para>Physical server issues</para>
</listitem>
<listitem>
<para>To provide secure ephemeral instance storage,
Alice implements qcow2 files on an encrypted
filesystem.</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch049_case-studies-tenant-data-idp51856">
<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>
<listitem>
<para>Track the destruction of both the customer data and
metadata through ticketing in a CMDB.</para>
</listitem>
<listitem>
<para>For Volume storage:</para>
<itemizedlist>
<listitem>
<para>Physical server issues</para>
</listitem>
<listitem>
<para>To provide secure ephemeral instance storage, Bob
implements qcow2 files on an encrypted filesystems.</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
</chapter>

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

@@ -1,697 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter [
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
%openstack;
]>
<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 must
also be secured appropriately to reduce the risks associated with
hypervisor breakout attacks. That is, while a virtualization stack
can provide isolation between instances, or guest virtual
machines, that isolation can be less than perfect in some
situations. Making intelligent selections for virtualization stack
as well as following the best practices outlined in this chapter
can be included in a layered approach to cloud security. Finally,
securing your virtualization stack is critical to deliver on the
promise of multi-tenant, either between customers in a public
cloud, between business units in a private cloud, or some mixture
of the two in a hybrid cloud.</para>
<para>This chapter discusses the hypervisor selection process. The
chapters that follow provide foundational information needed for
securing a virtualization stack.</para>
<section xml:id="ch051_vss-intro-idp236592">
<title>Hypervisors in OpenStack</title>
<para>Whether OpenStack is deployed within private data centers or
as a public cloud service, the underlying virtualization
technology provides enterprise-level capabilities in the realms
of scalability, resource efficiency, and uptime. While such
high-level benefits are generally available across many
OpenStack-supported hypervisor technologies, there are
significant differences in the security architecture and
features for each hypervisor, particularly when considering the
security threat vectors which are unique to elastic OpenStack
environments. As applications consolidate into single
Infrastructure-as-a-Service (IaaS) platforms, instance isolation
at the hypervisor level becomes paramount. The requirement for
secure isolation holds true across commercial, government, and
military communities.</para>
<para>Within the OpenStack framework, you can choose among many
hypervisor platforms and corresponding OpenStack plug-ins to
optimize your cloud environment. In the context of this guide,
hypervisor selection considerations are highlighted 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>
<para>As part of your hypervisor selection process, you must
consider a number of important factors to help increase your
security posture. Specifically, you must become familiar with
these areas:</para>
<itemizedlist>
<listitem>
<para>Team expertise</para>
</listitem>
<listitem>
<para>Product or project maturity</para>
</listitem>
<listitem>
<para>Common criteria</para>
</listitem>
<listitem>
<para>Certifications and attestations</para>
</listitem>
<listitem>
<para>Hardware concerns</para>
</listitem>
<listitem>
<para>Hypervisor vs. baremetal</para>
</listitem>
<listitem>
<para>Additional security features</para>
</listitem>
</itemizedlist>
<para>Additionally, the following security-related criteria are
highly encouraged to be evaluated when selecting a hypervisor
for OpenStack deployments:</para>
<itemizedlist>
<listitem>
<para>Has the hypervisor undergone Common Criteria
certification? If so, to what levels?</para>
</listitem>
<listitem>
<para>Is the underlying cryptography certified by a
third-party?</para>
</listitem>
</itemizedlist>
<section xml:id="team_expertise">
<title>Team expertise</title>
<para>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 fewer the configuration mistakes.
Additionally, having staff expertise spread across an
organization on a given hypervisor increases availability of
your systems, allows segregation of duties, and mitigates
problems in the event that a team member is
unavailable.</para>
</section>
<section xml:id="ch051_vss-intro-idp252752">
<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
has a number of effects once you have deployed your
cloud:</para>
<itemizedlist>
<listitem>
<para>Availability of expertise</para>
</listitem>
<listitem>
<para>Active developer and user communities</para>
</listitem>
<listitem>
<para>Timeliness and availability of updates</para>
</listitem>
<listitem>
<para>Incidence response</para>
</listitem>
</itemizedlist>
<para>One of the biggest indicators of a hypervisor's maturity
is the size and vibrancy of the community that surrounds it.
As this concerns security, the quality of the community
affects the availability of expertise if you need additional
cloud operators. It is also a sign of how widely deployed the
hypervisor is, in turn leading to the battle readiness of any
reference architectures and best practices.</para>
<para>Further, the quality of community, as it surrounds an open
source hypervisor like KVM or Xen, has a direct impact on the
timeliness of bug fixes and security updates. When
investigating both commercial and open source hypervisors, you
must 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. See
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>
<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">
<title>Common criteria</title>
<para>Common Criteria is an internationally standardized
software evaluation process, used by governments and
commercial companies to validate software technologies perform
as advertised. In the government sector, NSTISSP No. 11
mandates that U.S. Government agencies only procure software
which has been Common Criteria certified, a policy which has
been in place since July 2002. It should be specifically noted
that OpenStack has not undergone Common Criteria
certification, however many of the available hypervisors
have.</para>
<para>In addition to validating a technologies capabilities, the
Common Criteria process evaluates <emphasis>how</emphasis>
technologies are developed.</para>
<itemizedlist>
<listitem>
<para>How is source code management performed?</para>
</listitem>
<listitem>
<para>How are users granted access to build systems?</para>
</listitem>
<listitem>
<para>Is the technology cryptographically signed before
distribution?</para>
</listitem>
</itemizedlist>
<para>The KVM hypervisor has been Common Criteria certified
through the U.S. Government and commercial distributions,
which have been validated to separate the runtime environment
of virtual machines from each other, providing foundational
technology to enforce instance isolation. In addition to
virtual machine isolation, KVM has been Common Criteria
certified to</para>
<blockquote>
<para>"<emphasis>provide system-inherent separation mechanisms
to the resources of virtual machines. This separation
ensures that large software component used for
virtualizing and simulating devices executing for each
virtual machine cannot interfere with each other. Using
the SELinux multi-category mechanism, the virtualization
and simulation software instances are isolated. The
virtual machine management framework configures SELinux
multi-category settings transparently to the
administrator</emphasis>"</para>
</blockquote>
<para>While many hypervisor vendors, such as Red Hat, Microsoft,
and VMWare have achieved Common Criteria Certification their
underlying certified feature set differs. It is recommended to
evaluate vendor claims to ensure they minimally satisfy the
following requirements:</para>
<informaltable rules="all" width="80%">
<colgroup>
<col/>
<col/>
</colgroup>
<tbody>
<tr>
<td><para>Identification and Authentication</para></td>
<td><para>Identification and authentication using
pluggable authentication modules (PAM) based upon user
passwords. The quality of the passwords used can be
enforced through configuration options.</para></td>
</tr>
<tr>
<td><para>Audit</para></td>
<td><para>The system provides the capability to audit a
large number of events including individual system
calls as well as events generated by trusted
processes. Audit data is collected in regular files in
ASCII format. The system provides a program for the
purpose of searching the audit
records.</para><para>The system administrator can
define a rule base to restrict auditing to the events
they are interested in. This includes the ability to
restrict auditing to specific events, specific users,
specific objects or a combination of all of
this.</para><para>Audit records can be transferred to
a remote audit daemon.</para></td>
</tr>
<tr>
<td><para>Discretionary Access Control</para></td>
<td>
<para>Discretionary Access Control
(<glossterm>DAC</glossterm>) restricts access to
file system objects based on <glossterm
baseform="access control list">Access Control
Lists</glossterm> (ACLs) that include the standard
UNIX permissions for user, group and others. Access
control mechanisms also protect IPC objects from
unauthorized access.</para>
<para>The system includes the ext4 file system, which
supports POSIX ACLs. This allows defining access
rights to files within this type of file system down
to the granularity of a single user.</para>
</td>
</tr>
<tr>
<td><para>Mandatory Access Control</para></td>
<td><para>Mandatory Access Control (MAC) restricts access
to objects based on labels assigned to subjects and
objects. Sensitivity labels are automatically attached
to processes and objects. The access control policy
enforced using these labels is derived from the
BellLaPadula access control model.</para><para>SELinux
categories are attached to virtual machines and its
resources. The access control policy enforced using
these categories grant virtual machines access to
resources if the category of the virtual machine is
identical to the category of the accessed
resource.</para><para>The TOE implements
non-hierarchical categories to control access to
virtual machines.</para></td>
</tr>
<tr>
<td><para>Role-Based Access Control</para></td>
<td><para>Role-based access control (RBAC) allows
separation of roles to eliminate the need for an
all-powerful system administrator.</para></td>
</tr>
<tr>
<td><para>Object Reuse</para></td>
<td><para>File system objects and memory and IPC objects
are cleared before they can be reused by a process
belonging to a different user.</para></td>
</tr>
<tr>
<td><para>Security Management</para></td>
<td><para>The management of the security critical
parameters of the system is performed by
administrative users. A set of commands that require
root privileges (or specific roles when RBAC is used)
are used for system management. Security parameters
are stored in specific files that are protected by the
access control mechanisms of the system against
unauthorized access by users that are not
administrative users.</para></td>
</tr>
<tr>
<td><para>Secure Communication</para></td>
<td><para>The system supports the definition of trusted
channels using SSH. Password based authentication is
supported. Only a restricted number of cipher suites
are supported for those protocols in the evaluated
configuration.</para></td>
</tr>
<tr>
<td><para>Storage Encryption</para></td>
<td><para>The system supports encrypted block devices to
provide storage confidentiality via
dm_crypt.</para></td>
</tr>
<tr>
<td><para>TSF Protection</para></td>
<td><para>While in operation, the kernel software and data
are protected by the hardware memory protection
mechanisms. The memory and process management
components of the kernel ensure a user process cannot
access kernel storage or storage belonging to other
processes.</para><para>Non-kernel TSF software and
data are protected by DAC and process isolation
mechanisms. In the evaluated configuration, the
reserved user ID root owns the directories and files
that define the TSF configuration. In general, files
and directories containing internal TSF data, such as
configuration files and batch job queues, are also
protected from reading by DAC
permissions.</para><para>The system and the hardware
and firmware components are required to be physically
protected from unauthorized access. The system kernel
mediates all access to the hardware mechanisms
themselves, other than program visible CPU instruction
functions.</para><para>In addition, mechanisms for
protection against stack overflow attacks are
provided.</para></td>
</tr>
</tbody>
</informaltable>
</section>
<section xml:id="ch051_vss-intro-idp324896">
<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>
<thead>
<tr>
<th>Algorithm</th>
<th>Key length</th>
<th>Intended purpose</th>
<th>Security function</th>
<th>Implementation standard</th>
</tr>
</thead>
<tbody>
<tr>
<td>AES</td>
<td>128, 192, or 256 bits</td>
<td>Encryption / decryption</td>
<td>Protected data transfer, protection for data at
rest</td>
<td>RFC 4253</td>
</tr>
<tr>
<td>TDES</td>
<td>168 bits</td>
<td>Encryption / decryption</td>
<td>Protected data transfer</td>
<td>RFC 4253</td>
</tr>
<tr>
<td>RSA</td>
<td>1024, 2048, or 3072 bits</td>
<td>Authentication, key exchange</td>
<td>Identification and authentication, protected
data transfer</td>
<td>U.S. NIST FIPS PUB 186-3</td>
</tr>
<tr>
<td>DSA</td>
<td>L=1024, N=160 bits</td>
<td>Authentication, key exchange</td>
<td>Identification and authentication, protected
data transfer</td>
<td>U.S. NIST FIPS PUB 186-3</td>
</tr>
<tr>
<td>Serpent</td>
<td>128, 192, or 256 bits</td>
<td>Encryption / decryption</td>
<td>Protection of data at rest</td>
<td><link
xlink:href="http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf"
>http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf</link></td>
</tr>
<tr>
<td>Twofish</td>
<td>128, 192, or 256 bit</td>
<td>Encryption / decryption</td>
<td>Protection of data at rest</td>
<td><link
xlink:href="http://www.schneier.com/paper-twofish-paper.html"
>http://www.schneier.com/paper-twofish-paper.html</link></td>
</tr>
<tr>
<td>SHA-1</td>
<td>-</td>
<td>Message Digest</td>
<td>Protection of data at rest, protected data
transfer</td>
<td>U.S. NIST FIPS 180-3</td>
</tr>
<tr>
<td>SHA-2 (224, 256, 384, or 512 bits)</td>
<td>-</td>
<td>Message Digest</td>
<td>Protection for data at rest, identification and
authentication</td>
<td>U.S. NIST FIPS 180-3</td>
</tr>
</tbody>
</informaltable>
<section xml:id="ch051_vss-intro-idp362768">
<title>FIPS 140-2</title>
<para>In the United States the National Institute of Science
and Technology (NIST) certifies cryptographic algorithms
through a process known the Cryptographic Module Validation
Program. NIST certifies algorithms for conformance against
Federal Information Processing Standard 140-2 (FIPS 140-2),
which ensures:</para>
<blockquote>
<para><emphasis>Products validated as conforming to FIPS
140-2 are accepted by the Federal agencies of both
countries [United States and Canada] for the protection
of sensitive information (United States) or Designated
Information (Canada). The goal of the CMVP is to promote
the use of validated cryptographic modules and provide
Federal agencies with a security metric to use in
procuring equipment containing validated cryptographic
modules.</emphasis></para>
</blockquote>
<para>When evaluating base hypervisor technologies, consider
if the hypervisor has been certified against FIPS 140-2. Not
only is conformance against FIPS 140-2 mandated per U.S.
Government policy, formal certification indicates that a
given implementation of a cryptographic algorithm has been
reviewed for conformance against module specification,
cryptographic module ports and interfaces; roles, services,
and authentication; finite state model; physical security;
operational environment; cryptographic key management;
electromagnetic interference/electromagnetic compatibility
(EMI/EMC); self-tests; design assurance; and mitigation of
other attacks.</para>
</section>
</section>
<section xml:id="ch051_vss-intro-idp367552">
<title>Hardware concerns</title>
<para>Further, when you evaluate a hypervisor platform, consider
the supportability of the hardware on which the hypervisor
will run. 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 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>
<thead>
<tr>
<td>Description</td>
<td>Technology</td>
<td>Explanation</td>
</tr>
</thead>
<tbody>
<tr>
<td>I/O MMU</td>
<td>VT-d / AMD-Vi</td>
<td>Required for protecting
PCI-passthrough</td>
</tr>
<tr>
<td>Intel Trusted Execution Technology</td>
<td>Intel TXT / SEM</td>
<td>Required for dynamic attestation
services</td>
</tr>
<tr>
<td><anchor
xml:id="PCI-SIG_I.2FO_virtualization_.28IOV.29"
/>PCI-SIG I/O virtualization</td>
<td>SR-IOV, MR-IOV, ATS</td>
<td>Required to allow secure sharing of PCI Express
devices</td>
</tr>
<tr>
<td>Network virtualization</td>
<td>VT-c</td>
<td>Improves performance of network I/O on
hypervisors</td>
</tr>
</tbody>
</informaltable>
</section>
<section xml:id="ch051_vss-intro-idp396976">
<title>Hypervisor vs. baremetal</title>
<para>It is important to recognise the difference between using
LXC (Linux Containers) or Baremetal systems vs using a
hypervisor like KVM. Specifically, the focus of this security
guide is largely based on having a hypervisor and
virtualization platform. However, should your implementation
require the use of a baremetal or LXC environment, you must
pay attention to the particular differences in regard to
deployment of that environment.</para>
<para>In particular, you must assure your end users that the
node has been properly sanitized of their data prior to
re-provisioning. Additionally, prior to reusing a node, you
must provide assurances that the hardware has not been
tampered or otherwise compromised.</para>
<note>
<para>While OpenStack has a baremetal project, a discussion of
the particular security implications of running baremetal is
beyond the scope of this book.</para>
</note>
<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 Compute</link>.</para>
</note>
</section>
<section xml:id="ch051_vss-intro-idpKMSTPS">
<title>Hypervisor memory optimization</title>
<para>Many hypervisors use memory optimization techniques to
overcommit memory to guest virtual machines. This is a useful
feature that allows you to deploy very dense compute clusters.
One way to achieve this is through de-duplication or “sharing”
of memory pages. When two virtual machines have identical data
in memory, there are advantages to having them reference the
same memory.</para>
<para>Typically this is achieved through Copy-On-Write (COW)
mechanisms. These mechanisms have been shown to be vulnerable
to side-channel attacks where one VM can infer something about
the state of another and might not be appropriate for
multi-tenant environments where not all tenants are trusted or
share the same levels of trust.</para>
</section>
<section xml:id="ch051_vss-intro-idpKMS">
<title>KVM Kernel Samepage Merging</title>
<para>Introduced into the Linux kernel in version 2.6.32, Kernel
Samepage Merging (KSM) consolidates identical memory pages
between Linux processes. As each guest VM under the KVM
hypervisor runs in its own process, KSM can be used to
optimize memory use between VMs.</para>
</section>
<section xml:id="ch051_vss-intro-idpTPS">
<title>XEN transparent page sharing</title>
<para>XenServer 5.6 includes a memory overcommitment feature
named Transparent Page Sharing (TPS). TPS scans memory in 4 KB
chunks for any duplicates. When found, the Xen Virtual Machine
Monitor (VMM) discards one of the duplicates and records the
reference of the second one.</para>
</section>
<section xml:id="ch051_vss-intro-idpKMSTPSCons">
<title>Security considerations for memory optimization</title>
<para>Traditionally, memory de-duplication systems are
vulnerable to side channel attacks. Both KSM and TPS have
demonstrated to be vulnerable to some form of attack. In
academic studies<footnote>
<para>Fine grain Cross-VM Attacks on Xen and VMware are
possible - Apecechea and others. <link
xlink:href="https://eprint.iacr.org/2014/248.pdf"
>https://eprint.iacr.org/2014/248.pdf</link></para>
</footnote><footnote>
<para>Memory Deduplication as a Threat to the Guest OS -
Suzaki and others. <link
xlink:href="https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf"
>https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf</link></para>
</footnote>attackers were able to identify software packages
and versions running on neighboring virtual machines as well
as software downloads and other sensitive information through
analyzing memory access times on the attacker VM.</para>
<para>If a cloud deployment requires strong separation of
tenants, as is the situation with public clouds and some
private clouds, deployers should consider disabling TPS and
KSM memory optimizations.</para>
</section>
<section xml:id="ch051_vss-intro-idp401408">
<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 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>
<informaltable rules="all" width="80%">
<colgroup>
<col/>
<col/>
<col/>
<col/>
<col/>
<col/>
<col/>
</colgroup>
<tbody>
<tr>
<td><para/></td>
<td><para>XSM</para></td>
<td><para>sVirt</para></td>
<td><para>TXT</para></td>
<td><para>AppArmor</para></td>
<td><para>cgroups</para></td>
<td><para>MAC Policy</para></td>
</tr>
<tr>
<td><para>KVM</para></td>
<td><para/></td>
<td><para>&CHECK;</para></td>
<td><para>&CHECK;</para></td>
<td><para>&CHECK;</para></td>
<td><para>&CHECK;</para></td>
<td><para>&CHECK;</para></td>
</tr>
<tr>
<td><para>Xen</para></td>
<td><para>&CHECK;</para></td>
<td><para/></td>
<td><para>&CHECK;</para></td>
<td><para/></td>
<td><para/></td>
<td><para>&CHECK;</para></td>
</tr>
<tr>
<td><para>ESXi</para></td>
<td><para/></td>
<td><para/></td>
<td><para>&CHECK;</para></td>
<td><para/></td>
<td><para/></td>
<td><para/></td>
</tr>
<tr>
<td><para>Hyper-V</para></td>
<td><para/></td>
<td><para/></td>
<td><para/></td>
<td><para/></td>
<td><para/></td>
<td><para/></td>
</tr>
</tbody>
</informaltable>
<para><link xlink:href="http://www.linux-kvm.org/page/KSM">KVM:
Kernel Samepage Merging</link></para>
<para><link
xlink:href="http://wiki.xen.org/wiki/Xen_Security_Modules_:_XSM-FLASK"
>XSM: Xen Security Modules</link></para>
<para><link xlink:href="http://selinuxproject.org/page/SVirt"
>xVirt: Mandatory Access Control for Linux-based
virtualization</link></para>
<para><link xlink:href="http://www.intel.com/txt">TXT: Intel
Trusted Execution Technology</link></para>
<para><link
xlink:href="http://wiki.apparmor.net/index.php/Main_Page"
>AppArmor: Linux security module implementing
MAC</link></para>
<para><link
xlink:href="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt"
>cgroups: Linux kernel feature to control resource
usage</link></para>
<para>MAC Policy: Mandatory Access Control; may be implemented
with SELinux or other operating systems</para>
<para>* Features in this table might not be applicable to all
hypervisors or directly mappable between hypervisors.</para>
</section>
</section>
</chapter>

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

@@ -1,403 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE chapter [
<!ENTITY % openstack SYSTEM "../common/entities/openstack.ent">
%openstack;
]>
<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>
<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>
<para>KVM: <link
xlink:href="http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM">How
to assign devices with VT-d in KVM</link></para>
</listitem>
<listitem>
<para>Xen: <link xlink:href="http://wiki.xen.org/wiki/VTd_HowTo">VTd Howto</link>
</para>
</listitem>
</itemizedlist>
<note>
<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
<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>
<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 network,
storage, video, and other devices that may be needed. With
this in mind, most instances in your environment will
exclusively use virtual hardware, with a minority that will
require direct hardware access. The major open source
hypervisors use QEMU for this functionality. While QEMU fills
an important need for virtualization platforms, it has proven
to be a very challenging software project to write and
maintain. Much of the functionality in QEMU is implemented
with low-level code that is difficult for most developers to
comprehend. Furthermore, the hardware virtualized by QEMU
includes many legacy devices that have their own set of
quirks. Putting all of this together, QEMU has been the source
of many security problems, including hypervisor breakout
attacks.</para>
<para>
For the reasons stated above, it is important to take
proactive steps to harden QEMU. We recommend three specific
steps: minimizing the code base, using compiler hardening, and
using mandatory access controls, such as sVirt, SELinux, or
AppArmor.</para>
<section xml:id="ch052_devices-idp490976">
<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 \
--property hw_cdrom_bus=ide \
--property hw_vif_model=e1000 \
f16-x86_64-openstack-sda</userinput></screen>
<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
<command>./configure --help</command> 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>
<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>
<variablelist>
<varlistentry>
<term>RELocation Read-Only (RELRO)</term>
<listitem>
<para>
Hardens the data sections of an executable. Both full
and partial RELRO modes are supported by gcc. For QEMU
full RELRO is your best choice. This will make the
global offset table read-only and place various
internal data sections before the program data section
in the resulting executable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Stack canaries</term>
<listitem>
<para>
Places values on the stack and verifies their presence
to help prevent buffer overflow attacks.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Never eXecute (NX)</term>
<listitem>
<para>
Also known as Data Execution Prevention (DEP), ensures
that data sections of the executable can not be
executed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Position Independent Executable (PIE)</term>
<listitem>
<para>
Produces a position independent executable, which is
necessary for ASLR.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Address Space Layout Randomization (ASLR)</term>
<listitem>
<para>
This ensures that placement of both code and data
regions will be randomized. Enabled by the kernel (all
modern linux kernels support ASLR), when the executable
is built with PIE.</para>
</listitem>
</varlistentry>
</variablelist>
<para>
Putting this all together, and adding in some additional
useful protections, we recommend the following compiler
options for GCC when compiling QEMU:</para>
<programlisting>CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector \
--param ssp-buffer-size=4 -pie -fPIE -ftrapv -D_FORTIFY_SOURCE=2 -O2 \
-Wl,-z,relro,-z,now"</programlisting>
<para>
We recommend testing your QEMU executable file after it is
compiled to ensure that the compiler hardening worked
properly.</para>
<para>
Most cloud deployments will not want to build software such
as QEMU by hand. It is better to use packaging to ensure
that the process is repeatable and to ensure that the end
result can be easily deployed throughout the cloud. The
references below provide some additional details on applying
compiler hardening options to existing packages.</para>
<itemizedlist>
<listitem>
<para>DEB packages: <link xlink:href="http://wiki.debian.org/HardeningWalkthrough">Hardening Walkthrough</link></para>
</listitem>
<listitem>
<para>RPM packages: <link xlink:href="http://fedoraproject.org/wiki/How_to_create_an_RPM_package">How to create an RPM package</link></para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch052_devices-idp508032">
<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 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. With
developmental origins dating back to 2002, the Secure
Virtualization (sVirt) technology is the application of
SELinux against modern day virtualization. SELinux, which was
designed to apply separation control based upon labels, has
been extended to provide isolation between virtual machine
processes, devices, data files and system processes acting
upon their behalf.</para>
<para>
OpenStack's sVirt implementation aspires to protect hypervisor
hosts and virtual machines against two primary threat
vectors:</para>
<itemizedlist><listitem>
<para><emphasis role="bold">Hypervisor threats</emphasis> A
compromised application running within a virtual machine
attacks the hypervisor to access underlying resources. For
example, the host OS, applications, or devices within the
physical machine. This is a threat vector unique to
virtualization and represents considerable risk as the
underlying real machine can be compromised due to
vulnerability in a single virtual application.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Virtual Machine (multi-tenant)
threats</emphasis> A compromised application running
within a VM attacks the hypervisor to access/control
another virtual machine and its resources. This is a
threat vector unique to virtualization and represents
considerable risk as a multitude of virtual machine file
images could be compromised due to vulnerability in a
single application. This virtual network attack is a
major concern as the administrative techniques for
protecting real networks do not directly apply to the
virtual environment.</para>
</listitem>
</itemizedlist>
<para>
Each KVM-based virtual machine is a process which is labeled
by SELinux, effectively establishing a security boundary
around each virtual machine. This security boundary is
monitored and enforced by the Linux kernel, restricting the
virtual machine's access to resources outside of its boundary
such as host machine data files or other VMs.</para>
<para>
<inlinemediaobject>
<imageobject role="html">
<imagedata contentdepth="583" contentwidth="1135"
fileref="static/sVirt Diagram 1.png" format="PNG"
scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/sVirt Diagram 1.png"
format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject>
</para>
<para>
As shown above, sVirt isolation is provided regardless of the
guest Operating System running inside the virtual
machine&mdash;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>
<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
system_u:object_r:svirt_image_t:SystemLow image3
system_u:object_r:svirt_image_t:SystemLow image4</programlisting>
<para>
The <literal>svirt_image_t</literal> label uniquely
identifies image files on disk, allowing for the SELinux
policy to restrict access. When a KVM-based Compute image is
powered on, sVirt appends a random numerical identifier to
the image. sVirt is technically capable of assigning
numerical identifiers to 524,288 virtual machines per
hypervisor node, however OpenStack deployments are highly
unlikely to encounter this limitation.</para>
<para>This example shows the sVirt category identifier:</para>
<programlisting>system_u:object_r:svirt_image_t:s0:c87,c520 image1
system_u:object_r:svirt_image_t:s0:419,c172 image2</programlisting>
</section>
<section xml:id="ch052_devices-idp527632">
<title>Booleans</title>
<para>
To ease the administrative burden of managing SELinux, many
enterprise Linux platforms utilize SELinux Booleans to
quickly change the security posture of sVirt.</para>
<para>
Red Hat Enterprise Linux-based KVM deployments utilize the
following sVirt booleans:</para>
<informaltable rules="all" width="80%"><colgroup><col/><col/></colgroup>
<thead>
<tr>
<td><para><emphasis role="bold">sVirt SELinux Boolean</emphasis></para></td>
<td><para><emphasis role="bold">Description</emphasis></para></td>
</tr>
</thead>
<tbody>
<tr>
<td><para>virt_use_common</para></td>
<td><para>Allow virt to use serial/parallel communication ports.</para></td>
</tr>
<tr>
<td><para>virt_use_fusefs</para></td>
<td><para>Allow virt to read FUSE mounted files.</para></td>
</tr>
<tr>
<td><para>virt_use_nfs</para></td>
<td><para>Allow virt to manage NFS mounted files.</para></td>
</tr>
<tr>
<td><para>virt_use_samba</para></td>
<td><para>Allow virt to manage CIFS mounted files.</para></td>
</tr>
<tr>
<td><para>virt_use_sanlock</para></td>
<td><para>Allow confined virtual guests to interact with the sanlock.</para></td>
</tr>
<tr>
<td><para>virt_use_sysfs</para></td>
<td><para>Allow virt to manage device configuration (PCI).</para></td>
</tr>
<tr>
<td><para>virt_use_usb</para></td>
<td><para>Allow virt to use USB devices.</para></td>
</tr>
<tr>
<td><para>virt_use_xserver</para></td>
<td><para>Allow virtual machine to interact with the X Window System.</para></td>
</tr>
</tbody>
</informaltable>
</section>
</section>
</chapter>

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

@@ -1,21 +0,0 @@
<?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"
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>
<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>
<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>
</chapter>

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

@@ -1,227 +0,0 @@
<?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"
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>
<itemizedlist><listitem>
<para>Entropy to instances</para>
</listitem>
<listitem>
<para>Scheduling instances to nodes</para>
</listitem>
<listitem>
<para>Trusted images</para>
</listitem>
<listitem>
<para>Instance migrations</para>
</listitem>
</itemizedlist>
<section xml:id="ch055_security-services-for-instances-idp122544">
<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>
<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
xlink:href="http://docs.openstack.org/trunk/config-reference/content/section_compute-scheduler.html"
>Scheduling</link> in the <citetitle>OpenStack Configuration
Reference</citetitle>). The filter scheduler works in collaboration with
'filters' to decide where an instance should be started. This process of
host selection allows administrators to fulfill many different security
requirements. Depending on the cloud deployment type for example, one
could choose to have tenant instances reside on the same hosts whenever
possible if data isolation was a primary concern, conversely one could
attempt to have instances for a tenant reside on as many different hosts
as possible for availability or fault tolerance reasons. The following
diagram demonstrates how the filter scheduler works:</para>
<para><inlinemediaobject><imageobject role="html">
<imagedata contentdepth="400" contentwidth="550" fileref="static/filteringWorkflow1.png" format="PNG" scalefit="1"/>
</imageobject>
<imageobject role="fo">
<imagedata contentdepth="100%" fileref="static/filteringWorkflow1.png" format="PNG" scalefit="1" width="100%"/>
</imageobject>
</inlinemediaobject></para>
<para>The use of scheduler filters may be used to segregate customers, data, or even discard machines of the cloud that cannot be attested as secure. This generally applies to all OpenStack projects offering a scheduler. When building a cloud, you may choose to implement scheduling filters for a variety of security-related purposes.</para>
<para>Below we highlight a few of the filters that may be useful in a security context, depending on your requirements, the full set of filter documentation is documented in the <link xlink:href="http://docs.openstack.org/trunk/config-reference/content/filter-scheduler.html">Filter Scheduler</link> section of the <citetitle>OpenStack Configuration Reference</citetitle>.</para>
<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>
<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
partition up their compute host resources. Each node can have
multiple aggregates (see the <link
xlink:href="http://docs.openstack.org/trunk/config-reference/content/host-aggregates.html">Host
aggregates</link> section of the <citetitle>OpenStack
Configuration Reference</citetitle> for more information on
creating and managing aggregates).</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp142048">
<title>AggregateMultiTenancyIsolation</title>
<para>Isolates tenants to specific host aggregates. If a host is in an aggregate that has the metadata key <literal>filter_tenant_id</literal> it will only create instances from that tenant (or list of tenants). A host can be in multiple aggregates. If a host does not belong to an aggregate with the metadata key, it can create instances from all tenants.</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp143968">
<title>DifferentHostFilter</title>
<para>Schedule the instance on a different host from a set of instances. To take advantage of this filter, the requester must pass a scheduler hint, using <literal>different_host</literal> as the key and a list of instance uuids as the value. This filter is the opposite of the <literal>SameHostFilter</literal>.</para>
</section>
<section xml:id="ch055_security-services-for-instances-idp146208">
<title>GroupAntiAffinityFilter</title>
<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>
<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>
<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 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>
<prompt>$</prompt> <userinput>wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS</userinput>
<prompt>$</prompt> <userinput>wget http://mirror.anl.gov/pub/ubuntu-iso/CDs/precise/SHA256SUMS.gpg</userinput>
<prompt>$</prompt> <userinput>gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451</userinput>
<prompt>$</prompt> <userinput>gpg --verify SHA256SUMS.gpg SHA256SUMSsha256sum -c SHA256SUMS 2&gt;&amp;1 | grep OK</userinput></screen>
<para>The second option is to use the <link xlink:href="http://docs.openstack.org/trunk/image-guide/content/"><citetitle>OpenStack Virtual Machine Image Guide</citetitle></link>. In this case, you will want to follow your organizations OS hardening guidelines or those provided by a trusted third-party such as the <link xlink:href="http://iase.disa.mil/stigs/os/unix/red_hat.html">RHEL6 STIG</link>.</para>
<para>The final option is to use an automated image builder. The following example uses the Oz image builder. The OpenStack community has recently created a newer tool worth investigating: disk-image-builder. We have not evaluated this tool from a security perspective.</para>
<para>Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section<emphasis>AC-19(d) in</emphasis> Oz.</para>
<programlisting>&lt;template&gt;
&lt;name&gt;centos64&lt;/name&gt;
&lt;os&gt;
&lt;name&gt;RHEL-6&lt;/name&gt;
&lt;version&gt;4&lt;/version&gt;
&lt;arch&gt;x86_64&lt;/arch&gt;
&lt;install type='iso'&gt;
&lt;iso&gt;http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso&lt;/iso&gt;
&lt;/install&gt;
&lt;rootpw&gt;CHANGE THIS TO YOUR ROOT PASSWORD&lt;/rootpw&gt;
&lt;/os&gt;
&lt;description&gt;RHEL 6.4 x86_64&lt;/description&gt;
&lt;repositories&gt;
&lt;repository name='epel-6'&gt;
&lt;url&gt;http://download.fedoraproject.org/pub/epel/6/$basearch&lt;/url&gt;
&lt;signed&gt;no&lt;/signed&gt;
&lt;/repository&gt;
&lt;/repositories&gt;
&lt;packages&gt;
&lt;package name='epel-release'/&gt;
&lt;package name='cloud-utils'/&gt;
&lt;package name='cloud-init'/&gt;
&lt;/packages&gt;
&lt;commands&gt;
&lt;command name='update'&gt;
yum update
yum clean all
sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0
echo -n &gt; /etc/udev/rules.d/70-persistent-net.rules
echo -n &gt; /lib/udev/rules.d/75-persistent-net-generator.rules
chkconfig --level 0123456 autofs off
service autofs stop
&lt;/command&gt;
&lt;/commands&gt;
&lt;/template&gt;</programlisting>
<para>Note, it is the recommendation of this guide to shy away from the manual image building process as it is complex and prone to error. Further, using an automated system like Oz or disk-image-builder for image building, or a configuration management utility like Chef or Puppet for post boot image hardening gives you the ability to produce a consistent image as well as track compliance of your base image to its respective hardening guidelines over time.</para>
<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>
<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>
<para>
OpenStack and the underlying virtualization layers provide for
the live migration of images between OpenStack nodes allowing
you to seamlessly perform rolling upgrades of your OpenStack
compute nodes without instance downtime. However, live
migrations also come with their fair share of risk. To
understand the risks involved, it is important to first
understand how a live migration works. The following are the
high level steps preformed during a live migration.
</para>
<orderedlist>
<listitem><para>Start instance on destination host</para> </listitem>
<listitem><para>Transfer memory</para> </listitem>
<listitem><para>Stop the guest &amp; sync disks</para> </listitem>
<listitem><para>Transfer state</para> </listitem>
<listitem><para>Start the guest</para> </listitem>
</orderedlist>
<section xml:id="ch055_security-services-for-instances-idp177552">
<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>
</listitem>
<listitem>
<para><emphasis>Data exposure</emphasis>: Memory or disk transfers must be handled securely.</para>
</listitem>
<listitem>
<para><emphasis>Data manipulation</emphasis>: If memory or disk transfers are not handled securely, then an attacker could manipulate user data during the migration.</para>
</listitem>
<listitem>
<para><emphasis>Code injection</emphasis>: If memory or disk transfers are not handled securely, then an attacker could manipulate executables, either on disk or in memory, during the migration.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="ch055_security-services-for-instances-idp183744">
<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>
</listitem>
<listitem>
<para>Isolated migration network</para>
</listitem>
<listitem>
<para>Encrypted live migration</para>
</listitem>
</itemizedlist>
<section xml:id="ch055_security-services-for-instances-idp187568">
<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 <filename>policy.json</filename>
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>
<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>
<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>
</section>
</chapter>

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

@@ -1,30 +0,0 @@
<?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"
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>
<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>
<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 <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>

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

@@ -1,54 +0,0 @@
<?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"
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>
<para>Logs are not only valuable for proactive security and continuous compliance activities, but they are also a valuable information source for investigating and responding to incidents.</para>
<para>For instance, analyzing the access logs of 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>
<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>
<itemizedlist><listitem>
<para>Detecting the absence of log generation is an event of high value. Such an event would indicate a service failure or even an intruder who has temporarily switched off logging or modified the log level to hide their tracks.</para>
</listitem>
</itemizedlist>
<itemizedlist><listitem>
<para>Application events such as start and/or stop that were unscheduled would also be events to monitor and examine for possible security implications.</para>
</listitem>
</itemizedlist>
<itemizedlist><listitem>
<para>OS events on the OpenStack service machines such as user logins, restarts also provide valuable insight into use/misuse</para>
</listitem>
</itemizedlist>
<itemizedlist><listitem>
<para>Being able to detect the load on the OpenStack servers also enables responding by way of introducing additional servers for load balancing to ensure high availability.</para>
</listitem>
</itemizedlist>
<itemizedlist><listitem>
<para>Other events that are actionable are networking bridges going down, ip tables being flushed on compute nodes and consequential loss of access to instances resulting in unhappy customers.</para>
</listitem>
</itemizedlist>
<itemizedlist><listitem>
<para>To reduce security risks from orphan instances on a user/tenant/domain deletion in the Identity service there is discussion to generate notifications in the system and have OpenStack components respond to these events as appropriate such as terminating instances, disconnecting attached volumes, reclaiming CPU and storage resources etc.</para>
</listitem>
</itemizedlist>
<para>A cloud will host many virtual instances, and monitoring these instances goes beyond hardware monitoring and log files which may just contain CRUD events.</para>
<para>Security monitoring controls such as intrusion detection software, antivirus software, and spyware detection and removal utilities can generate logs that show when and how an attack or intrusion took place. Deploying these tools on the cloud machines provides value and protection. Cloud users, those running instances on the cloud may also want to run such tools on their instances.</para>
</section>
<section xml:id="ch058_forensicsincident-response-idp60512">
<title>References</title>
<para><link xlink:href="http://www.mirantis.com/blog/openstack-monitoring/">http://www.mirantis.com/blog/openstack-monitoring/</link></para>
<para><link xlink:href="http://blog.sflow.com/2012/01/host-sflow-distributed-agent.html">http://blog.sflow.com/2012/01/host-sflow-distributed-agent.html</link></para>
<para><link xlink:href="http://blog.sflow.com/2009/09/lan-and-wan.html">http://blog.sflow.com/2009/09/lan-and-wan.html</link></para>
<para><link xlink:href="http://blog.sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html">http://blog.sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html</link></para>
</section>
</chapter>

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

@@ -1,18 +0,0 @@
<?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"
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>
<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>
<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>

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

@@ -1,102 +0,0 @@
<?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"
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>
</listitem>
<listitem>
<para>Discuss common control frameworks and certification resources to achieve industry certifications or regulator attestations.</para>
</listitem>
<listitem>
<para>Act as a reference for auditors when evaluating OpenStack deployments.</para>
</listitem>
<listitem>
<para>Introduce privacy considerations specific to OpenStack and cloud environments.</para>
</listitem>
</itemizedlist>
<section xml:id="ch061_compliance-overview-idp48672">
<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>
<variablelist>
<varlistentry><term>Layered defenses</term>
<listitem>
<para>
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>
</listitem>
</varlistentry>
<varlistentry><term>Fail securely</term>
<listitem>
<para>
In the case of failure, systems should be configured to
fail into a closed secure state. For example, SSL
certificate verification should fail closed by severing
the network connection if the CNAME doesn't match the
server's DNS name. Software often fails open in this
situation, allowing the connection to proceed without a
CNAME match, which is less secure and not
recommended.</para>
</listitem>
</varlistentry>
<varlistentry><term>Least privilege</term>
<listitem>
<para>
Only the minimum level of access for users and system
services is granted. This access is based upon role,
responsibility and job function. This security principal
of least privilege is written into several international
government security policies, such as NIST 800-53
Section AC-6 within the United States.</para>
</listitem>
</varlistentry>
<varlistentry><term>Compartmentalize</term>
<listitem>
<para>
Systems should be segregated in a such way that if one
machine, or system-level service, is compromised the
security of the other systems will remain
intact. Practically, the enablement and proper usage of
SELinux helps accomplish this goal.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Promote privacy</term>
<listitem>
<para>
The amount of information that can be gathered about a
system and its users should be minimized.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Logging capability</term>
<listitem>
<para>
Appropriate logging is implemented to monitor for
unauthorized use, incident response and forensics. It is
highly recommended that selected audit subsystems be
Common Criteria certified, which provides non-attestable
event records in most countries.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</chapter>

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

@@ -1,73 +0,0 @@
<?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"
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>
</orderedlist>
<section xml:id="ch062_audit-guidance-idp48608">
<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>
<para>When addressing compliance, you can increase efficiency and reduce work effort by identifying common areas and criteria that apply across multiple certifications. Much of the audit principles and guidelines discussed in this book will assist in identifying these controls, additionally a number of external entities provide comprehensive lists. The following are some examples:</para>
<para>The <link xlink:href="https://cloudsecurityalliance.org/research/ccm/">Cloud Security Alliance Cloud Controls Matrix</link> (CCM) assists both cloud providers and consumers in assessing the overall security of a cloud provider. The CSA CMM provides a controls framework that map to many industry-accepted standards and regulations including the ISO 27001/2, ISACA, COBIT, PCI, NIST, Jericho Forum and NERC CIP.</para>
<para>The <link xlink:href="https://fedorahosted.org/scap-security-guide/">SCAP Security Guide</link> is another useful reference. This is still an emerging source, but we anticipate that this will grow into a tool with controls mappings that are more focused on the US federal government certifications and recommendations. For example, the SCAP Security Guide currently has some mappings for security technical implementation guides (STIGs) and NIST-800-53.</para>
<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>
<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>
<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>
</listitem>
<listitem>
<para>Deploy automated testing tools to ensure that the cloud remains compliant over time.</para>
</listitem>
<listitem>
<para>Select an auditor.</para>
</listitem>
</itemizedlist>
<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>
<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>
<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>

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

@@ -1,59 +0,0 @@
<?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"
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>
<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>
<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 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>
<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>
<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>
<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
advantageous from a security perspective, however the need for
security reviews is still a critical consideration for service
providers, as deployments vary, and security is not always the
primary concern for contributors. A comprehensive security
review process may include architectural review, threat
modelling, source code analysis and penetration testing. There
are many techniques and recommendations for conducting security
reviews that can be found publicly posted. A well-tested example
is the <link xlink:href="http://www.microsoft.com/security/sdl/process/release.aspx">Microsoft SDL</link>,
created as part of the Microsoft
Trustworthy Computing Initiative.</para>
</section>
<section xml:id="ch063_compliance-activities-idp54592">
<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>
<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>
<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>

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

@@ -1,285 +0,0 @@
<?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"
version="5.0"
xml:id="ch064_certifications-compliance-statements">
<?dbhtml stop-chunking?>
<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
below provides an OpenStack architect foundational knowledge and
guidance to achieve compliance against commercial and government
certifications and standards.</para>
<section
xml:id="ch064_certifications-compliance-statements-idp44896">
<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
required security activities mandated by these certifications
facilitate a foundation of security best practices and common
control criteria that can assist in achieving more stringent
compliance activities, including government attestations and
certifications.</para>
<para>After completing these initial certifications, the remaining
certifications are more deployment specific. For example, clouds
processing credit card transactions will need PCI-DSS, clouds
storing health care information require HIPAA, and clouds within
the federal government may require FedRAMP/FISMA, and ITAR,
certifications.</para>
<section
xml:id="ch064_certifications-compliance-statements-idp47472">
<title>SOC 1 (SSAE 16) / ISAE 3402</title>
<para>Service Organization Controls (SOC) criteria are defined
by the <link xlink:href="http://www.aicpa.org/">American
Institute of Certified Public Accountants</link> (AICPA).
SOC controls assess relevant financial statements and
assertions of a service provider, such as compliance with the
Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on
Auditing Standards No. 70 (SAS 70) Type II report. These
controls commonly include physical data centers in
scope.</para>
<para>There are two types of SOC 1 reports:</para>
<itemizedlist>
<listitem>
<para>Type 1 – report on the fairness of the presentation of
management's description of the service organization's
system and the suitability of the design of the controls
to achieve the related control objectives included in the
description as of a specified date.</para>
</listitem>
<listitem>
<para>Type 2 – report on the fairness of the presentation of
management's description of the service organization's
system and the suitability of the design and operating
effectiveness of the controls to achieve the related
control objectives included in the description throughout
a specified period</para>
</listitem>
</itemizedlist>
<para>For more details see the <link
xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC1Report.aspx"
>AICPA Report on Controls at a Service Organization Relevant
to User Entities’ Internal Control over Financial
Reporting</link>.</para>
</section>
<section
xml:id="ch064_certifications-compliance-statements-idp53632">
<title>SOC 2</title>
<para>Service Organization Controls (SOC) 2 is a self
attestation of controls that affect the security,
availability, and processing integrity of the systems a
service organization uses to process users' data and the
confidentiality and privacy of information processed by these
system. Examples of users are those responsible for governance
of the service organization; customers of the service
organization; regulators; business partners; suppliers and
others who have an understanding of the service organization
and its controls.</para>
<para>There are two types of SOC 2 reports:</para>
<itemizedlist>
<listitem>
<para>Type 1 – report on the fairness of the presentation of
management's description of the service organization's
system and the suitability of the design of the controls
to achieve the related control objectives included in the
description as of a specified date.</para>
</listitem>
<listitem>
<para>Type 2 – report on the fairness of the presentation of
management's description of the service organization's
system and the suitability of the design and operating
effectiveness of the controls to achieve the related
control objectives included in the description throughout
a specified period.</para>
</listitem>
</itemizedlist>
<para>For more details see the <link
xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx"
>AICPA Report on Controls at a Service Organization Relevant
to Security, Availability, Processing Integrity,
Confidentiality or Privacy</link>.</para>
</section>
</section>
<section
xml:id="ch064_certifications-compliance-statements-idp60416">
<title>SOC 3</title>
<para>Service Organization Controls (SOC) 3 is a trust services
report for service organizations. These reports are designed to
meet the needs of users who want assurance on the controls at a
service organization related to security, availability,
processing integrity, confidentiality, or privacy but do not
have the need for or the knowledge necessary to make effective
use of a SOC 2 Report. These reports are prepared using the
AICPA/Canadian Institute of Chartered Accountants (CICA) Trust
Services Principles, Criteria, and Illustrations for Security,
Availability, Processing Integrity, Confidentiality, and
Privacy. Because they are general use reports, SOC 3 Reports can
be freely distributed or posted on a website as a seal.</para>
<para>For more details see the <link
xlink:href="http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx"
>AICPA Trust Services Report for Service
Organizations</link>.</para>
</section>
<section
xml:id="ch064_certifications-compliance-statements-idp62832">
<title>ISO 27001/2</title>
<para>The ISO/IEC 27001/2 standards replace BS7799-2, and are
specifications for an Information Security Management System
(ISMS). An ISMS is a comprehensive set of policies and processes
that an organization creates and maintains to manage risk to
information assets. These risks are based upon the
confidentiality, integrity, and availability (CIA) of user
information. The CIA security triad has been used as a
foundation for much of the chapters in this book.</para>
<para>For more details see <link
xlink:href="http://www.27000.org/iso-27001.htm">ISO
27001</link>.</para>
</section>
<section
xml:id="ch064_certifications-compliance-statements-idp65296">
<title>HIPAA / HITECH</title>
<para>The Health Insurance Portability and Accountability Act
(HIPAA) is a United States congressional act that governs the
collection, storage, use and destruction of patient health
records. The act states that Protected Health Information (PHI)
must be rendered "unusable, unreadable, or indecipherable" to
unauthorized persons and that encryption for data 'at-rest' and
'inflight' should be addressed.</para>
<para>HIPAA is not a certification, rather a guide for protecting
healthcare data. Similar to the PCI-DSS, the most important
issues with both PCI and HIPPA is that a breach of credit card
information, and health data, does not occur. In the instance of a
breach the cloud provider will be scrutinized for compliance
with PCI and HIPPA controls. If proven compliant, the provider
can be expected to immediately implement remedial controls,
breach notification responsibilities, and significant
expenditure on additional compliance activities. If not
compliant, the cloud provider can expect on-site audit teams,
fines, potential loss of merchant ID (PCI), and massive
reputation impact.</para>
<para>Users or organizations that possess PHI must support HIPAA
requirements and are HIPAA covered entities. If an entity
intends to use a service, or in this case, an OpenStack cloud
that might use, store or have access to that PHI, then a
Business Associate Agreement must be signed. The BAA is a
contract between the HIPAA covered entity and the OpenStack
service provider that requires the provider to handle that PHI
in accordance with HIPAA requirements. If the service provider
does not handle the PHI, such as with security controls and
hardening, then they are subject to HIPAA fines and
penalties.</para>
<para>OpenStack architects interpret and respond to HIPAA
statements, with data encryption remaining a core practice.
Currently this would require any protected health information
contained within an OpenStack deployment to be encrypted with
industry standard encryption algorithms. Potential future
OpenStack projects such as object encryption will facilitate
HIPAA guidelines for compliance with the act.</para>
<para>For more details see the <link
xlink:href="https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf"
>Health Insurance Portability And Accountability
Act</link>.</para>
<section
xml:id="ch064_certifications-compliance-statements-idp4736">
<title>PCI-DSS</title>
<para>The Payment Card Industry Data Security Standard (PCI DSS)
is defined by the Payment Card Industry Standards Council, and
created to increase controls around card holder data to reduce
credit card fraud. Annual compliance validation is assessed by
an external Qualified Security Assessor (QSA) who creates a
Report on Compliance (ROC), or by a Self-Assessment
Questionnaire (SAQ) dependent on volume of card-holder
transactions.</para>
<para>OpenStack deployments which stores, processes, or
transmits payment card details are in scope for the PCI-DSS.
All OpenStack components that are not properly segmented from
systems or networks that handle payment data fall under the
guidelines of the PCI-DSS. Segmentation in the context of
PCI-DSS does not support multi-tenancy, but rather physical
separation (host/network).</para>
<para>For more details see <link
xlink:href="https://www.pcisecuritystandards.org/security_standards/"
>PCI security standards</link>.</para>
</section>
</section>
<section xml:id="ch064_certifications-compliance-statements-idp8448">
<title>Government standards</title>
<section
xml:id="ch064_certifications-compliance-statements-idp9088">
<title>FedRAMP</title>
<para>"The <link xlink:href="http://www.fedramp.gov">Federal
Risk and Authorization Management Program</link> (FedRAMP)
is a government-wide program that provides a standardized
approach to security assessment, authorization, and continuous
monitoring for cloud products and services". NIST 800-53 is
the basis for both FISMA and FedRAMP which mandates security
controls specifically selected to provide protection in cloud
environments. FedRAMP can be extremely intensive from
specificity around security controls, and the volume of
documentation required to meet government standards.</para>
<para>For more details see <link
xlink:href="http://www.gsa.gov/portal/category/102371"
>http://www.gsa.gov/portal/category/102371</link>.</para>
</section>
<section
xml:id="ch064_certifications-compliance-statements-idp10768">
<title>ITAR</title>
<para>The International Traffic in Arms Regulations (ITAR) is a
set of United States government regulations that control the
export and import of defense-related articles and services on
the United States Munitions List (USML) and related technical
data. ITAR is often approached by cloud providers as an
"operational alignment" rather than a formal certification.
This typically involves implementing a segregated cloud
environment following practices based on the NIST 800-53
framework, as per FISMA requirements, complemented with
additional controls restricting access to "U.S. Persons" only
and background screening.</para>
<para>For more details see <link
xlink:href="http://pmddtc.state.gov/regulations_laws/itar_official.html"
>http://pmddtc.state.gov/regulations_laws/itar_official.html</link>.</para>
</section>
<section
xml:id="ch064_certifications-compliance-statements-idp89888">
<title>FISMA</title>
<para>The Federal Information Security Management Act requires
that government agencies create a comprehensive plan to
implement numerous government security standards, and was
enacted within the E-Government Act of 2002. FISMA outlines a
process, which utilizing multiple NIST publications, prepares
an information system to store and process government
data.</para>
<para>This process is broken apart into three primary
categories:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">System
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
system compromise.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Control
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
categorized as “moderate” a requirement may be introduced
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>
</listitem>
</itemizedlist>
</section>
</section>
</chapter>

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

@@ -1,15 +0,0 @@
<?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"
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>
<para>To aid OpenStack architects in the protection of personal data, it is recommended that OpenStack architects review the NIST publication 800-122, titled "<emphasis>Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)</emphasis>." This guide steps through the process of protecting:</para>
<blockquote>
<para>"<emphasis>any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information</emphasis>"</para>
</blockquote>
<para>Comprehensive privacy management requires significant preparation, thought and investment. Additional complications are introduced when building global OpenStack clouds, for example navigating the differences between U.S. and more restrictive E.U. privacy laws. In addition, extra care needs to be taken when dealing with sensitive PII that may include information such as credit card numbers or medical records. This sensitive data is not only subject to privacy laws but also regulatory and governmental regulations. By deferring to established best practices, including those published by governments, a holistic privacy management policy may be created and practiced for OpenStack deployments.</para>
</chapter>

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

@@ -1,47 +0,0 @@
<?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"
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>
<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>
<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
enterprises. Bob recognizes that individual developers are not
necessarily concerned with compliance certifications, but to
larger enterprises certifications are critical. Specifically Bob
desires to achieve SOC 1, SOC 2 Security, as well as ISO 27001/2
as quickly as possible. Bob references the Cloud Security
Alliance Cloud Control Matrix (CCM) to assist in identifying
common controls across these three certifications (such as
periodic access reviews, auditable logging and monitoring
services, risk assessment activities, security reviews, etc).
Bob then engages an experienced audit team to conduct a gap
analysis on the public cloud deployment, reviews the results and
fills any gaps identified. Bob works with other team members to
ensure that these security controls and activities are regularly
conducted for a typical audit period (~6-12 months).</para>
<para>At the end of the audit period Bob has arranged for an
external audit team to review in-scope security controls at
randomly sampled points of time over a 6 month period. The audit
team provides Bob with an official report for SOC 1 and SOC 2,
and separately for ISO 27001/2. As Bob has been diligent in
ensuring security controls are in place for his OpenStack public
cloud, there are no additional gaps exposed on the report. Bob
can now provide these official reports to his customers under
NDA, and advertise that he is SOC 1, SOC 2 and ISO 27001/2
compliant on his website.</para>
</section>
</chapter>

10242
doc/security-guide/locale/ja.po
View File

File diff suppressed because it is too large Load Diff

6093
doc/security-guide/locale/security-guide.pot
View File

File diff suppressed because it is too large Load Diff

75
doc/security-guide/pom.xml
View File

@@ -1,75 +0,0 @@
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>org.openstack.docs</groupId>
<artifactId>parent-pom</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>openstack-security-guide</artifactId>
<packaging>jar</packaging>
<name>OpenStack Security Guide</name>
<properties>
<!-- This is set by Jenkins according to the branch. -->
<release.path.name>local</release.path.name>
<comments.enabled>1</comments.enabled>
</properties>
<build>
<plugins>
<plugin>
<groupId>com.rackspace.cloud.api</groupId>
<artifactId>clouddocs-maven-plugin</artifactId>
<!-- version is set in ../pom.xml file -->
<executions>
<execution>
<id>security-guide</id>
<goals>
<goal>generate-webhelp</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<includes>bk-openstack-sec-guide.xml</includes>
<sourceDirectory>.</sourceDirectory>
<glossaryCollection>${basedir}/../glossary/glossary-terms.xml</glossaryCollection>
<webhelpDirname>security-guide</webhelpDirname>
<pdfFilenameBase>security-guide</pdfFilenameBase>
<enableDisqus>${comments.enabled}</enableDisqus>
<enableGoogleAnalytics>1</enableGoogleAnalytics>
<googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
<chapterAutolabel>1</chapterAutolabel>
<sectionAutolabel>0</sectionAutolabel>
<tocSectionDepth>1</tocSectionDepth>
<formalProcedures>0</formalProcedures>
<generateToc>
appendix toc,title
article/appendix nop
article toc,title
book toc,title,figure,table,equation
chapter toc
part toc,title
acknowledgements toc,title
preface toc
qandadiv toc
qandaset toc
reference toc,title
section toc
set toc,title
</generateToc>
<pageWidth>7.44in</pageWidth>
<pageHeight>9.68in</pageHeight>
<doubleSided>1</doubleSided>
<omitCover>1</omitCover>
</configuration>
</execution>
</executions>
<configuration>
<canonicalUrlBase>http://docs.openstack.org/security-guide/content</canonicalUrlBase>
<branding>openstack</branding>
<showXslMessages>true</showXslMessages>
</configuration>
</plugin>
</plugins>
</build>
</project>

28
doc/security-guide/roadmap.rst
View File

@@ -1,28 +0,0 @@
Roadmap for Security Guide
--------------------------
This file is stored with the source to offer ideas for what to work on.
Put your name next to a task if you want to work on it and put a WIP
review up on review.openstack.org.
May 20, 2014
To do tasks:
- Add OpenStack Security Notes (OSSN) as appendix
- Update for icehouse - this guide is continually released, but hasn't
had updates for latest releases of OpenStack
- Document SSL everywhere (it's there but does it need updating for latest
releases?)
- Document Hyper-V considerations and Windows security
- Document key management - Barbican is not yet integrated so must link
to their documentation externally and document Kite and other solutions
- Standardize diagrams
- Add audience information; who is this book intended for
Ongoing tasks:
- Ensure it meets conventions and standards
- Triage incoming bugs in openstack-manuals project
- Continually update with latest release information relevant to security
Wishlist tasks:
- Replace all individual client commands (like keystone, nova) with openstack client commands

BIN
doc/security-guide/static/1aa-logical-neutron-flow.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 129 KiB

BIN
doc/security-guide/static/1aa-network-domains-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 134 KiB

BIN
doc/security-guide/static/APL Logo.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 40 KiB

BIN
doc/security-guide/static/APL%20center%20blue.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

BIN
doc/security-guide/static/AttackTypes.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 135 KiB

BIN
doc/security-guide/static/Bridging Security Domains.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.5 MiB

BIN
doc/security-guide/static/BridgingSecurityDomains2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 691 KiB

BIN
doc/security-guide/static/CP_Logotype_small.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 19 KiB

BIN
doc/security-guide/static/CommonCriteria.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 45 KiB

BIN
doc/security-guide/static/DomainBridging2.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 88 KiB

BIN
doc/security-guide/static/HP RGB_WEB.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.8 KiB

BIN
doc/security-guide/static/HP RGB_WEB_1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.3 KiB

BIN
doc/security-guide/static/Networking_Use_Case1-Rough.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 43 KiB

BIN
doc/security-guide/static/Networking_Use_Case2-Rough.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 46 KiB

BIN
doc/security-guide/static/Nicira-byVMware_300.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 15 KiB

BIN
doc/security-guide/static/Nicira-byVMware_72.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.4 KiB

BIN
doc/security-guide/static/Nicira-byVMware_72_1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.1 KiB

BIN
doc/security-guide/static/Nicira-byVMware_logo_V_CL_CMYK.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 15 KiB

BIN
doc/security-guide/static/Openstack_Networking_Service_Communication_Channels.JPG
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.2 MiB

BIN
doc/security-guide/static/Quantum-PhysNet-Diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 95 KiB

BIN
doc/security-guide/static/Quantum_Components_Communication.JPG
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 2.1 MiB

BIN
doc/security-guide/static/Quantum_Components_Communication_1.JPG
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.0 MiB

BIN
doc/security-guide/static/Rackspace_Cloud_Company_Logo_clr.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 60 KiB

BIN
doc/security-guide/static/Rackspace_Cloud_Company_Logo_clr_1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 63 KiB

96
doc/security-guide/static/Red_Hat_CMYK.svg
View File

@@ -1,96 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 15.0.2, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="logo" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
width="612px" height="792px" viewBox="0 0 612 792" enable-background="new 0 0 612 792" xml:space="preserve">
<g id="logo_1_">
<g id="white">
<path fill="#FFFFFF" d="M238.501,435.013c-2.433-0.558-5.012-0.91-7.621-0.91c-4.463,0-8.524,0.772-11.519,2.021
c-0.33,0.163-0.565,0.509-0.565,0.9c0,0.145,0.036,0.289,0.09,0.412c0.354,1.025-0.227,2.137-3.126,2.775
c-4.298,0.944-7.011,5.38-8.563,6.852c-1.823,1.732-6.973,2.794-6.198,1.762c0.607-0.805,2.923-3.322,4.333-6.042
c1.261-2.432,2.383-3.123,3.93-5.443c0.453-0.679,2.212-3.069,2.724-4.961c0.574-1.844,0.38-4.162,0.601-5.114
c0.316-1.377,1.614-4.36,1.712-6.045c0.057-0.954-3.979,1.36-5.894,1.36s-3.779-1.148-5.49-1.23
c-2.117-0.098-3.478,1.635-5.394,1.331c-1.093-0.175-2.015-1.14-3.926-1.21c-2.722-0.1-6.047,1.514-12.294,1.312
c-6.144-0.201-11.82-7.767-12.594-8.97c-0.908-1.41-2.017-1.41-3.224-0.3c-1.21,1.107-2.7,0.236-3.125-0.508
c-0.806-1.408-2.96-5.529-6.298-6.395c-4.615-1.196-6.952,2.555-6.648,5.54c0.308,3.03,2.266,3.88,3.174,5.49
c0.906,1.612,1.37,2.649,3.077,3.362c1.209,0.507,1.659,1.251,1.299,2.245c-0.316,0.864-1.575,1.062-2.401,1.103
c-1.758,0.084-2.991-0.394-3.89-0.967c-1.045-0.669-1.896-1.594-2.808-3.164c-1.056-1.734-2.719-2.49-4.656-2.49
c-0.923,0-1.787,0.243-2.555,0.639c-3.036,1.582-6.649,2.516-10.54,2.516l-4.388,0.004c8.414,24.955,32.01,42.925,59.805,42.925
C207.731,463.813,227.255,452.349,238.501,435.013z"/>
</g>
<g id="black">
<g>
<path d="M247.988,431.645h0.569l0.859,1.41h0.553l-0.93-1.437c0.482-0.058,0.847-0.311,0.847-0.891
c0-0.647-0.381-0.927-1.149-0.927h-1.24v3.254h0.491V431.645z M247.988,431.227v-1.011h0.672c0.342,0,0.71,0.076,0.71,0.479
c0,0.499-0.37,0.532-0.791,0.532H247.988z"/>
<path d="M251.762,431.432c0,1.757-1.429,3.187-3.189,3.187s-3.19-1.43-3.19-3.187c0-1.761,1.43-3.19,3.19-3.19
S251.762,429.671,251.762,431.432z M248.572,428.806c-1.45,0-2.626,1.176-2.626,2.628c0,1.446,1.176,2.616,2.626,2.616
c1.447,0,2.622-1.17,2.622-2.616C251.194,429.981,250.02,428.806,248.572,428.806z"/>
</g>
<g>
<path d="M238.501,435.017c-2.433-0.562-5.012-0.91-7.621-0.91c-4.463,0-8.524,0.774-11.519,2.018
c-0.33,0.166-0.565,0.51-0.565,0.903c0,0.142,0.036,0.29,0.09,0.409c0.354,1.027-0.227,2.141-3.126,2.777
c-4.298,0.944-7.011,5.378-8.563,6.853c-1.823,1.729-6.973,2.795-6.198,1.763c0.607-0.807,2.923-3.324,4.333-6.045
c1.261-2.429,2.383-3.122,3.93-5.44c0.453-0.682,2.212-3.072,2.724-4.962c0.574-1.847,0.38-4.161,0.601-5.116
c0.316-1.374,1.614-4.359,1.712-6.043c0.057-0.952-3.979,1.357-5.894,1.357s-3.779-1.144-5.49-1.227
c-2.117-0.102-3.478,1.632-5.394,1.329c-1.093-0.175-2.015-1.137-3.926-1.209c-2.722-0.101-6.047,1.512-12.294,1.311
c-6.144-0.197-11.82-7.763-12.594-8.966c-0.908-1.413-2.017-1.413-3.224-0.302c-1.21,1.104-2.7,0.235-3.125-0.507
c-0.806-1.41-2.96-5.533-6.298-6.396c-4.615-1.198-6.952,2.555-6.648,5.539c0.308,3.029,2.266,3.879,3.174,5.489
c0.906,1.612,1.37,2.655,3.077,3.368c1.209,0.501,1.659,1.249,1.299,2.242c-0.316,0.864-1.575,1.062-2.401,1.103
c-1.758,0.083-2.991-0.394-3.89-0.97c-1.045-0.664-1.896-1.59-2.808-3.162c-1.056-1.734-2.719-2.489-4.656-2.489
c-0.923,0-1.787,0.245-2.555,0.639c-3.036,1.579-6.649,2.517-10.54,2.517h-4.388c-2.136-6.332-3.293-13.116-3.293-20.17
c0-34.849,28.25-63.097,63.098-63.097s63.096,28.248,63.096,63.097C248.626,413.365,244.906,425.14,238.501,435.017z"/>
</g>
<path d="M280.79,404.699c0-5.787-0.12-10.043-0.354-13.893h9.465l0.405,8.211h0.31c2.127-6.086,7.168-9.188,11.834-9.188
c1.067,0,1.689,0.04,2.563,0.236v10.296c-1.022-0.201-1.979-0.311-3.293-0.311c-5.208,0-8.822,3.313-9.798,8.268
c-0.185,0.964-0.283,2.12-0.283,3.298v22.418h-10.938L280.79,404.699z"/>
<path d="M318.208,415.362c0.289,7.833,6.352,11.26,13.352,11.26c5.026,0,8.624-0.787,11.929-2.001l1.617,7.52
c-3.697,1.57-8.832,2.741-15.105,2.741c-14.037,0-22.26-8.668-22.26-21.913c0-11.931,7.237-23.221,21.142-23.221
c14.056,0,18.631,11.561,18.631,21.023c0,2.031-0.181,3.662-0.389,4.67L318.208,415.362z M337.218,407.748
c0.05-4.006-1.693-10.533-9.014-10.533c-6.73,0-9.527,6.104-10.018,10.533H337.218z"/>
<path d="M383.68,415.291c0,1.146-0.081,2.213-0.331,3.188c-1.101,4.73-4.969,7.779-9.439,7.779c-6.882,0-10.82-5.802-10.82-13.744
c0-8.021,3.903-14.228,10.944-14.228c4.915,0,8.434,3.465,9.4,7.675c0.187,0.886,0.246,1.978,0.246,2.852V415.291z
M394.604,374.16l-10.925-3.082v24.382h-0.18c-1.934-3.193-6.196-5.631-12.113-5.631c-10.396,0-19.446,8.602-19.381,23.085
c0,13.287,8.176,22.091,18.499,22.091c6.238,0,11.453-2.973,14.036-7.815h0.194l0.49,6.845h9.739
c-0.201-2.938-0.36-7.699-0.36-12.124V374.16z"/>
<path d="M423.507,389.78c-3.292,0-6.241,0.949-8.719,2.479c-2.572,1.507-4.665,3.832-5.91,6.24h-0.173v-20.231l-4.28-1.264v57.031
h4.28v-26.457c0-1.758,0.134-2.977,0.582-4.262c1.849-5.382,6.92-9.798,13.049-9.798c8.856,0,11.923,7.103,11.923,14.893v25.624
h4.276v-26.096C438.535,391.826,427.607,389.78,423.507,389.78z"/>
<path d="M476.934,423.759c0,3.421,0.138,6.963,0.631,10.276h-3.941l-0.628-6.199h-0.204c-2.096,3.334-6.916,7.184-13.793,7.184
c-8.705,0-12.756-6.122-12.756-11.891c0-9.986,8.814-16.002,26.414-15.816v-1.156c0-4.28-0.832-12.816-11.065-12.749
c-3.786,0-7.73,1.013-10.86,3.224l-1.362-3.112c3.952-2.679,8.779-3.738,12.692-3.738c12.484,0,14.873,9.372,14.873,17.103
V423.759z M472.656,410.912c-9.421-0.271-21.859,1.156-21.859,11.543c0,6.217,4.104,9.012,8.61,9.012
c7.209,0,11.309-4.464,12.802-8.675c0.311-0.923,0.447-1.851,0.447-2.592V410.912z"/>
<path d="M493.973,381.236v9.534h12.332v3.471h-12.332v28.119c0,5.501,1.708,8.948,6.355,8.948c2.229,0,3.807-0.293,4.915-0.678
l0.519,3.313c-1.397,0.586-3.359,1.04-5.971,1.04c-3.157,0-5.775-0.994-7.466-3.068c-1.959-2.272-2.629-5.903-2.629-10.317V394.24
h-7.301v-3.471h7.301v-7.955L493.973,381.236z"/>
<g>
<path d="M511.711,431.731h0.568l0.857,1.408h0.554l-0.928-1.437c0.483-0.059,0.847-0.311,0.847-0.891
c0-0.647-0.385-0.927-1.15-0.927h-1.242v3.254h0.494V431.731z M511.711,431.312v-1.01h0.67c0.339,0,0.71,0.076,0.71,0.477
c0,0.501-0.371,0.533-0.791,0.533H511.711z"/>
<path d="M515.483,431.516c0,1.758-1.43,3.187-3.19,3.187c-1.757,0-3.189-1.429-3.189-3.187c0-1.761,1.433-3.189,3.189-3.189
C514.054,428.326,515.483,429.755,515.483,431.516z M512.293,428.891c-1.453,0-2.625,1.175-2.625,2.627
c0,1.447,1.172,2.616,2.625,2.616c1.447,0,2.622-1.169,2.622-2.616C514.915,430.065,513.74,428.891,512.293,428.891z"/>
</g>
<path d="M199.427,429.229c0.324,0.315,0.883,1.383,0.199,2.732c-0.383,0.717-0.796,1.22-1.534,1.809
c-0.887,0.713-2.623,1.533-5.002,0.025c-1.278-0.812-1.356-1.085-3.123-0.856c-1.262,0.166-1.764-1.107-1.311-2.168
c0.455-1.055,2.319-1.911,4.636-0.552c1.043,0.611,2.668,1.907,4.092,0.76c0.589-0.473,0.942-0.787,1.761-1.736
c0.038-0.038,0.09-0.062,0.147-0.062C199.343,429.182,199.391,429.201,199.427,429.229z"/>
</g>
<path id="red" fill="#E22434" d="M180.619,367.667c-7.288,0.527-8.044,1.314-9.41,2.768c-1.925,2.05-4.461-2.66-4.461-2.66
c-1.521-0.32-3.366-2.774-2.372-5.065c0.981-2.266,2.792-1.586,3.359-0.881c0.69,0.859,2.164,2.265,4.077,2.214
c1.913-0.05,4.12-0.452,7.198-0.452c3.119,0,5.217,1.165,5.334,2.166C184.446,366.61,184.092,367.415,180.619,367.667z
M188.276,355.624c-0.011,0-0.022,0.002-0.033,0.002c-0.113,0-0.204-0.087-0.204-0.191c0-0.077,0.047-0.143,0.115-0.174
c1.414-0.745,3.521-1.34,5.934-1.586c0.724-0.074,1.432-0.112,2.113-0.117c0.12,0,0.239,0,0.36,0.001
c4.044,0.092,7.281,1.699,7.234,3.589c-0.048,1.893-3.364,3.352-7.409,3.262c-1.309-0.031-2.538-0.221-3.596-0.526
c-0.125-0.033-0.215-0.139-0.215-0.265s0.091-0.235,0.218-0.267c2.523-0.584,4.226-1.538,4.106-2.439
c-0.159-1.195-3.458-1.846-7.372-1.453C189.098,355.505,188.681,355.56,188.276,355.624z M221.136,383.931
c-0.625,2.097-1.51,4.777-5.456,6.802c-0.575,0.295-0.794-0.188-0.529-0.642c1.491-2.536,1.756-3.17,2.189-4.17
c0.606-1.463,0.924-3.544-0.282-7.883c-2.373-8.54-7.323-19.954-10.922-23.657c-3.472-3.574-9.764-4.578-15.451-3.12
c-2.095,0.537-6.192,2.668-13.791,0.957c-13.152-2.962-15.101,3.623-15.854,6.491c-0.756,2.87-2.568,11.023-2.568,11.023
c-0.604,3.322-1.395,9.096,19.026,12.986c9.514,1.811,9.997,4.27,10.417,6.038c0.756,3.169,1.962,4.983,3.322,5.89
c1.359,0.908,0,1.658-1.508,1.812c-4.052,0.421-19.026-3.874-27.885-8.908c-7.249-4.429-7.369-8.418-5.71-11.801
c-10.948-1.184-19.166,1.026-20.654,6.209c-2.557,8.895,19.555,24.089,44.735,31.714c26.425,8,53.603,2.414,56.625-14.195
C238.21,391.931,231.854,386.349,221.136,383.931z"/>
</g>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 8.7 KiB

BIN
doc/security-guide/static/Red_Hat_RGB_300px.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.2 KiB

BIN
doc/security-guide/static/Red_Hat_RGB_300px_1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.2 KiB

BIN
doc/security-guide/static/Red_Hat_RGB_300px_2.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.0 KiB

BIN
doc/security-guide/static/Screen Shot 2013-06-28 at 10.23.28.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 296 KiB

BIN
doc/security-guide/static/SecurityDomains.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 74 KiB

BIN
doc/security-guide/static/SprintWall.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 25 KiB

BIN
doc/security-guide/static/ThreatActors.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 94 KiB

BIN
doc/security-guide/static/book-sprint-all-logos.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 71 KiB

BIN
doc/security-guide/static/bridging_domains_clouduser.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 73 KiB

3
doc/security-guide/static/bridging_domains_clouduser.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 7.3 KiB

BIN
doc/security-guide/static/bridging_security_domains.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

3
doc/security-guide/static/bridging_security_domains.svg
View File

@@ -1,3 +0,0 @@
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xl="http://www.w3.org/1999/xlink" version="1.1" viewBox="136 50 222 266" width="222pt" height="266pt"><metadata xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:date>2013-06-26 21:53Z</dc:date><!-- Produced by OmniGraffle Professional 5.4.3 --></metadata><defs><filter id="Shadow" filterUnits="userSpaceOnUse"><feGaussianBlur in="SourceAlpha" result="blur" stdDeviation="3.488"/><feOffset in="blur" result="offset" dx="0" dy="4"/><feFlood flood-color="black" flood-opacity=".75" result="flood"/><feComposite in="flood" in2="offset" operator="in"/></filter><font-face font-family="Helvetica" font-size="14" units-per-em="1000" underline-position="-75.683594" underline-thickness="49.316406" slope="0" x-height="522.94922" cap-height="717.28516" ascent="770.01953" descent="-229.98047" font-weight="500"><font-face-src><font-face-name name="Helvetica"/></font-face-src></font-face></defs><g stroke="none" stroke-opacity="1" stroke-dasharray="none" fill="none" fill-opacity="1"><title>Canvas 1</title><rect fill="white" width="576" height="733"/><g><title>Layer 1</title><g><use xl:href="#id440_Graphic" filter="url(#Shadow)"/><use xl:href="#id441_Graphic" filter="url(#Shadow)"/><use xl:href="#id444_Graphic" filter="url(#Shadow)"/><use xl:href="#id442_Graphic" filter="url(#Shadow)"/><use xl:href="#id63_Graphic" filter="url(#Shadow)"/></g><g id="id440_Graphic"><rect x="157.77354" y="158" width="179.28896" height="61" fill="white"/><rect x="157.77354" y="158" width="179.28896" height="61" stroke="#03f" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(162.77354 180)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" fill="black" x="0" y="14" textLength="81.716797">Management</tspan></text></g><g id="id441_Graphic"><rect x="156.8459" y="231" width="179.28896" height="61" fill="white"/><rect x="156.8459" y="231" width="179.28896" height="61" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(161.8459 253)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" fill="black" x="0" y="14" textLength="29.572266">Data</tspan></text></g><g id="id444_Graphic"><rect x="288" y="159" width="27.0625" height="132" fill="white"/><rect x="288" y="159" width="27.0625" height="132" stroke="#060" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(310.03125 180.46875) rotate(90)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" x=".25878906" y="14" textLength="89.48242">Compute Host</tspan></text></g><g id="id442_Graphic"><rect x="156.8459" y="87" width="179.28896" height="61" fill="white"/><rect x="156.8459" y="87" width="179.28896" height="61" stroke="#c00" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(161.8459 109)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" fill="black" x="0" y="14" textLength="38.13086">Public</tspan></text></g><g id="id63_Graphic"><rect x="247" y="66" width="27.0625" height="152" fill="white"/><rect x="247" y="66" width="27.0625" height="152" stroke="#060" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(269.03125 112.46875) rotate(90)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" x=".038085938" y="14" textLength="59.923828">API Node</tspan></text></g></g></g></svg>
Side by Side

Before

Width:  |  Height:  |  Size: 3.6 KiB

BIN
doc/security-guide/static/bridging_security_domains_1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 14 KiB

3
doc/security-guide/static/bridging_security_domains_1.svg
View File

@@ -1,3 +0,0 @@
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xl="http://www.w3.org/1999/xlink" version="1.1" viewBox="136 50 222 266" width="222pt" height="266pt"><metadata xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:date>2013-06-28 15:33Z</dc:date><!-- Produced by OmniGraffle Professional 5.4.3 --></metadata><defs><filter id="Shadow" filterUnits="userSpaceOnUse"><feGaussianBlur in="SourceAlpha" result="blur" stdDeviation="3.488"/><feOffset in="blur" result="offset" dx="0" dy="4"/><feFlood flood-color="black" flood-opacity=".75" result="flood"/><feComposite in="flood" in2="offset" operator="in"/></filter><font-face font-family="Helvetica" font-size="14" units-per-em="1000" underline-position="-75.683594" underline-thickness="49.316406" slope="0" x-height="522.94922" cap-height="717.28516" ascent="770.01953" descent="-229.98047" font-weight="500"><font-face-src><font-face-name name="Helvetica"/></font-face-src></font-face></defs><g stroke="none" stroke-opacity="1" stroke-dasharray="none" fill="none" fill-opacity="1"><title>Canvas 1</title><rect fill="white" width="576" height="733"/><g><title>Layer 1</title><g><use xl:href="#id440_Graphic" filter="url(#Shadow)"/><use xl:href="#id441_Graphic" filter="url(#Shadow)"/><use xl:href="#id444_Graphic" filter="url(#Shadow)"/><use xl:href="#id442_Graphic" filter="url(#Shadow)"/><use xl:href="#id63_Graphic" filter="url(#Shadow)"/></g><g id="id440_Graphic"><rect x="157.77354" y="158" width="179.28896" height="61" fill="white"/><rect x="157.77354" y="158" width="179.28896" height="61" stroke="#03f" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(162.77354 180)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" x="0" y="14" textLength="81.716797">Management</tspan></text></g><g id="id441_Graphic"><rect x="156.8459" y="231" width="179.28896" height="61" fill="white"/><rect x="156.8459" y="231" width="179.28896" height="61" stroke="black" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(161.8459 253)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" x="0" y="14" textLength="29.572266">Data</tspan></text></g><g id="id444_Graphic"><rect x="288" y="159" width="27.0625" height="132" fill="white"/><rect x="288" y="159" width="27.0625" height="132" stroke="#060" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(310.03125 180.46875) rotate(90)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" x=".25878906" y="14" textLength="89.48242">Compute Host</tspan></text></g><g id="id442_Graphic"><rect x="156.8459" y="87" width="179.28896" height="61" fill="white"/><rect x="156.8459" y="87" width="179.28896" height="61" stroke="#c00" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(161.8459 109)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" x="0" y="14" textLength="38.13086">Public</tspan></text></g><g id="id63_Graphic"><rect x="247" y="66" width="27.0625" height="152" fill="white"/><rect x="247" y="66" width="27.0625" height="152" stroke="#060" stroke-linecap="round" stroke-linejoin="round" stroke-width="1"/><text transform="translate(269.03125 76.46875) rotate(90)" fill="black"><tspan font-family="Helvetica" font-size="14" font-weight="500" x=".35205078" y="14" textLength="132.2959">API Service Endpoint</tspan></text></g></g></g></svg>
Side by Side

Before

Width:  |  Height:  |  Size: 3.5 KiB

BIN
doc/security-guide/static/conductor.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 77 KiB

BIN
doc/security-guide/static/conductor3.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 90 KiB

BIN
doc/security-guide/static/cs.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 32 KiB

Some files were not shown because too many files have changed in this diff Show More