# SOME DESCRIPTIVE TITLE. # Copyright (C) 2015-2017, OpenStack contributors # This file is distributed under the same license as the Security Guide package. # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Security Guide \n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2022-11-09 13:05+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../api-endpoints.rst:3 msgid "API endpoints" msgstr "" #: ../api-endpoints.rst:5 msgid "" "The process of engaging an OpenStack cloud is started through the querying " "of an API endpoint. While there are different challenges for public and " "private endpoints, these are high value assets that can pose a significant " "risk if compromised." msgstr "" #: ../api-endpoints.rst:10 msgid "" "This chapter recommends security enhancements for both public and private-" "facing API endpoints." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:3 msgid "API endpoint configuration recommendations" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:7 msgid "Internal API communications" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:9 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:14 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:21 msgid "Configure internal URLs in the Identity service catalog" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:23 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:28 msgid "To register an internal URL for an endpoint:" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:36 msgid "" "Replace ``MANAGEMENT_IP`` with the management IP address of your controller " "node." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:40 msgid "Configure applications for internal URLs" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:42 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:47 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:53 msgid "Configuration example #1: nova" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:66 msgid "Configuration example #2: cinder" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:74 msgid "Paste and middleware" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:76 msgid "" "Most API endpoints and other HTTP services in OpenStack use the Python Paste " "Deploy library. From a security perspective, this library enables " "manipulation of the request filter pipeline through the application's " "configuration. Each element in this chain is referred to as *middleware*. " "Changing the order of filters in the pipeline or adding additional " "middleware might have unpredictable security impact." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:83 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:88 msgid "" "For more information about Paste Deploy, see `Python Paste Deployment " "documentation <http://pythonpaste.org/deploy/>`__." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:93 msgid "API endpoint process isolation and policy" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:95 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:102 #: ../messaging/security.rst:192 msgid "Namespaces" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:104 msgid "" "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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:110 #: ../messaging/security.rst:206 msgid "Network policy" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:112 msgid "" "Because API endpoints typically bridge multiple security domains, you must " "pay particular attention to the compartmentalization of the API processes. " "See :ref:`Bridging_security_domains` for additional information in this area." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:116 msgid "" "With careful modeling, you can use network ACLs and IDS technologies to " "enforce explicit point to point communication between network services. As a " "critical cross domain service, this type of explicit enforcement works well " "for OpenStack's message queue service." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:121 msgid "" "To enforce policies, you can configure services, host-based firewalls (such " "as iptables), local policy (SELinux or AppArmor), and optionally global " "network policy." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:127 #: ../compute/hardening-the-virtualization-layers.rst:221 #: ../messaging/security.rst:218 msgid "Mandatory access controls" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:129 msgid "" "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 " "controls 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." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:138 msgid "API endpoint rate-limiting" msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:140 msgid "" "Rate Limiting is a means to control the frequency of events received by a " "network based application. When robust rate limiting is not present, it can " "result in an application being susceptible to various denial of service " "attacks. This is especially true for APIs, which by their nature are " "designed to accept a high frequency of similar request types and operations." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:146 msgid "" "Within OpenStack, it is recommended that all endpoints, especially public, " "are provided with an extra layer of protection, by means of either a rate-" "limiting proxy or web application firewall." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:150 msgid "" "It is key that the operator carefully plans and considers the individual " "performance needs of users and services within their OpenStack cloud when " "configuring and implementing any rate limiting functionality." msgstr "" #: ../api-endpoints/api-endpoint-configuration-recommendations.rst:154 msgid "" "Common solutions for providing rate-limiting are :term:`Nginx`, HAProxy, " "OpenRepose, or Apache Modules such as mod_ratelimit, mod_qos, or " "mod_security." msgstr "" #: ../appendix.rst:2 msgid "Appendix" msgstr "" #: ../block-storage.rst:3 ../introduction/introduction-to-openstack.rst:153 msgid "Block Storage" msgstr "" #: ../block-storage.rst:5 msgid "" "OpenStack Block Storage (cinder) is a service that provides software " "(services and libraries) to self-service manage persistent block-level " "storage devices. This creates on-demand access to Block Storage resources " "for use with OpenStack Compute (nova) instances. This creates software-" "defined storage via abstraction by virtualizing pools of block storage to a " "variety of back-end storage devices which can be either software " "implementations or traditional hardware storage products. The primary " "functions of this is to manage the creation, attaching and detaching of the " "block devices. The consumer requires no knowledge of the type of back-end " "storage equipment or where it is located." msgstr "" #: ../block-storage.rst:17 msgid "" "Compute instances store and retrieve block storage via industry-standard " "storage protocols such as iSCSI, ATA over Ethernet, or Fibre-Channel. These " "resources are managed and configured via OpenStack native standard HTTP " "RESTful API. For more details on the API see the `OpenStack Block Storage " "documentation <https://docs.openstack.org/api-ref/block-storage/>`__." msgstr "" #: ../block-storage.rst:32 ../image-storage.rst:23 msgid "" "Whilst this chapter is currently sparse on specific guidance, it is expected " "that standard hardening practices will be followed. This section will be " "expanded with relevant information." msgstr "" #: ../block-storage/checklist.rst:3 ../compute/checklist.rst:3 #: ../dashboard/checklist.rst:3 ../identity/checklist.rst:3 #: ../image-storage/checklist.rst:3 ../networking/checklist.rst:3 #: ../secrets-management/checklist.rst:5 ../shared-file-systems/checklist.rst:5 msgid "Checklist" msgstr "" #: ../block-storage/checklist.rst:8 msgid "" "Check-Block-01: Is user/group ownership of config files set to root/cinder?" msgstr "" #: ../block-storage/checklist.rst:10 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally, modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues resulting in " "a denial of service to the other end users. Thus user ownership of such " "critical configuration files must be set to root and group ownership must be " "set to cinder. Additionally, the containing directory should have the same " "ownership to ensure that new files are owned correctly." msgstr "" #: ../block-storage/checklist.rst:19 ../block-storage/checklist.rst:44 #: ../compute/checklist.rst:19 ../compute/checklist.rst:47 #: ../dashboard/checklist.rst:18 ../dashboard/checklist.rst:39 #: ../identity/checklist.rst:17 ../identity/checklist.rst:44 #: ../image-storage/checklist.rst:19 ../image-storage/checklist.rst:49 #: ../networking/checklist.rst:19 ../networking/checklist.rst:45 #: ../secrets-management/checklist.rst:21 #: ../secrets-management/checklist.rst:46 #: ../shared-file-systems/checklist.rst:21 #: ../shared-file-systems/checklist.rst:46 msgid "Run the following commands:" msgstr "" #: ../block-storage/checklist.rst:29 msgid "" "**Pass:** If user and group ownership of all these config files is set to " "root and cinder respectively. The above commands show output of root cinder." msgstr "" #: ../block-storage/checklist.rst:32 msgid "" "**Fail:** If the above commands does not return any output as the user and " "group ownership might have set to any user other than root or any group " "other than cinder." msgstr "" #: ../block-storage/checklist.rst:39 msgid "Check-Block-02: Are strict permissions set for configuration files?" msgstr "" #: ../block-storage/checklist.rst:41 msgid "" "Similar to the previous check, we recommend setting strict access " "permissions for such configuration files." msgstr "" #: ../block-storage/checklist.rst:54 ../compute/checklist.rst:56 #: ../identity/checklist.rst:57 ../image-storage/checklist.rst:66 #: ../networking/checklist.rst:55 ../secrets-management/checklist.rst:55 #: ../shared-file-systems/checklist.rst:56 msgid "" "A broader restriction is also possible: if the containing directory is set " "to 750, the guarantee is made that newly created files inside this directory " "would have the desired permissions." msgstr "" #: ../block-storage/checklist.rst:58 msgid "" "**Pass:** If permissions are set to 640 or stricter, or the containing " "directory is set to 750. The permissions of 640/750 translates into owner r/" "w, group r, and no rights to others i.e. \"u=rw,g=r,o=\". Note that with :" "ref:`check_block_01` and permissions set to 640, root has read/write access " "and cinder has read access to these configuration files. The access rights " "can also be validated using the following command. This command will only be " "available on your system if it supports ACLs." msgstr "" #: ../block-storage/checklist.rst:76 ../dashboard/checklist.rst:62 #: ../image-storage/checklist.rst:91 ../networking/checklist.rst:78 #: ../shared-file-systems/checklist.rst:78 msgid "**Fail:** If permissions are not set to at least 640." msgstr "" #: ../block-storage/checklist.rst:81 msgid "Check-Block-03: Is keystone used for authentication?" msgstr "" #: ../block-storage/checklist.rst:83 ../compute/checklist.rst:90 #: ../image-storage/checklist.rst:98 ../networking/checklist.rst:85 #: ../shared-file-systems/checklist.rst:85 msgid "" "This item only applies to OpenStack releases Rocky and before as " "``auth_strategy`` was deprecated in Stein." msgstr "" #: ../block-storage/checklist.rst:88 msgid "" "OpenStack supports various authentication strategies like noauth, keystone " "etc. If the 'noauth' strategy is used then the users could interact with " "OpenStack services without any authentication. This could be a potential " "risk since an attacker might gain unauthorized access to the OpenStack " "components. Thus we strongly recommend that all services must be " "authenticated with keystone using their service accounts." msgstr "" #: ../block-storage/checklist.rst:95 msgid "" "**Pass:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section in ``/etc/cinder/cinder.conf`` is set to ``keystone``." msgstr "" #: ../block-storage/checklist.rst:98 ../shared-file-systems/checklist.rst:100 msgid "" "**Fail:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section is set to ``noauth``." msgstr "" #: ../block-storage/checklist.rst:104 msgid "Check-Block-04: Is TLS enabled for authentication?" msgstr "" #: ../block-storage/checklist.rst:106 ../block-storage/checklist.rst:129 #: ../networking/checklist.rst:108 msgid "" "OpenStack components communicate with each other using various protocols and " "the communication might involve sensitive / confidential data. An attacker " "may try to eavesdrop on the channel in order to get access to sensitive " "information. Thus all the components must communicate with each other using " "a secured communication protocol." msgstr "" #: ../block-storage/checklist.rst:112 msgid "" "**Pass:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/cinder/cinder.conf`` is set to " "Identity API endpoint starting with ``https://`` and value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/cinder/cinder.conf`` is set to ``False``." msgstr "" #: ../block-storage/checklist.rst:118 msgid "" "**Fail:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/cinder/cinder.conf`` is not set " "to Identity API endpoint starting with ``https://`` or value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/cinder/cinder.conf`` is set to ``True``." msgstr "" #: ../block-storage/checklist.rst:127 msgid "Check-Block-05: Does cinder communicate with nova over TLS?" msgstr "" #: ../block-storage/checklist.rst:135 msgid "" "**Pass:** If value of parameter ``nova_api_insecure`` under ``[DEFAULT]`` " "section in ``/etc/cinder/cinder.conf`` is set to ``False``." msgstr "" #: ../block-storage/checklist.rst:138 msgid "" "**Fail:** If value of parameter ``nova_api_insecure`` under ``[DEFAULT]`` " "section in ``/etc/cinder/cinder.conf`` is set to ``True``." msgstr "" #: ../block-storage/checklist.rst:144 msgid "Check-Block-06: Does cinder communicate with glance over TLS?" msgstr "" #: ../block-storage/checklist.rst:146 msgid "" "Similar to previous check (:ref:`check_block_05`), we recommend that all " "components communicate with each other using a secured communication " "protocol." msgstr "" #: ../block-storage/checklist.rst:149 msgid "" "**Pass:** If value of parameter ``glance_api_insecure`` under ``[DEFAULT]`` " "section in ``/etc/cinder/cinder.conf`` is set to ``False`` and value of " "parameter ``glance_api_servers`` is set to a value starting with ``https://" "``." msgstr "" #: ../block-storage/checklist.rst:153 msgid "" "**Fail:** If value of parameter ``glance_api_insecure`` under ``[DEFAULT]`` " "section in ``/etc/cinder/cinder.conf`` is set to ``True`` or the value of " "parameter ``glance_api_servers`` is set to a value that does not start with " "``https://``." msgstr "" #: ../block-storage/checklist.rst:161 msgid "Check-Block-07: Is NAS operating in a secure environment?" msgstr "" #: ../block-storage/checklist.rst:163 msgid "" "Cinder supports an NFS driver which works differently than a traditional " "block storage driver. The NFS driver does not actually allow an instance to " "access a storage device at the block level. Instead, files are created on an " "NFS share and mapped to instances, which emulates a block device. Cinder " "supports secure configuration for such files by controlling the file " "permissions when cinder volumes are created. Cinder configuration can also " "control whether file operations are run as the root user or the current " "OpenStack process user." msgstr "" #: ../block-storage/checklist.rst:171 msgid "" "**Pass:** If value of parameter ``nas_secure_file_permissions`` under " "``[DEFAULT]`` section in ``/etc/cinder/cinder.conf`` is set to ``auto``. " "When set to ``auto``, a check is done during cinder startup to determine if " "there are existing cinder volumes, no volumes will set the option to " "``True``, and use secure file permissions. The detection of existing volumes " "will set the option to ``False``, and use the current insecure method of " "handling file permissions. If value of parameter " "``nas_secure_file_operations`` under ``[DEFAULT]`` section in ``/etc/cinder/" "cinder.conf`` is set to ``auto``. When set to \"auto\", a check is done " "during cinder startup to determine if there are existing cinder volumes, no " "volumes will set the option to ``True``, be secure and do NOT run as the " "``root`` user. The detection of existing volumes will set the option to " "``False``, and use the current method of running operations as the ``root`` " "user. For new installations, a \"marker file\" is written so that subsequent " "restarts of cinder will know what the original determination had been." msgstr "" #: ../block-storage/checklist.rst:187 msgid "" "**Fail:** If value of parameter ``nas_secure_file_permissions`` under " "``[DEFAULT]`` section in ``/etc/cinder/cinder.conf`` is set to ``False`` and " "if value of parameter ``nas_secure_file_operations`` under ``[DEFAULT]`` " "section in ``/etc/cinder/cinder.conf`` is set to ``False``." msgstr "" #: ../block-storage/checklist.rst:196 msgid "" "Check-Block-08: Is max size for the body of a request set to default " "(114688)?" msgstr "" #: ../block-storage/checklist.rst:198 msgid "" "If the maximum body size per request is not defined, the attacker can craft " "an arbitrary osapi request of large size causing the service to crash and " "finally resulting in Denial Of Service attack. Assigning the maximum value " "ensures that any malicious oversized request gets blocked ensuring continued " "availability of the service." msgstr "" #: ../block-storage/checklist.rst:204 msgid "" "**Pass:** If value of parameter ``osapi_max_request_body_size`` under " "``[DEFAULT]`` section in ``/etc/cinder/cinder.conf`` is set to ``114688`` or " "if value of parameter ``max_request_body_size`` under ``[oslo_middleware]`` " "section in ``/etc/cinder/cinder.conf`` is set to ``114688``." msgstr "" #: ../block-storage/checklist.rst:209 msgid "" "**Fail:** If value of parameter ``osapi_max_request_body_size`` under " "``[DEFAULT]`` section in ``/etc/cinder/cinder.conf`` is not set to " "``114688`` or if value of parameter ``max_request_body_size`` under " "``[oslo_middleware]`` section in ``/etc/cinder/cinder.conf`` is not set to " "``114688``." msgstr "" #: ../block-storage/checklist.rst:218 msgid "Check-Block-09: Is the volume encryption feature enabled?" msgstr "" #: ../block-storage/checklist.rst:220 msgid "" "Unencrypted volume data makes volume-hosting platforms especially high-value " "targets for attackers, as it allows the attacker to read the data for many " "different VMs. In addition, the physical storage medium could be stolen, " "remounted, and accessed from a different machine. Encrypting volume data " "mitigates these risks and provides defense-in-depth to volume-hosting " "platforms. Block Storage (cinder) is able to encrypt volume data before it " "is written to disk, and we recommend that the volume encryption feature is " "enabled. See the `Volume Encryption <https://docs.openstack.org/cinder/" "latest/configuration/block-storage/volume-encryption.html>`__ section of the " "Openstack Cinder Service Configuration documentation for instructions." msgstr "" #: ../block-storage/checklist.rst:232 msgid "" "**Pass:** If 1) the value of parameter ``backend`` under the " "``[key_manager]`` section in ``/etc/cinder/cinder.conf`` is set, 2) the " "value of parameter ``backend`` under ``[key_manager]`` in ``/etc/nova/nova." "conf`` is set, and 3) if the instructions in the documentation referenced " "above are properly followed." msgstr "" #: ../block-storage/checklist.rst:238 msgid "" "To verify further, perform these steps after completing the volume " "encryption setup and creating the volume-type for LUKS as described in the " "documentation referenced above." msgstr "" #: ../block-storage/checklist.rst:242 msgid "Create a VM:" msgstr "" #: ../block-storage/checklist.rst:248 msgid "Create an encrypted volume and attach it to your VM:" msgstr "" #: ../block-storage/checklist.rst:256 msgid "" "On the VM, send some text to the newly attached volume and synchronize it:" msgstr "" #: ../block-storage/checklist.rst:263 msgid "" "On the system hosting cinder volume services, synchronize to flush the I/O " "cache then test to see if your string can be found:" msgstr "" #: ../block-storage/checklist.rst:271 msgid "" "The search should not return the string written to the encrypted volume." msgstr "" #: ../block-storage/checklist.rst:273 msgid "" "**Fail:** If value of parameter ``backend`` under ``[key_manager]`` section " "in ``/etc/cinder/cinder.conf`` is not set, or if the value of parameter " "``backend`` under ``[key_manager]`` section in ``/etc/nova/nova.conf`` is " "not set, or if the instructions in the documentation referenced above are " "not properly followed." msgstr "" #: ../block-storage/volume_wiping.rst:3 msgid "Volume Wiping" msgstr "" #: ../block-storage/volume_wiping.rst:5 msgid "" "There are several ways to wipe a block storage device. The traditional way " "is to set the ``lvm_type`` to ``thin``, and then use the ``volume_clear`` " "parameter if using the LVM backend. Alternatively, if the volume encryption " "feature is used, then volume wiping is not necessary if the volume " "encryption key is deleted. See the OpenStack Configuration Reference doc in " "the `Volume Encryption <https://docs.openstack.org/cinder/latest/" "configuration/block-storage/volume-encryption.html>`__ section for set up " "details and also the `Castellan usage <https://docs.openstack.org/castellan/" "latest/user/index.html>`__ document for key deletion." msgstr "" #: ../block-storage/volume_wiping.rst:18 msgid "" "In older OpenStack releases, ``lvm_type=default`` was used to signify a " "wipe. While this method still works, ``lvm_type=default`` is not recommended " "for setting secure delete." msgstr "" #: ../block-storage/volume_wiping.rst:22 msgid "" "The ``volume_clear`` parameter can be set to ``zero``. The ``zero`` argument " "will write a single pass of zeroes to the device." msgstr "" #: ../block-storage/volume_wiping.rst:25 msgid "" "For more information about the ``lvm_type`` parameter, see sections `LVM " "<https://docs.openstack.org/cinder/latest/configuration/block-storage/" "drivers/lvm-volume-driver.html>`__ and `Oversubscription in thin " "provisioning <https://docs.openstack.org/cinder/latest/admin/blockstorage-" "over-subscription.html>`__ of the *cinder* project documentation." msgstr "" #: ../block-storage/volume_wiping.rst:32 msgid "" "For more information about the ``volume_clear`` parameter, see section " "`Cinder Configuration Options <https://docs.openstack.org/cinder/latest/" "sample_config.html>`__ of the *cinder* project documentation." msgstr "" #: ../checklist.rst:3 msgid "Security Checklist" msgstr "" #: ../checklist.rst:5 msgid ":doc:`Identity service checklist <identity/checklist>`" msgstr "" #: ../checklist.rst:6 msgid ":doc:`Dashboard checklist <dashboard/checklist>`" msgstr "" #: ../checklist.rst:7 msgid ":doc:`Compute service checklist <compute/checklist>`" msgstr "" #: ../checklist.rst:8 msgid ":doc:`Block Storage service checklist <block-storage/checklist>`" msgstr "" #: ../checklist.rst:9 msgid "" ":doc:`Shared File Systems service checklist <shared-file-systems/checklist>`" msgstr "" #: ../checklist.rst:10 msgid ":doc:`Networking service checklist <networking/checklist>`" msgstr "" #: ../compliance.rst:3 msgid "Compliance" msgstr "" #: ../compliance.rst:5 msgid "" "An OpenStack deployment may require compliance activities for many purposes, " "such as regulatory and legal requirements, customer need, privacy " "considerations, and security best practices. The Compliance function is " "important for the business and its customers. Compliance means adhering to " "regulations, specifications, standards and laws. It is also used when " "describing an organizations status regarding assessments, audits, and " "certifications. Compliance, when done correctly, unifies and strengthens the " "other security topics discussed in this guide." msgstr "" #: ../compliance.rst:14 msgid "This chapter has several objectives:" msgstr "" #: ../compliance.rst:16 msgid "Review common security principles." msgstr "" #: ../compliance.rst:18 msgid "" "Discuss common control frameworks and certification resources to achieve " "industry certifications or regulator attestations." msgstr "" #: ../compliance.rst:21 msgid "Act as a reference for auditors when evaluating OpenStack deployments." msgstr "" #: ../compliance.rst:24 msgid "" "Introduce privacy considerations specific to OpenStack and cloud " "environments." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:3 msgid "Certification and compliance statements" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:5 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:13 msgid "Commercial standards" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:15 msgid "" "For commercial deployments of OpenStack, we recommend SOC 1/2 is combined " "with ISO 2700 1/2 to 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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:23 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:30 msgid "SOC 1 (SSAE 16) / ISAE 3402" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:32 msgid "" "Service Organization Controls (SOC) criteria are defined by the `American " "Institute of Certified Public Accountants <http://www.aicpa.org/>`_ (AICPA). " "SOC controls assess relevant financial statements and assertions of a :term:" "`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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:40 msgid "There are two types of SOC 1 reports:" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:42 #: ../compliance/certification-and-compliance-statements.rst:71 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:47 msgid "" "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" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:53 msgid "" "For more details see the `AICPA Report on Controls at a Service Organization " "Relevant to User Entities' Internal Control over Financial Reporting <http://" "www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/" "AICPASOC1Report.aspx>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:58 msgid "SOC 2" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:60 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:69 msgid "There are two types of SOC 2 reports:" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:76 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:82 msgid "" "For more details see the `AICPA Report on Controls at a Service Organization " "Relevant to Security, Availability, Processing Integrity, Confidentiality or " "Privacy <http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/" "Pages/AICPASOC2Report.aspx>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:88 msgid "SOC 3" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:90 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:102 msgid "" "For more details see the `AICPA Trust Services Report for Service " "Organizations <http://www.aicpa.org/InterestAreas/FRC/" "AssuranceAdvisoryServices/Pages/AICPASOC3Report.aspx>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:106 msgid "ISO 27001/2" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:108 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:116 msgid "For more details see `ISO 27001 <http://www.27000.org/iso-27001.htm>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:119 msgid "HIPAA / HITECH" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:121 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:128 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:139 msgid "" "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 (BAA) 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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:149 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:156 msgid "" "For more details see the `Health Insurance Portability And Accountability " "Act <https://www.cms.gov/Regulations-and-Guidance/HIPAA-Administrative-" "Simplification/HIPAAGenInfo/downloads/HIPAALaw.pdf>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:161 msgid "PCI-DSS" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:163 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:171 msgid "" "OpenStack deployments that store, process, or transmit 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)." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:178 msgid "" "For more details see `PCI security standards <https://www." "pcisecuritystandards.org/security_standards/>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:182 msgid "Government standards" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:185 msgid "FedRAMP" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:187 msgid "" "\"The `Federal Risk and Authorization Management Program <http://www.fedramp." "gov>`_ (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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:197 msgid "" "For more details see `FedRAMP <http://www.gsa.gov/portal/category/102371>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:200 msgid "ITAR" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:202 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:212 msgid "" "For more details see `The International Traffic in Arms Regulations (ITAR) " "<https://www.pmddtc.state.gov/regulations_laws/itar.html>`_." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:217 msgid "FISMA" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:219 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:225 msgid "This process is broken apart into three primary categories:" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:228 msgid "" "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." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:230 msgid "System categorization:" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:233 msgid "" "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\"." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:237 msgid "Control selection:" msgstr "" #: ../compliance/certification-and-compliance-statements.rst:240 msgid "" "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\"." msgstr "" #: ../compliance/certification-and-compliance-statements.rst:241 msgid "Control tailoring:" msgstr "" #: ../compliance/compliance-activities.rst:3 msgid "Compliance activities" msgstr "" #: ../compliance/compliance-activities.rst:5 msgid "" "There are a number of standard activities that will greatly assist with the " "compliance process. This chapter outlines some of the most common compliance " "activities. These are not specific to OpenStack, however references are " "provided to relevant sections in this book as useful context." msgstr "" #: ../compliance/compliance-activities.rst:12 msgid "Information Security Management system (ISMS)" msgstr "" #: ../compliance/compliance-activities.rst:14 msgid "" "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 " "`ISO/IEC 27001/2 <http://www.27000.org/iso-27001.htm>`_, which creates a " "solid foundation of security controls and practices for achieving more " "stringent compliance certifications. This standard was updated in 2013 to " "reflect the growing use of cloud services and places more emphasis on " "measuring and evaluating how well an organization's ISMS is performing." msgstr "" #: ../compliance/compliance-activities.rst:25 msgid "Risk assessment" msgstr "" #: ../compliance/compliance-activities.rst:27 msgid "" "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. Risks can be rated using a variety of " "mechanisms. For example, likelihood versus impact. An OpenStack deployment " "risk assessment can include control gaps." msgstr "" #: ../compliance/compliance-activities.rst:37 msgid "Access and log reviews" msgstr "" #: ../compliance/compliance-activities.rst:39 msgid "" "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 :ref:`monitoring-and-" "logging`." msgstr "" #: ../compliance/compliance-activities.rst:44 msgid "" "The OpenStack Identity service supports Cloud Auditing Data Federation " "(CADF) notification, providing auditing data for compliance with security, " "operational, and business processes. For more information, see the `Keystone " "developer documentation <https://docs.openstack.org/keystone/latest/advanced-" "topics/event_notifications.html#auditing-with-cadf>`_." msgstr "" #: ../compliance/compliance-activities.rst:52 msgid "Backup and disaster recovery" msgstr "" #: ../compliance/compliance-activities.rst:54 msgid "" "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." msgstr "" #: ../compliance/compliance-activities.rst:61 msgid "Security training" msgstr "" #: ../compliance/compliance-activities.rst:63 msgid "" "Annual, role-specific, security training is a mandatory requirement for " "almost all compliance certifications and attestations. To optimize 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." msgstr "" #: ../compliance/compliance-activities.rst:71 msgid "Security reviews" msgstr "" #: ../compliance/compliance-activities.rst:73 msgid "" "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 modeling, 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 `Microsoft SDL <http://www.microsoft.com/security/sdl/process/" "release.aspx>`_, created as part of the Microsoft Trustworthy Computing " "Initiative." msgstr "" #: ../compliance/compliance-activities.rst:87 #: ../management/continuous-systems-management.rst:12 msgid "Vulnerability management" msgstr "" #: ../compliance/compliance-activities.rst:89 msgid "" "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." msgstr "" #: ../compliance/compliance-activities.rst:99 msgid "Data classification" msgstr "" #: ../compliance/compliance-activities.rst:101 msgid "" "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). The underlying principle is that data classifications are " "clearly defined and in-use. The most common protective mechanisms include " "industry standard encryption technologies." msgstr "" #: ../compliance/compliance-activities.rst:112 msgid "Exception process" msgstr "" #: ../compliance/compliance-activities.rst:114 msgid "" "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." msgstr "" #: ../compliance/overview.rst:3 msgid "Compliance overview" msgstr "" #: ../compliance/overview.rst:6 msgid "Security principles" msgstr "" #: ../compliance/overview.rst:8 msgid "" "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." msgstr "" #: ../compliance/overview.rst:14 msgid "Layered defenses" msgstr "" #: ../compliance/overview.rst:16 msgid "" "Identify where risks exist in a cloud architecture and apply controls to " "mitigate the risks. In areas of significant concern, layered defenses " "provide multiple complementary controls to manage risk down to an acceptable " "level. For example, to ensure adequate isolation between cloud tenants, we " "recommend hardening :term:`QEMU <Quick EMUlator (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." msgstr "" #: ../compliance/overview.rst:28 msgid "Fail securely" msgstr "" #: ../compliance/overview.rst:30 msgid "" "In the case of failure, systems should be configured to fail into a closed " "secure state. For example, TLS certificate verification should fail closed " "by severing the network connection if the CNAME does not 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." msgstr "" #: ../compliance/overview.rst:38 msgid "Least privilege" msgstr "" #: ../compliance/overview.rst:40 msgid "" "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 principle of least privilege is written into several international " "government security policies, such as NIST 800-53 Section AC-6 within the " "United States." msgstr "" #: ../compliance/overview.rst:47 msgid "Compartmentalize" msgstr "" #: ../compliance/overview.rst:49 msgid "" "Systems should be segregated in such a 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." msgstr "" #: ../compliance/overview.rst:55 msgid "Promote privacy" msgstr "" #: ../compliance/overview.rst:57 msgid "" "The amount of information that can be gathered about a system and its users " "should be minimized." msgstr "" #: ../compliance/overview.rst:61 msgid "Logging capability" msgstr "" #: ../compliance/overview.rst:63 msgid "" "Appropriate logging is implemented to monitor for unauthorized use, incident " "response and forensics. We highly recommend selected audit subsystems be " "Common Criteria certified, which provides non-attestable event records in " "most countries." msgstr "" #: ../compliance/overview.rst:69 msgid "Common control frameworks" msgstr "" #: ../compliance/overview.rst:71 msgid "" "The following is a list of Control Frameworks that an organization can use " "to build their security controls." msgstr "" #: ../compliance/overview.rst:74 msgid "" "`Cloud Security Alliance (CSA) Common Control Matrix (CCM) <https://" "cloudsecurityalliance.org/media/news/csa-releases-new-ccm-caiq-v3-0-1/>`_" msgstr "" #: ../compliance/overview.rst:77 msgid "" "The CSA CCM is specifically designed to provide fundamental security " "principles to guide cloud vendors and to assist prospective cloud customers " "in assessing the overall security risk of a cloud provider. The CSA CCM " "provides a controls framework that are aligned across 16 security domains. " "The foundation of the Cloud Controls Matrix rests on its customized " "relationship to other industry standards, regulations, and controls " "frameworks such as: ISO 27001:2013, COBIT 5.0, PCI:DSS v3, AICPA 2014 Trust " "Service Principles and Criteria and augments internal control direction for " "service organization control reports attestations." msgstr "" #: ../compliance/overview.rst:87 msgid "" "The CSA CCM strengthens existing information security control environments " "by enabling the reduction of security threats and vulnerabilities in the " "cloud, provides standardized security and operational risk management, and " "seeks to normalize security expectations, cloud taxonomy and terminology, " "and security measures implemented in the cloud." msgstr "" #: ../compliance/overview.rst:94 msgid "`ISO 27001/2:2013 <http://www.27000.org/iso-27001.htm>`_" msgstr "" #: ../compliance/overview.rst:96 msgid "" "The ISO 27001 Information Security standard and certification has been used " "for many years to evaluate and distinguish an organizations alignment with " "information Security best practices. The standard is comprised of two parts: " "Mandatory Clauses that define the Information Security Management System " "(ISMS) and Annex A which contains a list of controls organized by domain." msgstr "" #: ../compliance/overview.rst:103 msgid "" "The information security management system preserves the confidentiality, " "integrity, and availability of information by applying a risk management " "process and gives confidence to interested parties that risks are adequately " "managed." msgstr "" #: ../compliance/overview.rst:108 msgid "" "`Trusted Security Principles <http://www.aicpa.org/interestareas/" "informationtechnology/resources/soc/trustservices/pages/trust%20services" "%20principles—an%20overview.aspx>`_" msgstr "" #: ../compliance/overview.rst:111 msgid "" "Trust Services are a set of professional attestation and advisory services " "based on a core set of principles and criteria that address the risks and " "opportunities of IT-enabled systems and privacy programs. Commonly known as " "the SOC audits, the principles define what the requirement is and it is the " "organizations responsibility to define the control that meets the " "requirement." msgstr "" #: ../compliance/overview.rst:119 msgid "Audit reference" msgstr "" #: ../compliance/overview.rst:121 msgid "" "OpenStack is innovative in many ways however the process used to audit an " "OpenStack deployment is fairly common. Auditors will evaluate a process by " "two criteria: Is the control designed effectively and if the control is " "operating effectively. An understanding of how an auditor evaluates if a " "control is designed and operating effectively will be discussed in the " "section called :doc:`understanding-the-audit-process`." msgstr "" #: ../compliance/overview.rst:128 msgid "" "The most common frameworks for auditing and evaluating a cloud deployment " "include the previously mentioned ISO 27001/2 Information Security standard, " "ISACA's Control Objectives for Information and Related Technology (COBIT) " "framework, Committee of Sponsoring Organizations of the Treadway Commission " "(COSO), and Information Technology Infrastructure Library (ITIL). It is very " "common for audits to include areas of focus from one or more of these " "frameworks. Fortunately there is a lot of overlap between the frameworks, so " "an organization that adopts one will be in a good position come audit time." msgstr "" #: ../compliance/privacy.rst:3 msgid "Privacy" msgstr "" #: ../compliance/privacy.rst:5 msgid "" "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." msgstr "" #: ../compliance/privacy.rst:10 msgid "" "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 `defined 10 privacy areas of focus " "<http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/" "generallyacceptedprivacyprinciples/>`_, OpenStack deployments within a " "commercial environment may desire to attest to some or all of these " "principles." msgstr "" #: ../compliance/privacy.rst:19 msgid "" "To aid OpenStack architects in the protection of personal data, we recommend " "OpenStack architects review the NIST publication 800-122, titled \"*Guide to " "Protecting the Confidentiality of Personally Identifiable Information (PII)*." "\" This guide steps through the process of protecting:" msgstr "" #: ../compliance/privacy.rst:25 msgid "" "\"... 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...\"" msgstr "" #: ../compliance/privacy.rst:33 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:3 msgid "Understanding the audit process" msgstr "" #: ../compliance/understanding-the-audit-process.rst:5 msgid "" "Information system security compliance is reliant on the completion of two " "foundational processes:" msgstr "" #: ../compliance/understanding-the-audit-process.rst:9 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:14 msgid "Implementation and operation of security controls" msgstr "" #: ../compliance/understanding-the-audit-process.rst:17 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:22 msgid "Independent verification and validation" msgstr "" #: ../compliance/understanding-the-audit-process.rst:25 msgid "Determining audit scope" msgstr "" #: ../compliance/understanding-the-audit-process.rst:27 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:31 msgid "" "When scoping OpenStack deployments for compliance purposes, prioritize " "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:36 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:44 msgid "" "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:" msgstr "" #: ../compliance/understanding-the-audit-process.rst:51 msgid "" "The `Cloud Security Alliance Cloud Controls Matrix <https://" "cloudsecurityalliance.org/group/cloud-controls-matrix/>`_ (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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:58 msgid "" "The `SCAP Security Guide <https://github.com/OpenSCAP/scap-security-guide/" ">`_ 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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:66 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:72 msgid "Phases of an audit" msgstr "" #: ../compliance/understanding-the-audit-process.rst:74 msgid "" "An audit has four distinct phases, though most stakeholders and control " "owners will only participate in one or two. The four phases are Planning, " "Fieldwork, Reporting and Wrap-up. Each of these phases is discussed below." msgstr "" #: ../compliance/understanding-the-audit-process.rst:78 msgid "" "The Planning phase is typically performed two weeks to six months before " "Fieldwork begins. In this phase audit items such as the timeframe, timeline, " "controls to be evaluated, and control owners are discussed and finalized. " "Concerns about resource availability, impartiality, and costs are also " "resolved." msgstr "" #: ../compliance/understanding-the-audit-process.rst:84 msgid "" "The Fieldwork phase is the most visible portion of the audit. This is where " "the auditors are onsite, interviewing the control owners, documenting the " "controls that are in place, and identifying any issues. It is important to " "note that the auditors will use a two part process for evaluating the " "controls in place. The first part is evaluating the design effectiveness of " "the control. This is where the auditor will evaluate whether the control is " "capable of effectively preventing or detecting and correcting weaknesses and " "deficiencies. A control must pass this test to be evaluated in the second " "phase. This is because with a control that is designed ineffectually, there " "is no point considering whether it is operating effectively. The second part " "is operational effectiveness. Operational effectiveness testing will " "determine how the control was applied, the consistency with which the " "control was applied and by whom or by what means the control was applied. A " "control may depend upon other controls (indirect controls) and, if they do, " "additional evidence that demonstrates the operating effectiveness of those " "indirect controls may be required for the auditor to determine the overall " "operating effectiveness of the control." msgstr "" #: ../compliance/understanding-the-audit-process.rst:102 msgid "" "The Reporting phase is where any issues that were identified during the " "Fieldwork phase will be validated by management. For logistics purposes, " "some activities such as issue validation may be performed during the " "Fieldwork phase. Management will also need to provide remediation plans to " "address the issues and ensure that they do not reoccur. A draft of the " "overall report will be circulated for review to the stakeholders and " "management. Agreed upon changes are incorporated and the updated draft is " "sent to senior management for review and approval. Once senior management " "approves the report, it is finalized and distributed to executive " "management. Any issues are entered into the issue tracking or risk tracking " "mechanism the organization uses." msgstr "" #: ../compliance/understanding-the-audit-process.rst:114 msgid "" "The Wrap-up phase is where the audit is officially spun down. Management " "will begin remediation activities at this point. Processes and notifications " "are used to ensure that any audit related information is moved to a secure " "repository." msgstr "" #: ../compliance/understanding-the-audit-process.rst:121 msgid "Internal audit" msgstr "" #: ../compliance/understanding-the-audit-process.rst:123 msgid "" "Once a cloud is deployed, it is time for an internal audit. This is the time " "to 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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:129 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:135 msgid "Prepare for external audit" msgstr "" #: ../compliance/understanding-the-audit-process.rst:137 msgid "" "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:" msgstr "" #: ../compliance/understanding-the-audit-process.rst:141 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:146 msgid "" "Deploy automated testing tools to ensure that the cloud remains compliant " "over time." msgstr "" #: ../compliance/understanding-the-audit-process.rst:149 msgid "Select an auditor." msgstr "" #: ../compliance/understanding-the-audit-process.rst:151 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:158 msgid "External audit" msgstr "" #: ../compliance/understanding-the-audit-process.rst:160 msgid "" "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." msgstr "" #: ../compliance/understanding-the-audit-process.rst:171 msgid "Compliance maintenance" msgstr "" #: ../compliance/understanding-the-audit-process.rst:173 msgid "" "The process does not 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 and compliance. Failing on either of " "these fronts will significantly complicate future audits." msgstr "" #: ../compute.rst:3 ../data-processing/deployment.rst:19 #: ../introduction/introduction-to-openstack.rst:112 msgid "Compute" msgstr "" #: ../compute.rst:5 msgid "" "The OpenStack Compute service (nova) runs in many locations throughout the " "cloud and interacts with a variety of internal services. The OpenStack " "Compute service offers a variety of configuration options which may be " "deployment specific." msgstr "" #: ../compute.rst:10 msgid "" "In this chapter we will call out general best practice around Compute " "security as well as specific known configurations that can lead to security " "issues. The ``nova.conf`` file and the ``/var/lib/nova`` locations should be " "secured. Controls like centralized logging, the ``policy.json`` file, and a " "mandatory access control framework should be implemented." msgstr "" #: ../compute/checklist.rst:8 msgid "" "Check-Compute-01: Is user/group ownership of config files set to root/nova?" msgstr "" #: ../compute/checklist.rst:10 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally, modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues causing a " "denial of service to the other end users. User ownership of such critical " "configuration files must be set to ``root`` and group ownership must be set " "to ``nova``. Additionally, the containing directory should have the same " "ownership to ensure that new files are owned correctly." msgstr "" #: ../compute/checklist.rst:29 msgid "" "**Pass:** If user and group ownership of all these config files is set to " "``root`` and ``nova`` respectively. The above commands show output of ``root " "nova``." msgstr "" #: ../compute/checklist.rst:33 msgid "" "**Fail:** If the above commands do not return any output, the user and group " "ownership might have set to any user other than ``root`` or any group other " "than ``nova``." msgstr "" #: ../compute/checklist.rst:37 ../compute/checklist.rst:83 msgid "Recommended in: :doc:`../compute`." msgstr "" #: ../compute/checklist.rst:42 msgid "Check-Compute-02: Are strict permissions set for configuration files?" msgstr "" #: ../compute/checklist.rst:44 msgid "" "Similar to the previous check, we recommend to set strict access permissions " "for such configuration files." msgstr "" #: ../compute/checklist.rst:60 msgid "" "**Pass:** If permissions are set to 640 or stricter, or the containing " "directory is set to 750. The permissions of 640/750 translates into owner r/" "w, group r, and no rights to others. For example, \"u=rw,g=r,o=\"." msgstr "" #: ../compute/checklist.rst:66 msgid "" "If :ref:`check_compute_01` and permissions set to 640, root has read/write " "access and nova has read access to these configuration files. The access " "rights can also be validated using the following command. This command will " "only be available on your system if it supports ACLs." msgstr "" #: ../compute/checklist.rst:81 ../identity/checklist.rst:64 msgid "**Fail:** If permissions are not set to at least 640/750." msgstr "" #: ../compute/checklist.rst:88 msgid "Check-Compute-03: Is keystone used for authentication?" msgstr "" #: ../compute/checklist.rst:95 msgid "" "OpenStack supports various authentication strategies like noauth, and " "keystone. If the noauth strategy is used, then the users could interact with " "OpenStack services without any authentication. This could be a potential " "risk since an attacker might gain unauthorized access to the OpenStack " "components. We strongly recommend that all services must be authenticated " "with keystone using their service accounts." msgstr "" #: ../compute/checklist.rst:102 msgid "Before Ocata:" msgstr "" #: ../compute/checklist.rst:104 msgid "" "**Pass:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section in ``/etc/nova/nova.conf`` is set to ``keystone``." msgstr "" #: ../compute/checklist.rst:107 ../networking/checklist.rst:100 msgid "" "**Fail:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section is set to ``noauth`` or ``noauth2``." msgstr "" #: ../compute/checklist.rst:110 msgid "After Ocata:" msgstr "" #: ../compute/checklist.rst:112 msgid "" "**Pass:** If value of parameter ``auth_strategy`` under ``[api]`` or " "``[DEFAULT]`` section in ``/etc/nova/nova.conf`` is set to ``keystone``." msgstr "" #: ../compute/checklist.rst:115 msgid "" "**Fail:** If value of parameter ``auth_strategy`` under ``[api]`` or " "``[DEFAULT]`` section is set to ``noauth`` or ``noauth2``." msgstr "" #: ../compute/checklist.rst:121 msgid "Check-Compute-04: Is secure protocol used for authentication?" msgstr "" #: ../compute/checklist.rst:123 ../compute/checklist.rst:146 #: ../secrets-management/checklist.rst:105 #: ../shared-file-systems/checklist.rst:108 msgid "" "OpenStack components communicate with each other using various protocols and " "the communication might involve sensitive or confidential data. An attacker " "may try to eavesdrop on the channel in order to get access to sensitive " "information. All the components must communicate with each other using a " "secured communication protocol." msgstr "" #: ../compute/checklist.rst:129 msgid "" "**Pass:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/nova/nova.conf`` is set to " "Identity API endpoint starting with ``https://`` and value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/nova/nova.conf`` is set to ``False``." msgstr "" #: ../compute/checklist.rst:135 msgid "" "**Fail:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/nova/nova.conf`` is not set to " "Identity API endpoint starting with ``https://`` or value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/nova/nova.conf`` is set to ``True``." msgstr "" #: ../compute/checklist.rst:144 msgid "Check-Compute-05: Does Nova communicate with Glance securely?" msgstr "" #: ../compute/checklist.rst:152 msgid "" "**Pass:** If value of parameter ``api_insecure`` under ``[glance]`` section " "in ``/etc/nova/nova.conf`` is set to ``False`` and value of parameter " "``api_servers`` under ``[glance]`` section in ``/etc/nova/nova.conf`` is set " "to a value starting with ``https://``." msgstr "" #: ../compute/checklist.rst:157 msgid "" "**Fail:** If value of parameter ``api_insecure`` under ``[glance]`` section " "in ``/etc/nova/nova.conf`` is set to ``True``, or if value of parameter " "``api_servers`` under ``[glance]`` section in ``/etc/nova/nova.conf`` is set " "to a value that does not start with ``https://``." msgstr "" #: ../compute/hardening-deployments.rst:3 msgid "Hardening Compute deployments" msgstr "" #: ../compute/hardening-deployments.rst:5 msgid "" "One of the main security concerns with any OpenStack deployment is the " "security and controls around sensitive files, such as the ``nova.conf`` " "file. Normally contained in the ``/etc`` directory, this configuration file " "contains many sensitive options including configuration details and service " "passwords. All such sensitive files should be given strict file level " "permissions, and monitored for changes through file integrity monitoring " "(FIM) tools such as iNotify or Samhain. These utilities will take a hash of " "the target file in a known good state, and then periodically take a new hash " "of the file and compare it to the known good hash. An alert can be created " "if it was found to have been modified unexpectedly." msgstr "" #: ../compute/hardening-deployments.rst:16 msgid "" "The permissions of a file can be examined my moving into the directory the " "file is contained in and running the :command:`ls -lh` command. This will " "show the permissions, owner, and group that have access to the file, as well " "as other information such as the last time the file was modified and when it " "was created." msgstr "" #: ../compute/hardening-deployments.rst:22 msgid "" "The ``/var/lib/nova`` directory is used to hold details about the instances " "on a given compute host. This directory should be considered sensitive as " "well, with strictly enforced file permissions. Additionally, it should be " "backed up regularly as it contains information and metadata for the " "instances associated with that host." msgstr "" #: ../compute/hardening-deployments.rst:28 msgid "" "If your deployment does not require full virtual machine backups, we " "recommend excluding the ``/var/lib/nova/instances`` directory as it will be " "as large as the combined space of each vm running on that node. If your " "deployment does require full VM backups, you will need to ensure this " "directory is backed up successfully." msgstr "" #: ../compute/hardening-deployments.rst:34 msgid "" "Monitoring is a critical component of IT infrastructure, we recommend the " "`Compute logfiles <https://docs.openstack.org/newton/config-reference/" "compute/logs.html>`_ be monitored and analyzed so that meaningful alerts can " "be created." msgstr "" #: ../compute/hardening-deployments.rst:41 #: ../compute/vulnerability-awareness.rst:6 msgid "OpenStack vulnerability management team" msgstr "" #: ../compute/hardening-deployments.rst:43 msgid "" "We recommend keeping up to date on security issues and advisories as they " "are published. The `OpenStack Security Portal <https://security.openstack." "org>`_ is the central portal where advisories, notices, meetings, and " "processes can be coordinated. Additionally, the `OpenStack Vulnerability " "Management Team (VMT) portal <https://security.openstack.org/#openstack-" "vulnerability-management-team>`_ coordinates remediation within the " "OpenStack project, as well as the process of investigating reported bugs " "which are responsibly disclosed (privately) to the VMT, by marking the bug " "as 'This bug is a security vulnerability'. Further detail is outlined in the " "`VMT process page <https://security.openstack.org/vmt-process." "html#process>`_ and results in an OpenStack Security Advisory (OSSA). This " "OSSA outlines the issue and the fix, as well as linking to both the original " "bug, and the location where the where the patch is hosted." msgstr "" #: ../compute/hardening-deployments.rst:59 #: ../compute/vulnerability-awareness.rst:24 msgid "OpenStack security notes" msgstr "" #: ../compute/hardening-deployments.rst:61 msgid "" "Reported security bugs that are found to be the result of a " "misconfiguration, or are not strictly part of OpenStack are drafted into " "OpenStack Security Notes (OSSNs). These include configuration issues such as " "ensuring Identity provider mappings as well as non-OpenStack but critical " "issues such as the Bashbug/Ghost or Venom vulnerabilities that affect the " "platform OpenStack utilizes. The current set of OSSNs is in the `Security " "Note wiki <https://wiki.openstack.org/wiki/Security_Notes>`_." msgstr "" #: ../compute/hardening-deployments.rst:71 msgid "OpenStack-dev mailinglist" msgstr "" #: ../compute/hardening-deployments.rst:73 msgid "" "All bugs, OSSAs and OSSNs are publicly disseminated through the openstack-" "discuss mailinglist with the [security] topic in the subject line. We " "recommend subscribing to this list as well as mail filtering rules that " "ensure OSSNs, OSSAs, and other important advisories are not missed. The " "openstack-discuss mailinglist is managed through `OpenStack Development " "Mailing List <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-" "discuss>`_. The openstack-discuss uses tags as defined in the `Project Team " "Guide <https://docs.openstack.org/project-team-guide/open-community." "html#mailing-lists>`_." msgstr "" #: ../compute/hardening-deployments.rst:85 #: ../compute/vulnerability-awareness.rst:48 msgid "Hypervisor mailinglists" msgstr "" #: ../compute/hardening-deployments.rst:87 #: ../compute/vulnerability-awareness.rst:50 msgid "" "When implementing OpenStack, one of the core decisions is which hypervisor " "to utilize. We recommend being informed of advisories pertaining to the " "hypervisor(s) you have chosen. Several common hypervisor security lists are " "below:" msgstr "" #: ../compute/hardening-deployments.rst:92 #: ../compute/hardening-the-virtualization-layers.rst:36 #: ../compute/vulnerability-awareness.rst:55 msgid "Xen:" msgstr "" #: ../compute/hardening-deployments.rst:93 #: ../compute/vulnerability-awareness.rst:56 msgid "`http://xenbits.xen.org/xsa/ <http://xenbits.xen.org/xsa/>`_" msgstr "" #: ../compute/hardening-deployments.rst:94 #: ../compute/vulnerability-awareness.rst:57 msgid "VMWare:" msgstr "" #: ../compute/hardening-deployments.rst:95 #: ../compute/vulnerability-awareness.rst:58 msgid "" "`http://blogs.vmware.com/security/ <http://blogs.vmware.com/security/>`_" msgstr "" #: ../compute/hardening-deployments.rst:96 #: ../compute/vulnerability-awareness.rst:59 msgid "Others (KVM, and more):" msgstr "" #: ../compute/hardening-deployments.rst:97 #: ../compute/vulnerability-awareness.rst:60 msgid "`http://seclists.org/oss-sec <http://seclists.org/oss-sec>`_" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:3 msgid "Hardening the virtualization layers" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:5 msgid "" "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. Then we discuss how the Secure " "Encrypted Virtualization technology can be used to encrypt the memory of VMs " "on AMD-based machines which support the technology. We conclude the chapter " "with a discussion of sVirt, an open source project for integrating SELinux " "mandatory access controls with the virtualization components." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:14 msgid "Physical hardware (PCI passthrough)" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:16 msgid "" "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 or GPUs " "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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:23 msgid "" "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. We recommend cloud architects should " "ensure that the hypervisor is configured to utilize this hardware feature." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:33 msgid "KVM:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:33 msgid "" "`How to assign devices with VT-d in KVM <http://www.linux-kvm.org/page/" "How_to_assign_devices_with_VT-d_in_KVM>`_" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:36 msgid "`Xen VTd Howto <http://wiki.xen.org/wiki/VTd_HowTo>`_" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:40 msgid "The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:42 msgid "" "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 the host OS, the malicious code can spread into those " "systems. The end result is that one instance can run code outside of its " "security domain. This is a significant breach as it is harder to reset the " "state of physical hardware than virtual hardware, and can lead to additional " "exposure such as access to the management network." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:50 msgid "" "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. 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 :ref:`management-secure-bootstrapping`, is 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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:61 msgid "" "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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:67 msgid "Virtual hardware (QEMU)" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:69 msgid "" "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 :term:`QEMU <Quick " "EMUlator (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. 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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:83 msgid "" "It is important to take proactive steps to harden QEMU. We recommend three " "specific steps:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:86 msgid "Minimizing the code base." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:87 msgid "Using compiler hardening." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:88 msgid "Using mandatory access controls such as sVirt, SELinux, or AppArmor." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:90 msgid "" "Ensure your iptables have the default policy filtering network traffic, and " "consider examining the existing rule set to understand each rule and " "determine if the policy needs to be expanded upon." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:95 msgid "Minimizing the QEMU code base" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:97 msgid "" "We recommend minimizing the QEMU code base by removing unused components " "from the system. QEMU provides support for many different virtual hardware " "devices, however only a small number of devices are needed for a given " "instance. The most common hardware devices are the virtio devices. Some " "legacy instances will need access to specific hardware, which can be " "specified using glance metadata:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:112 msgid "" "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` from within the QEMU source directory. Decide " "what is needed for your deployment, and disable the remaining options." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:120 msgid "Compiler hardening" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:122 msgid "" "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 include relocation read-only (RELRO), stack " "canaries, never execute (NX), position independent executable (PIE), and " "address space layout randomization (ASLR)." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:128 msgid "" "Many modern Linux distributions already build QEMU with compiler hardening " "enabled, we recommend verifying your existing executable before proceeding. " "One tool that can assist you with this verification is called `checksec.sh " "<http://www.trapkit.de/tools/checksec.html>`_" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:135 msgid "" "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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:138 msgid "RELocation Read-Only (RELRO)" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:141 msgid "" "Places values on the stack and verifies their presence to help prevent " "buffer overflow attacks." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:141 msgid "Stack canaries" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:144 msgid "" "Also known as Data Execution Prevention (DEP), ensures that data sections of " "the executable can not be executed." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:144 msgid "Never eXecute (NX)" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:146 msgid "Position Independent Executable (PIE)" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:147 msgid "" "Produces a position independent executable, which is necessary for ASLR." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:149 msgid "" "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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:151 msgid "Address Space Layout Randomization (ASLR)" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:153 msgid "" "The following compiler options are recommend for GCC when compiling QEMU:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:161 msgid "" "We recommend testing your QEMU executable file after it is compiled to " "ensure that the compiler hardening worked properly." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:164 msgid "" "Most cloud deployments will not 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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:170 msgid "DEB packages:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:171 msgid "`Hardening Walkthrough <https://wiki.debian.org/HardeningWalkthrough>`_" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:173 msgid "" "`How to create an RPM package <http://fedoraproject.org/wiki/" "How_to_create_an_RPM_package>`_" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:174 msgid "RPM packages:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:177 msgid "Secure Encrypted Virtualization" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:179 msgid "" "`Secure Encrypted Virtualization (SEV) <https://developer.amd.com/sev/>`_ is " "a technology from AMD which enables the memory for a VM to be encrypted with " "a key unique to the VM. SEV is available in the Train release as a technical " "preview with KVM guests on certain AMD-based machines for the purpose of " "evaluating the technology." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:185 msgid "" "The `KVM hypervisor section of the nova configuration guide <https://docs." "openstack.org/nova/latest/admin/configuration/hypervisor-kvm.html#amd-sev-" "secure-encrypted-virtualization>`_ contains information needed to configure " "the machine and hypervisor, and lists several limitations of SEV." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:190 msgid "" "SEV provides protection for data in the memory used by the running VM. " "However, while the first phase of SEV integration with OpenStack enables " "encrypted memory for VMs, importantly it does not provide the " "``LAUNCH_MEASURE`` or ``LAUNCH_SECRET`` capabilities which are available " "with the SEV firmware. This means that data used by an SEV-protected VM may " "be subject to attacks from a motivated adversary who has control of the " "hypervisor. For example, a rogue administrator on the hypervisor machine " "could provide a VM image for tenants with a backdoor and spyware capable of " "stealing secrets, or replace the VNC server process to snoop data sent to or " "from the VM console including passwords which unlock full disk encryption " "solutions." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:201 msgid "" "To reduce the chances for a rogue administrator to gain unauthorized access " "to data, the following security practices should accompany the use of SEV:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:204 msgid "A full disk encryption solution should be used by the VM." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:206 msgid "A bootloader password should be used on the VM." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:208 msgid "" "In addition, standard security best practices should be used with the VM " "including the following:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:211 msgid "" "The VM should be well maintained, including regular security scanning and " "patching to ensure a continuously strong security posture for the VM." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:214 msgid "" "Connections to the VM should use encrypted and authenticated protocols such " "as HTTPS and SSH." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:217 msgid "" "Additional security tools and processes should be considered and used for " "the VM appropriate to the level of sensitivity of the data." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:223 msgid "" "Compiler hardening makes it more difficult to attack the QEMU process. " "However, if an attacker does succeed, you want 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 " "by using sVirt, SELinux, or AppArmor. When using sVirt, SELinux is " "configured to run each QEMU process under a separate security context. " "AppArmor can be configured to provide similar functionality. We provide more " "details on sVirt and instance isolation in the section below :ref:`hardening-" "the-virtualization-layers-svirt-selinux-and-virtualization`." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:233 msgid "" "Specific SELinux policies are available for many OpenStack services. CentOS " "users can review these policies by `installing the selinux-policy source " "package`_. The most up to date policies appear in `Fedora's selinux-policy`_ " "repository. The `rawhide-contrib`_ branch has files that end in ``.te``, " "such as ``cinder.te``, that can be used on systems running SELinux." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:239 msgid "" "AppArmor profiles for OpenStack services do not currently exist, but the " "OpenStack-Ansible project handles this by `applying AppArmor profiles to " "each container`_ that runs an OpenStack service." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:251 msgid "sVirt: SELinux and virtualization" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:253 msgid "" "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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:262 msgid "" "OpenStack's sVirt implementation aspires to protect hypervisor hosts and " "virtual machines against two primary threat vectors:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:266 msgid "" "A compromised application running within a virtual machine attacks the " "hypervisor to access underlying resources. For example, when a virtual " "machine is able to access the hypervisor OS, physical devices, or other " "applications. This threat vector represents considerable risk as a " "compromise on a hypervisor can infect the physical hardware as well as " "exposing other virtual machines and network segments." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:270 msgid "Hypervisor threats" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:273 msgid "" "A compromised application running within a VM attacks the hypervisor to " "access or 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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:279 msgid "Virtual Machine (multi-tenant) threats" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:281 msgid "" "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." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:290 msgid "" "sVirt isolation is provided regardless of the guest operating system running " "inside the virtual machine. Linux or Windows VMs can be used. Additionally, " "many Linux distributions provide SELinux within the operating system, " "allowing the virtual machine to protect internal virtual resources from " "threats." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:297 msgid "Labels and categories" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:299 msgid "" "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:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:312 msgid "" "The ``svirt_image_t`` label uniquely identifies image files on disk, " "allowing for the SELinux policy to restrict access. When a KVM-based compute " "image is powered on, sVirt appends a random numerical identifier to the " "image. sVirt is capable of assigning numeric identifiers to a maximum of " "524,288 virtual machines per hypervisor node, however most OpenStack " "deployments are highly unlikely to encounter this limitation." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:319 msgid "This example shows the sVirt category identifier:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:327 msgid "SELinux users and roles" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:329 msgid "" "SELinux manages user roles. These can be viewed through the ``-Z`` flag, or " "with the :command:`semanage` command. On the hypervisor, only administrators " "should be able to access the system, and should have an appropriate context " "around both the administrative users and any other users that are on the " "system. For more information, see the `SELinux users documentation <http://" "selinuxproject.org/page/BasicConcepts#Users>`_." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:337 msgid "Booleans" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:339 msgid "" "To ease the administrative burden of managing SELinux, many enterprise Linux " "platforms utilize SELinux Booleans to quickly change the security posture of " "sVirt." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:343 msgid "" "Red Hat Enterprise Linux-based KVM deployments utilize the following sVirt " "booleans:" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:350 msgid "sVirt SELinux Boolean" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:351 #: ../compute/hypervisor-selection.rst:326 #: ../security-review/architecture-page-guidance.rst:191 #: ../shared-file-systems/network-and-security-models.rst:44 #: ../shared-file-systems/security-services.rst:57 msgid "Description" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:352 msgid "virt_use_common" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:353 msgid "Allow virt to use serial or parallel communication ports." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:354 msgid "virt_use_fusefs" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:355 msgid "Allow virt to read FUSE mounted files." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:356 msgid "virt_use_nfs" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:357 msgid "Allow virt to manage NFS mounted files." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:358 msgid "virt_use_samba" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:359 msgid "Allow virt to manage CIFS mounted files." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:360 msgid "virt_use_sanlock" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:361 msgid "Allow confined virtual guests to interact with the sanlock." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:362 msgid "virt_use_sysfs" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:363 msgid "Allow virt to manage device configuration (PCI)." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:364 msgid "virt_use_usb" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:365 msgid "Allow virt to use USB devices." msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:366 msgid "virt_use_xserver" msgstr "" #: ../compute/hardening-the-virtualization-layers.rst:367 msgid "Allow virtual machine to interact with the X Window System." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:3 msgid "How to select virtual consoles" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:5 msgid "" "One decision a cloud architect will need to make regarding Compute service " "configuration is whether to use :term:`VNC <Virtual Network Computing " "(VNC)>` or :term:`SPICE <Simple Protocol for Independent Computing " "Environments (SPICE)>`." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:11 msgid "Virtual Network Computer (VNC)" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:13 msgid "" "OpenStack can be configured to provide remote desktop console access to " "instances for tenants and administrators using the Virtual Network Computer " "(VNC) protocol." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:18 #: ../compute/how-to-select-virtual-consoles.rst:59 #: ../management/management-interfaces.rst:31 #: ../management/management-interfaces.rst:91 msgid "Capabilities" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:20 msgid "" "The OpenStack Dashboard (horizon) can provide a VNC console for instances " "directly on the web page using the HTML5 noVNC client. This requires the " "``nova-novncproxy`` service to bridge from the public network to the " "management network." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:24 msgid "" "The ``nova`` command-line utility can return a URL for the VNC console for " "access by the nova Java VNC client. This requires the ``nova-xvpvncproxy`` " "service to bridge from the public network to the management network." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:29 #: ../compute/how-to-select-virtual-consoles.rst:76 #: ../management/management-interfaces.rst:54 #: ../management/management-interfaces.rst:102 #: ../management/management-interfaces.rst:157 #: ../management/management-interfaces.rst:184 msgid "Security considerations" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:31 msgid "" "The ``nova-novncproxy`` and ``nova-xvpvncproxy`` services by default open " "public-facing ports that are token authenticated." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:33 msgid "" "By default, the remote desktop traffic is not encrypted. TLS can be enabled " "to encrypt the VNC traffic. Refer to :doc:`../secure-communication/" "introduction-to-ssl-and-tls` for appropriate recommendations." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:39 #: ../compute/how-to-select-virtual-consoles.rst:86 #: ../compute/hypervisor-selection.rst:473 #: ../data-processing/configuration-and-hardening.rst:205 #: ../management/management-interfaces.rst:77 #: ../management/management-interfaces.rst:166 #: ../management/management-interfaces.rst:209 #: ../monitoring-logging/forensics-and-incident-response.rst:87 msgid "Bibliography" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:41 msgid "" "blog.malchuk.ru, OpenStack VNC Security. 2013. `Secure Connections to VNC " "ports <http://blog.malchuk.ru/2013/05/21/47>`_" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:43 msgid "" "OpenStack Mailing List, [OpenStack] nova-novnc SSL configuration - Havana. " "2014. `OpenStack nova-novnc SSL Configuration <http://lists.openstack.org/" "pipermail/openstack/2014-February/005357.html>`_" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:47 msgid "" "Redhat.com/solutions, Using SSL Encryption with OpenStack nova-novacproxy. " "2014. `OpenStack nova-novncproxy SSL encryption <https://access.redhat.com/" "solutions/514143>`_" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:52 msgid "Simple Protocol for Independent Computing Environments (SPICE)" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:54 msgid "" "As an alternative to VNC, OpenStack provides remote desktop access to guest " "virtual machines using the Simple Protocol for Independent Computing " "Environments (SPICE) protocol." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:61 msgid "" "SPICE is supported by the OpenStack Dashboard (horizon) directly on the " "instance web page. This requires the ``nova-spicehtml5proxy`` service." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:63 msgid "" "The nova command-line utility can return a URL for SPICE console for access " "by a SPICE-html client." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:67 msgid "Limitations" msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:69 msgid "" "Although SPICE has many advantages over VNC, the spice-html5 browser " "integration currently does not allow administrators to take advantage of the " "benefits. To take advantage of SPICE features like multi-monitor, USB pass " "through, we recommend administrators use a standalone SPICE client within " "the management network." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:78 msgid "" "The ``nova-spicehtml5proxy`` service by default opens public-facing ports " "that are token authenticated." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:80 msgid "" "The functionality and integration are still evolving. We will access the " "features in the next release and make recommendations." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:82 msgid "" "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." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:88 msgid "" "OpenStack Admin Guide. SPICE Console. `SPICE Console <https://docs.openstack." "org/admin-guide/compute-remote-console-access.html>`_." msgstr "" #: ../compute/how-to-select-virtual-consoles.rst:90 msgid "" "bugzilla.redhat.com, Bug 913607 - RFE: Support Tunnelling SPICE over " "websockets. 2013. `RedHat bug 913607 <https://bugzilla.redhat.com/show_bug." "cgi?id=913607>`_." msgstr "" #: ../compute/hypervisor-selection.rst:3 msgid "Hypervisor selection" msgstr "" #: ../compute/hypervisor-selection.rst:6 msgid "Hypervisors in OpenStack" msgstr "" #: ../compute/hypervisor-selection.rst:8 msgid "" "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 :" "term:`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." msgstr "" #: ../compute/hypervisor-selection.rst:20 msgid "" "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, \"*Guide " "to Security for Full Virtualization Technologies*\"." msgstr "" #: ../compute/hypervisor-selection.rst:30 msgid "Selection criteria" msgstr "" #: ../compute/hypervisor-selection.rst:32 msgid "" "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:" msgstr "" #: ../compute/hypervisor-selection.rst:36 #: ../compute/hypervisor-selection.rst:51 #: ../introduction/selecting-supporting-software.rst:13 #: ../introduction/selecting-supporting-software.rst:19 msgid "Team expertise" msgstr "" #: ../compute/hypervisor-selection.rst:37 #: ../compute/hypervisor-selection.rst:62 #: ../introduction/selecting-supporting-software.rst:14 #: ../introduction/selecting-supporting-software.rst:28 msgid "Product or project maturity" msgstr "" #: ../compute/hypervisor-selection.rst:38 #: ../compute/hypervisor-selection.rst:100 msgid "Common criteria" msgstr "" #: ../compute/hypervisor-selection.rst:39 #: ../compute/hypervisor-selection.rst:91 msgid "Certifications and attestations" msgstr "" #: ../compute/hypervisor-selection.rst:40 #: ../compute/hypervisor-selection.rst:311 #: ../introduction/selecting-supporting-software.rst:16 #: ../introduction/selecting-supporting-software.rst:48 msgid "Hardware concerns" msgstr "" #: ../compute/hypervisor-selection.rst:41 msgid "Hypervisor vs. baremetal" msgstr "" #: ../compute/hypervisor-selection.rst:42 #: ../compute/hypervisor-selection.rst:418 msgid "Additional security features" msgstr "" #: ../compute/hypervisor-selection.rst:44 msgid "" "Additionally, the following security-related criteria are highly encouraged " "to be evaluated when selecting a hypervisor for OpenStack deployments: * Has " "the hypervisor undergone Common Criteria certification? If so, to what " "levels? * Is the underlying cryptography certified by a third-party?" msgstr "" #: ../compute/hypervisor-selection.rst:53 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:64 msgid "" "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:" msgstr "" #: ../compute/hypervisor-selection.rst:68 #: ../introduction/selecting-supporting-software.rst:34 msgid "Availability of expertise" msgstr "" #: ../compute/hypervisor-selection.rst:69 #: ../introduction/selecting-supporting-software.rst:35 msgid "Active developer and user communities" msgstr "" #: ../compute/hypervisor-selection.rst:70 #: ../introduction/selecting-supporting-software.rst:36 msgid "Timeliness and availability of updates" msgstr "" #: ../compute/hypervisor-selection.rst:71 #: ../introduction/selecting-supporting-software.rst:37 msgid "Incidence response" msgstr "" #: ../compute/hypervisor-selection.rst:73 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:80 msgid "" "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 `OpenStack Hypervisor " "Support Matrix <https://wiki.openstack.org/wiki/HypervisorSupportMatrix>`_ " "for OpenStack compute feature support by hypervisor." msgstr "" #: ../compute/hypervisor-selection.rst:93 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:102 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:110 msgid "" "OpenStack has not undergone Common Criteria certification, however many of " "the available hypervisors have." msgstr "" #: ../compute/hypervisor-selection.rst:113 msgid "" "In addition to validating a technologies capabilities, the Common Criteria " "process evaluates how technologies are developed." msgstr "" #: ../compute/hypervisor-selection.rst:116 msgid "How is source code management performed?" msgstr "" #: ../compute/hypervisor-selection.rst:117 msgid "How are users granted access to build systems?" msgstr "" #: ../compute/hypervisor-selection.rst:118 msgid "Is the technology cryptographically signed before distribution?" msgstr "" #: ../compute/hypervisor-selection.rst:120 msgid "" "The KVM hypervisor has been Common Criteria certified through the U.S. " "Government and commercial distributions. These 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...:" msgstr "" #: ../compute/hypervisor-selection.rst:136 msgid "" "While many hypervisor vendors, such as Red Hat, Microsoft, and VMware have " "achieved Common Criteria Certification their underlying certified feature " "set differs, we recommend evaluating vendor claims to ensure they minimally " "satisfy the following requirements:" msgstr "" #: ../compute/hypervisor-selection.rst:145 msgid "Identification and Authentication" msgstr "" #: ../compute/hypervisor-selection.rst:146 msgid "" "Identification and authentication using pluggable authentication modules " "(PAM) based upon user passwords. The quality of the passwords used can be " "enforced through configuration options." msgstr "" #: ../compute/hypervisor-selection.rst:149 msgid "Audit" msgstr "" #: ../compute/hypervisor-selection.rst:150 msgid "" "The system provides the capability to audit a large number of events, " "including individual system calls and 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. 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. Audit records can be transferred to a remote " "audit daemon." msgstr "" #: ../compute/hypervisor-selection.rst:159 msgid "Discretionary Access Control" msgstr "" #: ../compute/hypervisor-selection.rst:160 msgid "" ":term:`Discretionary Access Control (DAC)` restricts access to file system " "objects based on :term:`ACL <access control list (ACL)>` that include the " "standard UNIX permissions for user, groups, and others. Access control " "mechanisms also protect IPC objects from unauthorized access. 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." msgstr "" #: ../compute/hypervisor-selection.rst:168 msgid "Mandatory Access Control" msgstr "" #: ../compute/hypervisor-selection.rst:169 msgid "" "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 :term:`Bell-LaPadula model`. 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. The TOE implements non-hierarchical " "categories to control access to virtual machines." msgstr "" #: ../compute/hypervisor-selection.rst:180 msgid "Role-Based Access Control" msgstr "" #: ../compute/hypervisor-selection.rst:181 msgid "" "Role-based access control (RBAC) allows separation of roles to eliminate the " "need for an all-powerful system administrator." msgstr "" #: ../compute/hypervisor-selection.rst:183 msgid "Object Reuse" msgstr "" #: ../compute/hypervisor-selection.rst:184 msgid "" "File system objects, memory, and IPC objects are cleared before they can be " "reused by a process belonging to a different user." msgstr "" #: ../compute/hypervisor-selection.rst:186 msgid "Security Management" msgstr "" #: ../compute/hypervisor-selection.rst:187 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:193 msgid "Secure Communication" msgstr "" #: ../compute/hypervisor-selection.rst:194 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:198 msgid "Storage Encryption" msgstr "" #: ../compute/hypervisor-selection.rst:199 msgid "" "The system supports encrypted block devices to provide storage " "confidentiality via ``dm_crypt``." msgstr "" #: ../compute/hypervisor-selection.rst:201 msgid "TSF Protection" msgstr "" #: ../compute/hypervisor-selection.rst:202 msgid "" "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. 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. 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. " "In addition, mechanisms for protection against stack overflow attacks are " "provided." msgstr "" #: ../compute/hypervisor-selection.rst:220 msgid "Cryptography standards" msgstr "" #: ../compute/hypervisor-selection.rst:222 msgid "" "Several cryptography algorithms are available within OpenStack for " "identification and authorization, data transfer and protection of data at " "rest. When selecting a hypervisor, we recommend the following algorithms and " "implementation standards:" msgstr "" #: ../compute/hypervisor-selection.rst:231 msgid "Algorithm" msgstr "" #: ../compute/hypervisor-selection.rst:232 msgid "Key length" msgstr "" #: ../compute/hypervisor-selection.rst:233 msgid "Intended purpose" msgstr "" #: ../compute/hypervisor-selection.rst:234 msgid "Security function" msgstr "" #: ../compute/hypervisor-selection.rst:235 msgid "Implementation standard" msgstr "" #: ../compute/hypervisor-selection.rst:236 msgid "AES" msgstr "" #: ../compute/hypervisor-selection.rst:237 #: ../compute/hypervisor-selection.rst:259 msgid "128, 192, or 256 bits" msgstr "" #: ../compute/hypervisor-selection.rst:238 #: ../compute/hypervisor-selection.rst:243 #: ../compute/hypervisor-selection.rst:260 #: ../compute/hypervisor-selection.rst:266 msgid "Encryption / decryption" msgstr "" #: ../compute/hypervisor-selection.rst:239 msgid "Protected data transfer, protection for data at rest" msgstr "" #: ../compute/hypervisor-selection.rst:240 #: ../compute/hypervisor-selection.rst:245 msgid "`RFC 4253 <http://www.ietf.org/rfc/rfc4253.txt>`_" msgstr "" #: ../compute/hypervisor-selection.rst:241 msgid "TDES" msgstr "" #: ../compute/hypervisor-selection.rst:242 msgid "168 bits" msgstr "" #: ../compute/hypervisor-selection.rst:244 msgid "Protected data transfer" msgstr "" #: ../compute/hypervisor-selection.rst:246 msgid "RSA" msgstr "" #: ../compute/hypervisor-selection.rst:247 msgid "1024, 2048, or 3072 bits" msgstr "" #: ../compute/hypervisor-selection.rst:248 #: ../compute/hypervisor-selection.rst:254 msgid "Authentication, key exchange" msgstr "" #: ../compute/hypervisor-selection.rst:249 #: ../compute/hypervisor-selection.rst:255 msgid "Identification and authentication, protected data transfer" msgstr "" #: ../compute/hypervisor-selection.rst:250 #: ../compute/hypervisor-selection.rst:256 msgid "" "`U.S. NIST FIPS PUB 186-3 <http://csrc.nist.gov/publications/fips/fips186-3/" "fips_186-3.pdf>`_" msgstr "" #: ../compute/hypervisor-selection.rst:252 msgid "DSA" msgstr "" #: ../compute/hypervisor-selection.rst:253 msgid "L=1024, N=160 bits" msgstr "" #: ../compute/hypervisor-selection.rst:258 msgid "Serpent" msgstr "" #: ../compute/hypervisor-selection.rst:261 #: ../compute/hypervisor-selection.rst:267 msgid "Protection of data at rest" msgstr "" #: ../compute/hypervisor-selection.rst:262 msgid "" "`http://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf <http://www.cl.cam.ac.uk/" "~rja14/Papers/serpent.pdf>`_" msgstr "" #: ../compute/hypervisor-selection.rst:264 msgid "Twofish" msgstr "" #: ../compute/hypervisor-selection.rst:265 msgid "128, 192, or 256 bit" msgstr "" #: ../compute/hypervisor-selection.rst:268 msgid "" "`https://www.schneier.com/paper-twofish-paper.html <https://www.schneier.com/" "paper-twofish-paper.html>`_" msgstr "" #: ../compute/hypervisor-selection.rst:270 msgid "SHA-1" msgstr "" #: ../compute/hypervisor-selection.rst:272 #: ../compute/hypervisor-selection.rst:278 msgid "Message Digest" msgstr "" #: ../compute/hypervisor-selection.rst:273 msgid "Protection of data at rest, protected data transfer" msgstr "" #: ../compute/hypervisor-selection.rst:274 #: ../compute/hypervisor-selection.rst:280 msgid "" "`U.S. NIST FIPS PUB 180-3 <http://csrc.nist.gov/publications/fips/fips180-3/" "fips180-3_final.pdf>`_" msgstr "" #: ../compute/hypervisor-selection.rst:276 msgid "SHA-2 (224, 256, 384, or 512 bits)" msgstr "" #: ../compute/hypervisor-selection.rst:279 msgid "Protection for data at rest, identification and authentication" msgstr "" #: ../compute/hypervisor-selection.rst:284 msgid "FIPS 140-2" msgstr "" #: ../compute/hypervisor-selection.rst:286 msgid "" "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...:" msgstr "" #: ../compute/hypervisor-selection.rst:300 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:313 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:327 msgid "Technology" msgstr "" #: ../compute/hypervisor-selection.rst:328 msgid "Explanation" msgstr "" #: ../compute/hypervisor-selection.rst:329 msgid "I/O MMU" msgstr "" #: ../compute/hypervisor-selection.rst:330 msgid "VT-d / AMD-Vi" msgstr "" #: ../compute/hypervisor-selection.rst:331 msgid "Required for protecting PCI-passthrough" msgstr "" #: ../compute/hypervisor-selection.rst:332 msgid "Intel Trusted Execution Technology" msgstr "" #: ../compute/hypervisor-selection.rst:333 msgid "Intel TXT / SEM" msgstr "" #: ../compute/hypervisor-selection.rst:334 msgid "Required for dynamic attestation services" msgstr "" #: ../compute/hypervisor-selection.rst:335 msgid "PCI-SIG I/O virtualization" msgstr "" #: ../compute/hypervisor-selection.rst:336 msgid "SR-IOV, MR-IOV, ATS" msgstr "" #: ../compute/hypervisor-selection.rst:337 msgid "Required to allow secure sharing of PCI Express devices" msgstr "" #: ../compute/hypervisor-selection.rst:338 msgid "Network virtualization" msgstr "" #: ../compute/hypervisor-selection.rst:339 msgid "VT-c" msgstr "" #: ../compute/hypervisor-selection.rst:340 msgid "Improves performance of network I/O on hypervisors" msgstr "" #: ../compute/hypervisor-selection.rst:344 msgid "Hypervisor versus bare metal" msgstr "" #: ../compute/hypervisor-selection.rst:346 msgid "" "It is important to recognize the difference between using Linux Containers " "(LXC) or bare metal systems versus 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." msgstr "" #: ../compute/hypervisor-selection.rst:353 msgid "" "Ensure 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." msgstr "" #: ../compute/hypervisor-selection.rst:360 msgid "" "While OpenStack has a bare metal project, a discussion of the particular " "security implications of running bare metal is beyond the scope of this book." msgstr "" #: ../compute/hypervisor-selection.rst:363 msgid "" "Due to the time constraints around a book sprint, the team chose to use KVM " "as the hypervisor in our example implementations and architectures." msgstr "" #: ../compute/hypervisor-selection.rst:368 msgid "" "There is an OpenStack Security Note pertaining to the `Use of LXC in Compute " "<https://bugs.launchpad.net/ossn/+bug/1098582>`_." msgstr "" #: ../compute/hypervisor-selection.rst:373 msgid "Hypervisor memory optimization" msgstr "" #: ../compute/hypervisor-selection.rst:375 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:381 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:388 msgid "KVM Kernel Samepage Merging" msgstr "" #: ../compute/hypervisor-selection.rst:390 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:396 msgid "XEN transparent page sharing" msgstr "" #: ../compute/hypervisor-selection.rst:398 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:404 msgid "Security considerations for memory optimization" msgstr "" #: ../compute/hypervisor-selection.rst:406 msgid "" "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, 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." msgstr "" #: ../compute/hypervisor-selection.rst:413 msgid "" "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." msgstr "" #: ../compute/hypervisor-selection.rst:420 msgid "" "Another thing to look into when selecting a hypervisor platform is the " "availability of specific security features. In particular, features. For " "example, Xen Server's XSM or Xen Security Modules, sVirt, Intel TXT, or " "AppArmor." msgstr "" #: ../compute/hypervisor-selection.rst:425 msgid "" "The following table calls out these features by common hypervisor platforms." msgstr "" #: ../compute/hypervisor-selection.rst:431 msgid "XSM" msgstr "" #: ../compute/hypervisor-selection.rst:432 msgid "sVirt" msgstr "" #: ../compute/hypervisor-selection.rst:433 msgid "TXT" msgstr "" #: ../compute/hypervisor-selection.rst:434 msgid "AppArmor" msgstr "" #: ../compute/hypervisor-selection.rst:435 msgid "cgroups" msgstr "" #: ../compute/hypervisor-selection.rst:436 msgid "MAC Policy" msgstr "" #: ../compute/hypervisor-selection.rst:437 msgid "KVM" msgstr "" #: ../compute/hypervisor-selection.rst:439 #: ../compute/hypervisor-selection.rst:440 #: ../compute/hypervisor-selection.rst:441 #: ../compute/hypervisor-selection.rst:442 #: ../compute/hypervisor-selection.rst:443 #: ../compute/hypervisor-selection.rst:445 #: ../compute/hypervisor-selection.rst:447 #: ../compute/hypervisor-selection.rst:454 msgid "X" msgstr "" #: ../compute/hypervisor-selection.rst:444 msgid "Xen" msgstr "" #: ../compute/hypervisor-selection.rst:451 msgid "ESXi" msgstr "" #: ../compute/hypervisor-selection.rst:458 msgid "Hyper-V" msgstr "" #: ../compute/hypervisor-selection.rst:468 msgid "" "Features in this table might not be applicable to all hypervisors or " "directly mappable between hypervisors." msgstr "" #: ../compute/hypervisor-selection.rst:475 msgid "" "Sunar, Eisenbarth, Inci, Gorka Irazoqui Apecechea. Fine Grain Cross-VM " "Attacks on Xen and VMware are possible!. 2014. `https://eprint.iacr." "org/2014/248.pfd <https://eprint.iacr.org/2014/248.pdf>`_" msgstr "" #: ../compute/hypervisor-selection.rst:479 msgid "" "Artho, Yagi, Iijima, Kuniyasu Suzaki. Memory Deduplication as a Threat to " "the Guest OS. 2011. `https://staff.aist.go.jp/c.artho/papers/EuroSec2011-" "suzaki.pdf <https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf>`_" msgstr "" #: ../compute/hypervisor-selection.rst:483 msgid "" "KVM: Kernel-based Virtual Machine. Kernel Samepage Merging. 2010. `http://" "www.linux-kvm.org/page/KSM <http://www.linux-kvm.org/page/KSM>`_" msgstr "" #: ../compute/hypervisor-selection.rst:485 msgid "" "Xen Project, Xen Security Modules: XSM-FLASK. 2014. `http://wiki.xen.org/" "wiki/Xen_Security_Modules_:_XSM-FLASK <http://wiki.xen.org/wiki/" "Xen_Security_Modules_:_XSM-FLASK>`_" msgstr "" #: ../compute/hypervisor-selection.rst:488 msgid "" "SELinux Project, SVirt. 2011. `http://selinuxproject.org/page/SVirt <http://" "selinuxproject.org/page/SVirt>`_" msgstr "" #: ../compute/hypervisor-selection.rst:491 msgid "" "Intel.com, Trusted Compute Pools with Intel Trusted Execution Technology " "(Intel TXT). `http://www.intel.com/txt <http://www.intel.com/txt>`_" msgstr "" #: ../compute/hypervisor-selection.rst:494 msgid "" "AppArmor.net, AppArmor Main Page. 2011. `http://wiki.apparmor.net/index.php/" "Main_Page <http://wiki.apparmor.net/index.php/Main_Page>`_" msgstr "" #: ../compute/hypervisor-selection.rst:497 msgid "" "Kernel.org, CGroups. 2004. `https://www.kernel.org/doc/Documentation/cgroup-" "v1/cgroups.txt <https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups." "txt>`_" msgstr "" #: ../compute/hypervisor-selection.rst:500 msgid "" "Computer Security Resource Centre. Guide to Security for Full Virtualization " "Technologies. 2011. `http://csrc.nist.gov/publications/nistpubs/800-125/" "SP800-125-final.pdf <http://csrc.nist.gov/publications/nistpubs/800-125/" "SP800-125-final.pdf>`_" msgstr "" #: ../compute/hypervisor-selection.rst:504 msgid "" "National Information Assurance Partnership, National Security " "Telecommunications and Information Systems Security Policy. 2003. `http://" "www.niap-ccevs.org/cc-scheme/nstissp_11_revised_factsheet.pdf <http://www." "niap-ccevs.org/cc-scheme/nstissp_11_revised_factsheet.pdf>`_" msgstr "" #: ../compute/vulnerability-awareness.rst:3 msgid "Vulnerability awareness" msgstr "" #: ../compute/vulnerability-awareness.rst:8 msgid "" "We recommend keeping up to date on security issues and advisories as they " "are published. The `OpenStack Security Portal <https://security.openstack." "org/>`_ is the central portal where advisories, notices, meetings, and " "processes can be coordinated. Additionally, the `OpenStack Vulnerability " "Management Team (VMT) portal <https://security.openstack.org/#vulnerability-" "management>`_ coordinates remediation within OpenStack, as well as the " "process of investigating reported bugs which are responsibly disclosed " "(privately) to the VMT, by marking the bug as 'This bug is a security " "vulnerability'. Further detail is outlined in the `VMT process page <https://" "security.openstack.org/vmt-process.html#process>`_ and results in an " "OpenStack Security Advisory (OSSA). This OSSA outlines the issue and the " "fix, as well as linking to both the original bug, and the location where the " "where the patch is hosted." msgstr "" #: ../compute/vulnerability-awareness.rst:26 msgid "" "Reported security bugs that are found to be the result of a " "misconfiguration, or are not strictly part of OpenStack, are drafted into " "OpenStack Security Notes (OSSNs). These include configuration issues such as " "ensuring identity provider mappings as well as non-OpenStack, but critical, " "issues such as the Bashbug/Ghost or Venom vulnerabilities that affect the " "platform OpenStack utilizes. The current set of OSSNs is in the `Security " "Note wiki <https://wiki.openstack.org/wiki/Security_Notes>`_." msgstr "" #: ../compute/vulnerability-awareness.rst:35 msgid "OpenStack-discuss mailing list" msgstr "" #: ../compute/vulnerability-awareness.rst:37 msgid "" "All bugs, OSSAs and OSSNs are publicly disseminated through the openstack-" "discuss mailing list with the [security] topic in the subject line. We " "recommend subscribing to this list as well as mail filtering rules that " "ensure OSSNs, OSSAs, and other important advisories are not missed. The " "openstack-discuss mailinglist is managed through `http://lists.openstack.org/" "cgi-bin/mailman/listinfo/openstack-discuss <http://lists.openstack.org/cgi-" "bin/mailman/listinfo/openstack-discuss>`_. The openstack-discuss uses tags " "as defined in the `Project Team Guide <https://docs.openstack.org/project-" "team-guide/open-community.html#mailing-lists>`_." msgstr "" #: ../dashboard.rst:3 #: ../documentation/system-documentation-requirements.rst:132 #: ../introduction/introduction-to-openstack.rst:189 #: ../management/management-interfaces.rst:23 #: ../secure-communication/introduction-to-ssl-and-tls.rst:196 msgid "Dashboard" msgstr "" #: ../dashboard.rst:5 msgid "" "The Dashboard (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 virtual machine (VM) images, managing networks, setting " "up security groups, starting instances, and accessing the instances through " "a console." msgstr "" #: ../dashboard.rst:11 msgid "" "The Dashboard is based on the Django web framework, ensuring secure " "deployment practices for Django apply directly to horizon. This guide " "provides a set of Django security recommendations. Further information can " "be found by reading the `Django documentation <https://docs.djangoproject." "com/>`_." msgstr "" #: ../dashboard.rst:16 msgid "" "The Dashboard ships with default security settings, and has `deployment and " "configuration documentation <https://docs.openstack.org/horizon/latest/user/" "index.html>`_." msgstr "" #: ../dashboard/checklist.rst:8 msgid "Check-Dashboard-01: Is user/group of config files set to root/horizon?" msgstr "" #: ../dashboard/checklist.rst:10 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues causing a " "denial of service to the other end users. Thus user ownership of such " "critical configuration files must be set to root and group ownership must be " "set to horizon." msgstr "" #: ../dashboard/checklist.rst:24 msgid "" "**Pass:** If user and group ownership of the config file is set to root and " "horizon respectively. The above commands show output of root horizon." msgstr "" #: ../dashboard/checklist.rst:27 msgid "" "**Fail:** If the above commands does not return any output as the user and " "group ownership might have set to any user other than root or any group " "other than horizon." msgstr "" #: ../dashboard/checklist.rst:34 msgid "" "Check-Dashboard-02: Are strict permissions set for horizon configuration " "files?" msgstr "" #: ../dashboard/checklist.rst:36 ../identity/checklist.rst:41 #: ../networking/checklist.rst:42 ../shared-file-systems/checklist.rst:43 msgid "" "Similar to the previous check, it is recommended to set strict access " "permissions for such configuration files." msgstr "" #: ../dashboard/checklist.rst:45 msgid "" "**Pass:** If permissions are set to 640 or stricter. The permissions of 640 " "translates into owner r/w, group r, and no rights to others i.e. \"u=rw,g=r," "o=\". Note that with :ref:`check_dashboard_01` and permissions set to 640, " "root has read/write access and horizon has read access to these " "configuration files. The access rights can also be validated using the " "following command. This command will only be available on your system if it " "supports ACLs." msgstr "" #: ../dashboard/checklist.rst:67 msgid "" "Check-Dashboard-03: Is ``DISALLOW_IFRAME_EMBED`` parameter set to ``True``?" msgstr "" #: ../dashboard/checklist.rst:69 msgid "" "``DISALLOW_IFRAME_EMBED`` can be used to prevent the OpenStack Dashboard " "from being embedded within an iframe." msgstr "" #: ../dashboard/checklist.rst:72 msgid "" "Legacy browsers are still vulnerable to a Cross-Frame Scripting (XFS) " "vulnerability, so this option allows extra security hardening where iframes " "are not used in deployment." msgstr "" #: ../dashboard/checklist.rst:76 msgid "Default setting is True." msgstr "" #: ../dashboard/checklist.rst:78 msgid "" "**Pass:** If value of parameter ``DISALLOW_IFRAME_EMBED`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``True``." msgstr "" #: ../dashboard/checklist.rst:81 msgid "" "**Fail:** If value of parameter ``DISALLOW_IFRAME_EMBED`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``False``." msgstr "" #: ../dashboard/checklist.rst:84 msgid "Recommended in: :doc:`https-hsts-xss-ssrf`." msgstr "" #: ../dashboard/checklist.rst:89 msgid "" "Check-Dashboard-04: Is ``CSRF_COOKIE_SECURE`` parameter set to ``True``?" msgstr "" #: ../dashboard/checklist.rst:91 msgid "" "CSRF (Cross-site request forgery) is an attack which forces an end user to " "execute unauthorized commands on a web application in which he/she is " "currently authenticated. A successful CSRF exploit can compromise end user " "data and operations. If the targeted end user has admin privileges, this can " "compromise the entire web application." msgstr "" #: ../dashboard/checklist.rst:97 msgid "" "**Pass:** If value of parameter ``CSRF_COOKIE_SECURE`` in ``/etc/openstack-" "dashboard/local_settings.py`` is set to ``True``." msgstr "" #: ../dashboard/checklist.rst:100 msgid "" "**Fail:** If value of parameter ``CSRF_COOKIE_SECURE`` in ``/etc/openstack-" "dashboard/local_settings.py`` is set to ``False``." msgstr "" #: ../dashboard/checklist.rst:103 ../dashboard/checklist.rst:122 #: ../dashboard/checklist.rst:141 msgid "Recommended in: :doc:`cookies`." msgstr "" #: ../dashboard/checklist.rst:108 msgid "" "Check-Dashboard-05: Is ``SESSION_COOKIE_SECURE`` parameter set to ``True``?" msgstr "" #: ../dashboard/checklist.rst:110 msgid "" "The \"SECURE\" cookie attribute instructs web browsers to only send the " "cookie through an encrypted HTTPS (SSL/TLS) connection. This session " "protection mechanism is mandatory to prevent the disclosure of the session " "ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker " "cannot simply capture the session ID from web browser traffic." msgstr "" #: ../dashboard/checklist.rst:116 msgid "" "**Pass:** If value of parameter ``SESSION_COOKIE_SECURE`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``True``." msgstr "" #: ../dashboard/checklist.rst:119 msgid "" "**Fail:** If value of parameter ``SESSION_COOKIE_SECURE`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``False``." msgstr "" #: ../dashboard/checklist.rst:128 msgid "" "Check-Dashboard-06: Is ``SESSION_COOKIE_HTTPONLY`` parameter set to ``True``?" msgstr "" #: ../dashboard/checklist.rst:130 msgid "" "The \"HTTPONLY\" cookie attribute instructs web browsers not to allow " "scripts (e.g. JavaScript or VBscript) an ability to access the cookies via " "the DOM ``document.cookie`` object. This session ID protection is mandatory " "to prevent session ID stealing through XSS attacks." msgstr "" #: ../dashboard/checklist.rst:135 msgid "" "**Pass:** If value of parameter ``SESSION_COOKIE_HTTPONLY`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``True``." msgstr "" #: ../dashboard/checklist.rst:138 msgid "" "**Fail:** If value of parameter ``SESSION_COOKIE_HTTPONLY`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``False``." msgstr "" #: ../dashboard/checklist.rst:146 msgid "Check-Dashboard-07: Is ``PASSWORD_AUTOCOMPLETE`` set to ``False``?" msgstr "" #: ../dashboard/checklist.rst:148 msgid "" "Common feature that applications use to provide users a convenience is to " "cache the password locally in the browser (on the client machine) and having " "it 'pre-typed' in all subsequent requests. While this feature can be " "perceived as extremely friendly for the average user, at the same time, it " "introduces a flaw, as the user account becomes easily accessible to anyone " "that uses the same account on the client machine and thus may lead to " "compromise of the user account." msgstr "" #: ../dashboard/checklist.rst:156 msgid "" "**Pass:** If value of parameter ``PASSWORD_AUTOCOMPLETE`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``off``." msgstr "" #: ../dashboard/checklist.rst:159 msgid "" "**Fail:** If value of parameter ``PASSWORD_AUTOCOMPLETE`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``on``." msgstr "" #: ../dashboard/checklist.rst:165 msgid "Check-Dashboard-08: Is ``DISABLE_PASSWORD_REVEAL`` set to ``True``?" msgstr "" #: ../dashboard/checklist.rst:167 msgid "" "Similar to the previous check, it is recommended not to reveal password " "fields." msgstr "" #: ../dashboard/checklist.rst:169 msgid "" "**Pass:** If value of parameter ``DISABLE_PASSWORD_REVEAL`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``True``." msgstr "" #: ../dashboard/checklist.rst:172 msgid "" "**Fail:** If value of parameter ``DISABLE_PASSWORD_REVEAL`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``False``." msgstr "" #: ../dashboard/checklist.rst:177 msgid "This option was introduced in Kilo release." msgstr "" #: ../dashboard/checklist.rst:182 msgid "Check-Dashboard-09: Is ``ENFORCE_PASSWORD_CHECK`` set to ``True``?" msgstr "" #: ../dashboard/checklist.rst:184 msgid "" "Setting ``ENFORCE_PASSWORD_CHECK`` to True will display an 'Admin Password' " "field on the Change Password form to verify that it is indeed the admin " "logged-in who wants to change the password." msgstr "" #: ../dashboard/checklist.rst:188 msgid "" "**Pass:** If value of parameter ``ENFORCE_PASSWORD_CHECK`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``True``." msgstr "" #: ../dashboard/checklist.rst:191 msgid "" "**Fail:** If value of parameter ``ENFORCE_PASSWORD_CHECK`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to ``False``." msgstr "" #: ../dashboard/checklist.rst:197 msgid "Check-Dashboard-10: Is ``PASSWORD_VALIDATOR`` configured?" msgstr "" #: ../dashboard/checklist.rst:199 msgid "Allows a regular expression to validate user password complexity." msgstr "" #: ../dashboard/checklist.rst:201 msgid "" "**Pass:** If value of parameter ``PASSWORD_VALIDATOR`` in ``/etc/openstack-" "dashboard/local_settings.py`` is set to any value outside of the defaul " "allow all `\"regex\": '.*',`" msgstr "" #: ../dashboard/checklist.rst:205 msgid "" "**Fail:** If value of parameter ``PASSWORD_VALIDATOR`` in ``/etc/openstack-" "dashboard/local_settings.py`` is set to allow all `\"regex\": '.*'`" msgstr "" #: ../dashboard/checklist.rst:212 msgid "Check-Dashboard-11: Is ``SECURE_PROXY_SSL_HEADER`` configured?" msgstr "" #: ../dashboard/checklist.rst:214 msgid "" "If the OpenStack Dashboard is deployed behind a proxy and the proxy strips " "``X-Forwarded-Proto`` header from all incoming requests, or sets the ``X-" "Forwarded-Proto`` header and sends it to the Dashboard, but only for " "requests that originally come in via HTTPS, then you should consider " "configuring ``SECURE_PROXY_SSL_HEADER``" msgstr "" #: ../dashboard/checklist.rst:220 msgid "" "Futher information can be found in the `Django documentation <https://docs." "djangoproject.com/en/1.8/ref/settings/#secure-proxy-ssl-header/>`_." msgstr "" #: ../dashboard/checklist.rst:222 msgid "" "**Pass:** If value of parameter ``SECURE_PROXY_SSL_HEADER`` in ``/etc/" "openstack-dashboard/local_settings.py`` is set to " "``'HTTP_X_FORWARDED_PROTO', 'https'``" msgstr "" #: ../dashboard/checklist.rst:226 msgid "" "**Fail:** If value of parameter ``SECURE_PROXY_SSL_HEADER`` in ``/etc/" "openstack-dashboard/local_settings.py`` is not set to " "``'HTTP_X_FORWARDED_PROTO', 'https'`` or commented out." msgstr "" #: ../dashboard/cookies.rst:3 msgid "Cookies" msgstr "" #: ../dashboard/cookies.rst:5 msgid "Session cookies should be set to HTTPONLY:" msgstr "" #: ../dashboard/cookies.rst:11 msgid "" "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:" msgstr "" #: ../dashboard/cross-origin-resource-sharing-cors.rst:3 msgid "Cross Origin Resource Sharing (CORS)" msgstr "" #: ../dashboard/cross-origin-resource-sharing-cors.rst:5 msgid "" "Configure your web server to send a restrictive CORS header with each " "response, allowing only the dashboard domain and protocol:" msgstr "" #: ../dashboard/cross-origin-resource-sharing-cors.rst:13 msgid "Never allow the wild card origin." msgstr "" #: ../dashboard/debug.rst:3 msgid "Debug" msgstr "" #: ../dashboard/debug.rst:5 msgid "" "We recommend that the ``DEBUG`` setting is set to ``False`` in production " "environments. If ``DEBUG`` is set to True, Django will display stack traces " "and sensitive web server state information when exceptions are thrown." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:3 msgid "Domain names, dashboard upgrades, and basic web server configuration" msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:6 msgid "Domain names" msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:8 msgid "" "Many organizations typically deploy web applications at subdomains of an " "overarching organization domain. It is natural for users to expect a domain " "of the form ``openstack.example.org``. In this context, there are often " "applications which are deployed in the same second-level namespace. This " "name structure is convenient and simplifies name server maintenance." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:16 msgid "" "We strongly recommend deploying dashboard to a *second-level domain*, such " "as ``https://example.com``, rather than deploying dashboard on a *shared " "subdomain* of any level, for example ``https://openstack.example.org`` or " "``https://horizon.openstack.example.org``. We also advise against deploying " "to bare internal domains like ``https://horizon/``. These recommendations " "are based on the limitations of browser same-origin-policy." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:26 msgid "" "Recommendations given in this guide cannot effectively guard against known " "attacks if you deploy the dashboard in a domain that also hosts user-" "generated content, even when this content resides on a separate sub-domain. " "User-generated content can consist of scripts, images, or uploads of any " "type. Most major web presences, including googleusercontent.com, fbcdn.com, " "github.io, and twimg.co, use this approach to segregate user-generated " "content from cookies and security tokens." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:34 msgid "" "If you do not follow this recommendation regarding second-level domains, " "avoid a cookie-backed session store and employ HTTP Strict Transport " "Security (HSTS). When deployed on a subdomain, the dashboard's security is " "equivalent to the least secure application deployed on the same second-level " "domain." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:41 msgid "Basic web server configuration" msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:43 msgid "" "The dashboard should be deployed as a Web Services Gateway Interface (WSGI) " "application behind an HTTPS proxy such as Apache or :term:`Nginx`. If Apache " "is not already in use, we recommend :term:`Nginx` since it is lightweight " "and easier to configure correctly." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:49 msgid "" "When using :term:`Nginx`, we recommend `gunicorn <http://docs.gunicorn.org/" "en/latest/deploy.html>`_ as the WSGI host with an appropriate number of " "synchronous workers. When using Apache, we recommend ``mod_wsgi`` to host " "the dashboard." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:56 msgid "Allowed hosts" msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:58 msgid "" "Configure the ``ALLOWED_HOSTS`` setting with the fully qualified host " "name(s) that are served by the OpenStack dashboard. Once this setting is " "provided, if the value in the \"Host:\" header of an incoming HTTP request " "does not match any of the values in this list an error will be raised and " "the requestor will not be able to proceed. Failing to configure this option, " "or the use of wild card characters in the specified host names, will cause " "the dashboard to be vulnerable to security breaches associated with fake " "HTTP Host headers." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:66 #: ../dashboard/front-end-caching-session-back-end.rst:59 msgid "" "For further details, see the `Django documentation <https://docs." "djangoproject.com/>`_." msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:70 msgid "Horizon image upload" msgstr "" #: ../dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst:72 msgid "" "We recommend that implementers `disable HORIZON_IMAGES_ALLOW_UPLOAD <https://" "docs.openstack.org/horizon/latest/user/manage-images.html#upload-an-image>`_ " "unless they have implemented a plan to prevent resource exhaustion and " "denial of service." msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:3 msgid "Front-end caching and session back end" msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:6 msgid "Front-end caching" msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:8 msgid "" "We do not recommend using front-end caching tools with the dashboard. The " "dashboard is rendering dynamic content resulting directly from OpenStack API " "requests and front-end caching layers such as varnish can prevent the " "correct content from being displayed. In Django, static media is directly " "served from Apache or :term:`Nginx` and already benefits from web host " "caching." msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:16 msgid "Session back end" msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:18 msgid "" "The default session back end for horizon ``django.contrib.sessions.backends." "signed_cookies`` saves user data in signed, but unencrypted cookies stored " "in the browser. Due to the fact that each dashboard instance is stateless, " "the previously mentioned methodology provides the ability to implement the " "most simple session back-end scaling." msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:25 msgid "" "It should be noted that with this type of implementation sensitive access " "tokens will be stored in the browser and will be transmitted with each " "request made. The back end ensures the integrity of session data, even " "though the transmitted data is only encrypted by HTTPS." msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:31 msgid "" "If your architecture allows for shared storage and and if you have " "configured your cache correctly, we recommend setting your " "``SESSION_ENGINE`` to ``django.contrib.sessions.backends.cache`` and using " "it as cache-based session backend with memcached as the cache. Memcached is " "an efficient in-memory key-value store for chunks of data that can be used " "in a high availability and distributed environment and is easy to configure. " "However, you need to ensure that there is no data leakage. Memcached makes " "use of spare RAM to store frequently accessed data blocks, acting like " "memory cache for repeatedly accessed information. Since memcached utilizes " "local memory, there is no overhead of database and file system usage leading " "to direct access of data from RAM rather than from disk." msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:45 msgid "" "We recommend the use of memcached instead of local-memory cache because it " "is fast, retains data for a longer duration, is multi-process safe and has " "the ability to share cache over multiple servers, but still treats it as a " "single cache." msgstr "" #: ../dashboard/front-end-caching-session-back-end.rst:50 msgid "To enable memcached, execute the following:" msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:3 msgid "HTTPS, HSTS, XSS, and SSRF" msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:6 msgid "Cross Site Scripting (XSS)" msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:8 msgid "" "Unlike many similar systems, the 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)." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:13 msgid "" "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." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:22 msgid "Cross Site Request Forgery (CSRF)" msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:24 msgid "" "Django has dedicated middleware for cross-site request forgery (CSRF). For " "further details, see the `Django documentation <https://docs.djangoproject." "com/>`_." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:28 msgid "" "The OpenStack dashboard is designed to discourage developers from " "introducing cross-site scripting vulnerabilities with custom dashboards as " "threads can be introduced. Dashboards that utilize multiple instances of " "JavaScript should be audited for vulnerabilities such as inappropriate use " "of the ``@csrf_exempt`` decorator. Any dashboard that does not follow these " "recommended security settings should be carefully evaluated before " "restrictions are relaxed." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:38 msgid "Cross-Frame Scripting (XFS)" msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:40 msgid "" "Legacy browsers are still vulnerable to a Cross-Frame Scripting (XFS) " "vulnerability, so the OpenStack dashboard provides an option " "``DISALLOW_IFRAME_EMBED`` that allows extra security hardening where iframes " "are not used in deployment." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:46 msgid "HTTPS" msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:48 msgid "" "Deploy the dashboard behind a secure :term:`HTTPS <Hypertext Transfer " "Protocol Secure (HTTPS)>` 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." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:55 msgid "" "Configure HTTP requests to the dashboard domain to redirect to the fully " "qualified HTTPS URL." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:59 msgid "HTTP Strict Transport Security (HSTS)" msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:61 msgid "It is highly recommended to use HTTP Strict Transport Security (HSTS)." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:66 msgid "" "If you are using an HTTPS proxy in front of your web server, rather than " "using an HTTP server with HTTPS functionality, modify the " "``SECURE_PROXY_SSL_HEADER`` variable. Refer to the `Django documentation " "<https://docs.djangoproject.com/>`_ for information about modifying the " "``SECURE_PROXY_SSL_HEADER`` variable." msgstr "" #: ../dashboard/https-hsts-xss-ssrf.rst:74 msgid "" "See the chapter on :doc:`../secure-communication` for more specific " "recommendations and server configurations for HTTPS configurations, " "including the configuration of HSTS." msgstr "" #: ../dashboard/passwords.rst:3 msgid "Passwords" msgstr "" #: ../dashboard/passwords.rst:5 msgid "" "Password management should be an integral part of your cloud administration " "plan. A definitive tutorial about passwords is beyond the scope of this " "book; however, cloud administrators should refer to the best practices " "recommended in Chapter 4 of NIST Special Publication `Guide to Enterprise " "Password Management <http://csrc.nist.gov/publications/drafts/800-118/draft-" "sp800-118.pdf>`_." msgstr "" #: ../dashboard/passwords.rst:11 msgid "" "Browser-based access to the OpenStack cloud, whether through the dashboard " "or other applications, introduces additional considerations. Modern browsers " "all support some form of password storage and autofilling of credentials for " "remembered sites. This can be useful when using strong passwords that cannot " "be easily remembered or typed, but may cause the browser to become the weak " "link if the physical security of the client is compromised. If the browser's " "password store itself is not protected by a strong password, or if the " "password store is allowed to remain unlocked for the duration of the " "session, unauthorized access to your system can be easily obtained." msgstr "" #: ../dashboard/passwords.rst:21 msgid "" "Password management applications such as `KeePassX <http://www.keepassx." "org>`_ and `Password Safe <http://www.pwsafe.org>`_ can be useful as most " "support the generation of strong passwords and periodic reminders to " "generate new passwords. Most importantly, the password store remains " "unlocked only briefly, which reduces the risk of password exposure and " "unauthorized resource access through browser or system compromise." msgstr "" #: ../dashboard/secret-key.rst:3 msgid "Secret key" msgstr "" #: ../dashboard/secret-key.rst:5 msgid "" "The dashboard depends on a shared ``SECRET_KEY`` setting for some security " "functions. The secret key should be a randomly generated string at least 64 " "characters long, which 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." msgstr "" #: ../dashboard/static-media.rst:3 msgid "Static media" msgstr "" #: ../dashboard/static-media.rst:5 msgid "" "The 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." msgstr "" #: ../dashboard/static-media.rst:11 msgid "" "Django media settings are documented in the `Django documentation <https://" "docs.djangoproject.com/>`_." msgstr "" #: ../dashboard/static-media.rst:14 msgid "" "Dashboard's default configuration uses `django_compressor <http://django-" "compressor.readthedocs.org/>`_ to compress and minify CSS and JavaScript " "content before serving it. This process should be statically done before " "deploying the 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, Node.js) should " "not be installed on production machines." msgstr "" #: ../data-processing.rst:3 msgid "Data processing" msgstr "" #: ../data-processing.rst:5 msgid "" "The Data Processing service (sahara) provides a platform for the " "provisioning and management of instance clusters using processing frameworks " "such as Hadoop and Spark. Through the OpenStack Dashboard, or REST API, " "users are able to upload and execute framework applications which may access " "data in object storage or external providers. The data processing controller " "uses the Orchestration service (heat) to create clusters of instances which " "may exist as long-running groups that can grow and shrink as requested, or " "as transient groups created for a single workload." msgstr "" #: ../data-processing/configuration-and-hardening.rst:3 msgid "Configuration and hardening" msgstr "" #: ../data-processing/configuration-and-hardening.rst:5 msgid "" "There are several configuration options and deployment strategies that can " "improve security in the Data processing service. The service controller is " "configured through a main configuration file and one or more policy files. " "Installations that are using the data-locality features will also have two " "additional files to specify the physical location of Compute and Object " "Storage nodes." msgstr "" #: ../data-processing/configuration-and-hardening.rst:13 msgid "TLS" msgstr "" #: ../data-processing/configuration-and-hardening.rst:15 msgid "" "The Data processing service controller, like many other OpenStack " "controllers, can be configured to require TLS connections." msgstr "" #: ../data-processing/configuration-and-hardening.rst:18 msgid "" "Pre-Kilo releases will require a TLS proxy as the controller does not allow " "direct TLS connections. Configuring TLS proxies is covered in :doc:`../" "secure-communication/tls-proxies-and-http-services`, and we recommend " "following the advice there to create this type of installation." msgstr "" #: ../data-processing/configuration-and-hardening.rst:24 msgid "" "From the Kilo release onward the data processing controller allows direct " "TLS connections, which we recommend. Enabling this behavior requires some " "small adjustments to the controller configuration file." msgstr "" #: ../data-processing/configuration-and-hardening.rst:28 msgid "**Example. Configuring TLS access to the controller**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:40 msgid "Role-based access control policies" msgstr "" #: ../data-processing/configuration-and-hardening.rst:42 msgid "" "The Data processing service uses a policy file, as described in :doc:`../" "identity/policies`, to configure role-based access control. Using the policy " "file an operator can restrict a group’s access to specific data processing " "functionality." msgstr "" #: ../data-processing/configuration-and-hardening.rst:47 msgid "" "The reasons for doing this will change depending on the organizational " "requirements of the installation. In general, these fine grained controls " "are used in situations where an operator needs to restrict the creation, " "deletion, and retrieval of the Data processing service resources. Operators " "who need to restrict access within a project should be fully aware that " "there will need to be alternative means for users to gain access to the core " "functionality of the service (for example, provisioning clusters)." msgstr "" #: ../data-processing/configuration-and-hardening.rst:56 msgid "**Example. Allow all methods to all users (default policy)**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:64 msgid "**Example. Disallow image registry manipulations to non-admin users**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:78 #: ../networking/services-security-best-practices.rst:49 msgid "Security groups" msgstr "" #: ../data-processing/configuration-and-hardening.rst:80 msgid "" "The Data processing service allows for the association of security groups " "with instances provisioned for its clusters. With no additional " "configuration the service will use the default security group for any " "project that provisions clusters. A different security group may be used if " "requested, or an automated option exists which instructs the service to " "create a security group based on ports specified by the framework being " "accessed." msgstr "" #: ../data-processing/configuration-and-hardening.rst:88 msgid "" "For production environments we recommend controlling the security groups " "manually and creating a set of group rules that are appropriate for the " "installation. In this manner the operator can ensure that the default " "security group will contain all the appropriate rules. For an expanded " "discussion of security groups please see :ref:`networking-security-groups`." msgstr "" #: ../data-processing/configuration-and-hardening.rst:98 msgid "Proxy domains" msgstr "" #: ../data-processing/configuration-and-hardening.rst:100 msgid "" "When using the Object Storage service in conjunction with data processing it " "is necessary to add credentials for the store access. With proxy domains the " "Data processing service can instead use a delegated trust from the Identity " "service to allow store access via a temporary user created in the domain. " "For this delegation mechanism to work the Data processing service must be " "configured to use proxy domains and the operator must configure an identity " "domain for the proxy users." msgstr "" #: ../data-processing/configuration-and-hardening.rst:109 msgid "" "The data processing controller retains temporary storage of the username and " "password provided for object store access. When using proxy domains the " "controller will generate this pair for the proxy user, and the access of " "this user will be limited to that of the identity trust. We recommend using " "proxy domains in any installation where the controller or its database have " "routes to or from public networks." msgstr "" #: ../data-processing/configuration-and-hardening.rst:116 msgid "**Example. Configuring for a proxy domain named “dp_proxyâ€**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:126 msgid "Custom network topologies" msgstr "" #: ../data-processing/configuration-and-hardening.rst:128 msgid "" "The data processing controller can be configured to use proxy commands for " "accessing its cluster instances. In this manner custom network topologies " "can be created for installations which will not use the networks provided " "directly by the Networking service. We recommend using this option for " "installations which require limiting access between the controller and the " "instances." msgstr "" #: ../data-processing/configuration-and-hardening.rst:135 msgid "**Example. Access instances through a specified relay machine**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:142 msgid "**Example. Access instances through a custom network namespace**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:150 msgid "Indirect access" msgstr "" #: ../data-processing/configuration-and-hardening.rst:152 msgid "" "For installations in which the controller will have limited access to all " "the instances of a cluster, due to limits on floating IP addresses or " "security rules, indirect access may be configured. This allows some " "instances to be designated as proxy gateways to the other instances of the " "cluster." msgstr "" #: ../data-processing/configuration-and-hardening.rst:158 msgid "" "This configuration can only be enabled while defining the node group " "templates that will make up the data processing clusters. It is provided as " "a run time option to be enabled during the cluster provisioning process." msgstr "" #: ../data-processing/configuration-and-hardening.rst:164 msgid "Rootwrap" msgstr "" #: ../data-processing/configuration-and-hardening.rst:166 msgid "" "When creating custom topologies for network access it can be necessary to " "allow non-root users the ability to run the proxy commands. For these " "situations the oslo rootwrap package is used to provide a facility for non-" "root users to run privileged commands. This configuration requires the user " "associated with the data processing controller application to be in the " "sudoers list and for the option to be enabled in the configuration file. " "Optionally, an alternative rootwrap command can be provided." msgstr "" #: ../data-processing/configuration-and-hardening.rst:175 msgid "**Example. Enabling rootwrap usage and showing the default command**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:183 msgid "" "For more information on the rootwrap project, please see the official " "documentation: `https://wiki.openstack.org/wiki/Rootwrap <https://wiki." "openstack.org/wiki/Rootwrap>`_" msgstr "" #: ../data-processing/configuration-and-hardening.rst:188 msgid "Logging" msgstr "" #: ../data-processing/configuration-and-hardening.rst:190 msgid "" "Monitoring the output of the service controller is a powerful forensic tool, " "as described more thoroughly in :doc:`../monitoring-logging`. The Data " "processing service controller offers a few options for setting the location " "and level of logging." msgstr "" #: ../data-processing/configuration-and-hardening.rst:195 msgid "" "**Example. Setting the log level higher than warning and specifying an " "output file.**" msgstr "" #: ../data-processing/configuration-and-hardening.rst:207 msgid "" "OpenStack.org, Welcome to Sahara!. 2016. `Sahara project documentation " "<https://docs.openstack.org/sahara/latest/>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:210 msgid "" "The Apache Software Foundation, Welcome to Apache Hadoop!. 2016. `Apache " "Hadoop project <https://hadoop.apache.org>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:213 msgid "" "The Apache Software Foundation, Hadoop in Secure Mode. 2016. `Hadoop secure " "mode docs <https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-" "common/SecureMode.html>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:216 msgid "" "The Apache Software Foundation, HDFS User Guide. 2016. `Hadoop HDFS " "documentation <https://hadoop.apache.org/docs/stable/hadoop-project-dist/" "hadoop-hdfs/HdfsUserGuide.html>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:219 msgid "" "The Apache Software Foundation, Spark. 2016. `Spark project <https://spark." "apache.org>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:222 msgid "" "The Apache Software Foundation, Spark Security. 2016. `Spark security " "documentation <https://spark.apache.org/docs/latest/security.html>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:225 msgid "" "The Apache Software Foundation, Apache Storm. 2016. `Storm project <https://" "storm.apache.org>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:228 msgid "" "The Apache Software Foundation, Apache Zookeeper. 2016. `Zookeeper project " "<https://zookeeper.apache.org>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:231 msgid "" "The Apache Software Foundation, Apache Oozie Workflow Scheduler for Hadoop. " "2016. `Oozie project <https://oozie.apache.org>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:234 msgid "" "The Apache Software Foundation, Apache Hive. 2016. `Hive <https://hive." "apache.org>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:237 msgid "" "The Apache Software Foundation, Welcome to Apache Pig. 2016. `Pig <https://" "pig.apache.org>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:240 msgid "" "The Apache Software Foundation, Cloudera Product Documentation. 2016. " "`Cloudera CDH documentation <https://www.cloudera.com/content/cloudera/en/" "documentation.html#CDH>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:243 msgid "" "Hortonworks, Hortonworks. 2016. `Hortonworks Data Platform documentation " "<http://docs.hortonworks.com>`__" msgstr "" #: ../data-processing/configuration-and-hardening.rst:246 msgid "" "MapR Technologies, Apache Hadoop for the MapR Converged Data Platform. 2016. " "`MapR project <https://www.mapr.com/products/mapr-distribution-including-" "apache-hadoop>`__" msgstr "" #: ../data-processing/deployment.rst:3 msgid "Deployment" msgstr "" #: ../data-processing/deployment.rst:5 msgid "" "The Data processing service is deployed, like many other OpenStack services, " "as an application running on a host connected to the stack. As of the Kilo " "release, it has the ability to be deployed in a distributed manner with " "several redundant controllers. Like other services, it also requires a " "database to store information about its resources. See :doc:`../databases`. " "It is important to note that the Data processing service will need to manage " "several Identity service trusts, communicate directly with the Orchestration " "and Networking services, and potentially create users in a proxy domain. For " "these reasons the controller will need access to the control plane and as " "such we recommend installing it alongside other service controllers." msgstr "" #: ../data-processing/deployment.rst:17 msgid "Data processing interacts directly with several openstack services:" msgstr "" #: ../data-processing/deployment.rst:20 ../identity.rst:3 msgid "Identity" msgstr "" #: ../data-processing/deployment.rst:21 #: ../introduction/introduction-to-openstack.rst:175 ../networking.rst:3 msgid "Networking" msgstr "" #: ../data-processing/deployment.rst:22 #: ../introduction/introduction-to-openstack.rst:136 ../object-storage.rst:3 msgid "Object Storage" msgstr "" #: ../data-processing/deployment.rst:23 msgid "Orchestration" msgstr "" #: ../data-processing/deployment.rst:24 msgid "Block Storage (optional)" msgstr "" #: ../data-processing/deployment.rst:26 msgid "" "We recommend documenting all the data flows and bridging points between " "these services and the data processing controller. See :doc:`../" "documentation`." msgstr "" #: ../data-processing/deployment.rst:30 msgid "" "The Object Storage service is used by the Data processing service to store " "job binaries and data sources. Users wishing to have access to the full Data " "processing service functionality will need an object store in the projects " "they are using." msgstr "" #: ../data-processing/deployment.rst:35 msgid "" "The Networking service plays an important role in the provisioning of " "clusters. Prior to provisioning, the user is expected to provide one or more " "networks for the cluster instances. The action of associating networks is " "similar to the process of assigning networks when launching instances " "through the dashboard. These networks are used by the controller for " "administrative access to the instances and frameworks of its clusters." msgstr "" #: ../data-processing/deployment.rst:43 msgid "" "Also of note is the Identity service. Users of the Data processing service " "will need appropriate roles in their projects to allow the provisioning of " "instances for their clusters. Installations that use the proxy domain " "configuration require special consideration. See :ref:`data-processing-proxy-" "domains`. Specifically, the Data processing service will need the ability to " "create users within the proxy domain." msgstr "" #: ../data-processing/deployment.rst:51 msgid "Controller network access to clusters" msgstr "" #: ../data-processing/deployment.rst:53 msgid "" "One of the primary tasks of the data processing controller is to communicate " "with the instances it spawns. These instances are provisioned and then " "configured depending on the framework being used. The communication between " "the controller and the instances uses :term:`secure shell (SSH)` and HTTP " "protocols." msgstr "" #: ../data-processing/deployment.rst:59 msgid "" "When provisioning clusters each instance will be given an IP address in the " "networks provided by the user. The first network is often referred to as the " "data processing management network and instances can use the fixed IP " "address assigned by the Networking service for this network. The controller " "can also be configured to use floating IP addresses for the instances in " "addition to their fixed address. When communicating with the instances the " "controller will prefer the floating address if enabled." msgstr "" #: ../data-processing/deployment.rst:68 msgid "" "For situations where the fixed and floating IP addresses do not provide the " "functionality required the controller can provide access through two " "alternate methods: custom network topologies and indirect access. The custom " "network topologies feature allows the controller to access the instances " "through a supplied shell command in the configuration file. Indirect access " "is used to specify instances that can be used as proxy gateways by the user " "during cluster provisioning. These options are discussed with examples of " "usage in :doc:`configuration-and-hardening`." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:3 msgid "Introduction to Data processing" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:5 msgid "" "The Data processing service controller will be responsible for creating, " "maintaining, and destroying any instances created for its clusters. The " "controller will use the Networking service to establish network paths " "between itself and the cluster instances. It will also manage the deployment " "and life-cycle of user applications that are to be run on the clusters. The " "instances within a cluster contain the core of a framework's processing " "engine and the Data processing service provides several options for creating " "and managing the connections to these instances." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:15 msgid "" "Data processing resources (clusters, jobs, and data sources) are segregated " "by projects defined within the Identity service. These resources are shared " "within a project and it is important to understand the access needs of those " "who are using the service. Activities within projects (for example launching " "clusters, uploading jobs, etc.) can be restricted further through the use of " "role-based access controls." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:23 msgid "" "In this chapter we discuss how to assess the needs of data processing users " "with respect to their applications, the data that they use, and their " "expected capabilities within a project. We will also demonstrate a number of " "hardening techniques for the service controller and its clusters, and " "provide examples of various controller configurations and user management " "approaches to ensure an adequate level of security and privacy." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:32 msgid "Architecture" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:34 msgid "" "The following diagram presents a conceptual view of how the Data processing " "service fits into the greater OpenStack ecosystem." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:39 msgid "" "The Data processing service makes heavy use of the Compute, Orchestration, " "Image, and Block Storage services during the provisioning of clusters. It " "will also use one or more networks, created by the Networking service, " "provided during cluster creation for administrative access to the instances. " "While users are running framework applications the controller and the " "clusters will be accessing the Object Storage service. Given these service " "usages, we recommend following the instructions outlined in :doc:`../" "documentation` for cataloging all the components of an installation." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:51 msgid "Technologies involved" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:53 msgid "" "The Data Processing service is responsible for the deployment and management " "of several applications. For a complete understanding of the security " "options provided we recommend that operators have a general familiarity with " "these applications. The list of highlighted technologies is broken into two " "sections: first, high priority applications that have a greater impact on " "security, and second, supporting applications with a lower impact." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:61 msgid "Higher impact" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:63 msgid "`Hadoop <https://hadoop.apache.org>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:64 msgid "" "`Hadoop secure mode docs <https://hadoop.apache.org/docs/current/hadoop-" "project-dist/hadoop-common/SecureMode.html>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:65 msgid "" "`HDFS <https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/" "HdfsUserGuide.html>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:66 msgid "`Spark <https://spark.apache.org>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:67 msgid "`Spark Security <https://spark.apache.org/docs/latest/security.html>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:68 msgid "`Storm <https://storm.apache.org>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:69 msgid "`Zookeeper <https://zookeeper.apache.org>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:71 msgid "Lower impact" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:73 msgid "`Oozie <https://oozie.apache.org>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:74 msgid "`Hive <https://hive.apache.org>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:75 msgid "`Pig <https://pig.apache.org>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:77 msgid "" "These technologies comprise the core of the frameworks that are deployed " "with the Data processing service. In addition to these technologies, the " "service also includes bundled frameworks provided by third party vendors. " "These bundled frameworks are built using the same core pieces described " "above plus configurations and applications that the vendors include. For " "more information on the third party framework bundles please see the " "following links:" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:85 msgid "" "`Cloudera CDH <https://www.cloudera.com/content/cloudera/en/documentation." "html#CDH>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:86 msgid "`Hortonworks Data Platform <http://docs.hortonworks.com>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:87 msgid "" "`MapR <https://www.mapr.com/products/mapr-distribution-including-apache-" "hadoop>`_" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:90 msgid "User access to resources" msgstr "" #: ../data-processing/introduction-to-data-processing.rst:92 msgid "" "The resources (clusters, jobs, and data sources) of the Data processing " "service are shared within the scope of a project. Although a single " "controller installation may manage several sets of resources, these " "resources will each be scoped to a single project. Given this constraint we " "recommend that user membership in projects is monitored closely to maintain " "proper segregation of resources." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:99 msgid "" "As the security requirements of organizations deploying this service will " "vary based on their specific needs, we recommend that operators focus on " "data privacy, cluster management, and end-user applications as a starting " "point for evaluating the needs of their users. These decisions will help " "guide the process of configuring user access to the service. For an expanded " "discussion on data privacy see :doc:`../tenant-data`." msgstr "" #: ../data-processing/introduction-to-data-processing.rst:107 msgid "" "The default assumption for a data processing installation is that users will " "have access to all functionality within their projects. In the event that " "more granular control is required the Data processing service provides a " "policy file (as described in :doc:`../identity/policies`). These " "configurations will be highly dependent on the needs of the installing " "organization, and as such there is no general advice on their usage: see :" "ref:`data-processing-rbac-policies` for details." msgstr "" #: ../databases.rst:3 msgid "Databases" msgstr "" #: ../databases.rst:5 msgid "" "The choice of database server is an important consideration in the security " "of an OpenStack deployment. Multiple factors should be considered when " "deciding on a database server, however for the scope of this book only " "security considerations will be discussed. OpenStack supports a variety of " "database types. See the `OpenStack Administrator Guide <https://docs." "openstack.org/admin-guide/>`_ for more information." msgstr "" #: ../databases.rst:13 msgid "The Security Guide currently focuses on PostgreSQL and MySQL." msgstr "" #: ../databases/database-access-control.rst:3 msgid "Database access control" msgstr "" #: ../databases/database-access-control.rst:5 msgid "" "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 back " "end choices." msgstr "" #: ../databases/database-access-control.rst:12 msgid "OpenStack database access model" msgstr "" #: ../databases/database-access-control.rst:14 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:18 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:25 msgid "Granular access control" msgstr "" #: ../databases/database-access-control.rst:27 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:35 #: ../databases/database-access-control.rst:166 msgid "Nova-conductor" msgstr "" #: ../databases/database-access-control.rst:37 msgid "" "The compute nodes are the least trusted of the services in OpenStack because " "they host tenant instances. The ``nova-conductor`` 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." msgstr "" #: ../databases/database-access-control.rst:43 msgid "We strongly recommend:" msgstr "" #: ../databases/database-access-control.rst:45 msgid "All database communications be isolated to a management network" msgstr "" #: ../databases/database-access-control.rst:47 msgid "Securing communications using TLS" msgstr "" #: ../databases/database-access-control.rst:49 msgid "" "Creating unique database user accounts per OpenStack service endpoint " "(illustrated below)" msgstr "" #: ../databases/database-access-control.rst:57 msgid "Database authentication and access control" msgstr "" #: ../databases/database-access-control.rst:59 msgid "" "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 TLS. " "Alternatively, for increased security it is recommended that the database " "accounts be configured using X.509 certificate authentication in addition to " "user names and passwords." msgstr "" #: ../databases/database-access-control.rst:71 msgid "Privileges" msgstr "" #: ../databases/database-access-control.rst:73 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:79 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:84 msgid "Require user accounts to require SSL transport" msgstr "" #: ../databases/database-access-control.rst:87 #: ../databases/database-access-control.rst:133 msgid "Configuration example #1: (MySQL)" msgstr "" #: ../databases/database-access-control.rst:94 #: ../databases/database-access-control.rst:142 msgid "Configuration example #2: (PostgreSQL)" msgstr "" #: ../databases/database-access-control.rst:96 msgid "In the file ``pg_hba.conf``:" msgstr "" #: ../databases/database-access-control.rst:102 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:106 msgid "" "The ``md5`` parameter defines the authentication method as a hashed " "password. We provide a secure authentication example in the section below." msgstr "" #: ../databases/database-access-control.rst:111 #: ../databases/database-access-control.rst:149 msgid "OpenStack service database configuration" msgstr "" #: ../databases/database-access-control.rst:113 msgid "" "If your database server is configured for TLS transport, you will need to " "specify the certificate authority information for use with the initial " "connection string in the SQLAlchemy query." msgstr "" #: ../databases/database-access-control.rst:118 msgid "Example of a ``:sql_connection`` string to MySQL:" msgstr "" #: ../databases/database-access-control.rst:125 msgid "Authentication with X.509 certificates" msgstr "" #: ../databases/database-access-control.rst:127 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:151 msgid "" "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 back end. These parameters specify the " "certificate, private key, and certificate authority information for use with " "the initial connection string." msgstr "" #: ../databases/database-access-control.rst:157 msgid "" "Example of a ``:sql_connection`` string for X.509 certificate authentication " "to MySQL:" msgstr "" #: ../databases/database-access-control.rst:168 msgid "" "OpenStack Compute offers a sub-service called nova-conductor which proxies " "database connections, with the primary purpose of having the nova compute " "nodes interfacing with nova-conductor to meet data persistence needs as " "opposed to directly communicating with the database." msgstr "" #: ../databases/database-access-control.rst:174 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:179 msgid "" "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." msgstr "" #: ../databases/database-access-control.rst:188 msgid "" "Unfortunately, this solution complicates the task of more fine-grained " "access control and the ability to audit data access. Because the nova-" "conductor 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 nova-conductor and " "effectively modifying the database." msgstr "" #: ../databases/database-access-control.rst:195 msgid "" "Note, as nova-conductor 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." msgstr "" #: ../databases/database-access-control.rst:200 msgid "" "To disable the nova-conductor, place the following into your ``nova.conf`` " "file (on your compute hosts):" msgstr "" #: ../databases/database-backend-considerations.rst:3 msgid "Database back end considerations" msgstr "" #: ../databases/database-backend-considerations.rst:5 msgid "" "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." msgstr "" #: ../databases/database-backend-considerations.rst:10 msgid "" "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." msgstr "" #: ../databases/database-backend-considerations.rst:19 msgid "Security references for database back ends" msgstr "" #: ../databases/database-backend-considerations.rst:21 msgid "" "Those deploying MySQL or PostgreSQL are advised to refer to existing " "security guidance. Some references are listed below:" msgstr "" #: ../databases/database-backend-considerations.rst:24 msgid "MySQL:" msgstr "" #: ../databases/database-backend-considerations.rst:26 msgid "" "`OWASP MySQL Hardening <https://www.owasp.org/index.php/" "OWASP_Backend_Security_Project_MySQL_Hardening>`__" msgstr "" #: ../databases/database-backend-considerations.rst:29 msgid "" "`MySQL Pluggable Authentication <http://dev.mysql.com/doc/refman/5.5/en/" "pluggable-authentication.html>`__" msgstr "" #: ../databases/database-backend-considerations.rst:32 msgid "" "`Security in MySQL <https://dev.mysql.com/doc/refman/5.5/en/security.html>`__" msgstr "" #: ../databases/database-backend-considerations.rst:35 msgid "PostgreSQL:" msgstr "" #: ../databases/database-backend-considerations.rst:37 msgid "" "`OWASP PostgreSQL Hardening <https://www.owasp.org/index.php/" "OWASP_Backend_Security_Project_PostgreSQL_Hardening>`__" msgstr "" #: ../databases/database-backend-considerations.rst:40 msgid "" "`Total security in a PostgreSQL database <https://www.ibm.com/developerworks/" "opensource/library/os-postgresecurity>`__" msgstr "" #: ../databases/database-transport-security.rst:3 msgid "Database transport security" msgstr "" #: ../databases/database-transport-security.rst:5 msgid "" "This chapter covers issues related to network communications to and from the " "database server. This includes IP address bindings and encrypting network " "traffic with TLS." msgstr "" #: ../databases/database-transport-security.rst:10 msgid "Database server IP address binding" msgstr "" #: ../databases/database-transport-security.rst:12 msgid "" "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." msgstr "" #: ../databases/database-transport-security.rst:20 msgid "Restricting bind address for MySQL" msgstr "" #: ../databases/database-transport-security.rst:22 #: ../databases/database-transport-security.rst:66 msgid "In ``my.cnf``:" msgstr "" #: ../databases/database-transport-security.rst:31 msgid "Restricting listen address for PostgreSQL" msgstr "" #: ../databases/database-transport-security.rst:33 msgid "In ``postgresql.conf``:" msgstr "" #: ../databases/database-transport-security.rst:40 msgid "Database transport" msgstr "" #: ../databases/database-transport-security.rst:42 msgid "" "In addition to restricting database communications to the management " "network, we also strongly recommend that the cloud administrator configure " "their database back end to require TLS. Using TLS for the database client " "connections protects the communications from tampering and eavesdropping. As " "will be discussed in the next section, using TLS also provides the framework " "for doing database user authentication through X.509 certificates (commonly " "referred to as PKI). Below is guidance on how TLS is typically configured " "for the two popular database back ends MySQL and PostgreSQL." msgstr "" #: ../databases/database-transport-security.rst:54 msgid "" "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 database daemon user to prevent unauthorized access by " "other processes and users on the database server." msgstr "" #: ../databases/database-transport-security.rst:61 msgid "MySQL SSL configuration" msgstr "" #: ../databases/database-transport-security.rst:63 msgid "" "The following lines should be added in the system-wide MySQL configuration " "file:" msgstr "" #: ../databases/database-transport-security.rst:76 #: ../databases/database-transport-security.rst:95 msgid "" "Optionally, if you wish to restrict the set of SSL ciphers used for the " "encrypted connection. See `ciphers <https://www.openssl.org/docs/manmaster/" "man1/ciphers.html>`_ for a list of ciphers and the syntax for specifying the " "cipher string:" msgstr "" #: ../databases/database-transport-security.rst:86 msgid "PostgreSQL SSL configuration" msgstr "" #: ../databases/database-transport-security.rst:88 msgid "" "The following lines should be added in the system-wide PostgreSQL " "configuration file, ``postgresql.conf``." msgstr "" #: ../databases/database-transport-security.rst:104 msgid "" "The server certificate, key, and certificate authority (CA) files should be " "placed in the $PGDATA directory in the following files:" msgstr "" #: ../databases/database-transport-security.rst:107 msgid "``$PGDATA/server.crt`` - Server certificate" msgstr "" #: ../databases/database-transport-security.rst:109 msgid "``$PGDATA/server.key`` - Private key corresponding to ``server.crt``" msgstr "" #: ../databases/database-transport-security.rst:111 msgid "``$PGDATA/root.crt`` - Trusted certificate authorities" msgstr "" #: ../databases/database-transport-security.rst:113 msgid "``$PGDATA/root.crl`` - Certificate revocation list" msgstr "" #: ../documentation.rst:3 msgid "System documentation" msgstr "" #: ../documentation.rst:5 msgid "" "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." msgstr "" #: ../documentation/system-documentation-requirements.rst:3 msgid "System documentation requirements" msgstr "" #: ../documentation/system-documentation-requirements.rst:6 msgid "System roles and types" msgstr "" #: ../documentation/system-documentation-requirements.rst:8 msgid "" "The two broadly defined types of nodes that generally make up an OpenStack " "installation are:" msgstr "" #: ../documentation/system-documentation-requirements.rst:12 msgid "" "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." msgstr "" #: ../documentation/system-documentation-requirements.rst:14 msgid "Infrastructure nodes" msgstr "" #: ../documentation/system-documentation-requirements.rst:17 msgid "Compute, storage, or other resource nodes" msgstr "" #: ../documentation/system-documentation-requirements.rst:17 msgid "Provide storage capacity or virtual machines for your cloud." msgstr "" #: ../documentation/system-documentation-requirements.rst:20 msgid "System inventory" msgstr "" #: ../documentation/system-documentation-requirements.rst:22 msgid "" "Documentation should provide a general description of the OpenStack " "environment and cover all systems used (for example, production, " "development, or test). 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." msgstr "" #: ../documentation/system-documentation-requirements.rst:32 msgid "Hardware inventory" msgstr "" #: ../documentation/system-documentation-requirements.rst:34 msgid "" "Clouds without stringent compliance requirements for written documentation " "might benefit from having a Configuration Management Database (CMDB). 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 such as compute nodes, storage nodes, or network " "devices. A CMDB can assist in identifying assets that exist on the network " "which may have vulnerabilities due to inadequate maintenance, inadequate " "protection, or being displaced and forgotten. An OpenStack provisioning " "system can provide some basic CMDB functions if the underlying hardware " "supports the necessary auto-discovery features." msgstr "" #: ../documentation/system-documentation-requirements.rst:46 msgid "Software inventory" msgstr "" #: ../documentation/system-documentation-requirements.rst:48 msgid "" "As with hardware, all software components within the OpenStack deployment " "should be documented. Examples include:" msgstr "" #: ../documentation/system-documentation-requirements.rst:51 msgid "System databases, such as MySQL or mongoDB" msgstr "" #: ../documentation/system-documentation-requirements.rst:52 msgid "OpenStack software components, such as Identity or Compute" msgstr "" #: ../documentation/system-documentation-requirements.rst:53 msgid "" "Supporting components, such as load-balancers, reverse proxies, DNS, or DHCP " "services" msgstr "" #: ../documentation/system-documentation-requirements.rst:56 msgid "" "An authoritative list of software components may be critical when assessing " "the impact of a compromise or vulnerability in a library, application or " "class of software." msgstr "" #: ../documentation/system-documentation-requirements.rst:61 msgid "Network topology" msgstr "" #: ../documentation/system-documentation-requirements.rst:63 msgid "" "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 might 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." msgstr "" #: ../documentation/system-documentation-requirements.rst:72 msgid "Services, protocols, and ports" msgstr "" #: ../documentation/system-documentation-requirements.rst:74 msgid "" "Knowing information about organizational assets is typically a best " "practice. An assets table can assist with validating security requirements " "and help to maintain standard security components such as firewall " "configuration, service port conflicts, security remediation areas, and " "compliance. Additionally, the table can help to understand the relationship " "between OpenStack components. The table might include:" msgstr "" #: ../documentation/system-documentation-requirements.rst:81 msgid "" "Services, protocols, and ports being utilized in the OpenStack deployment." msgstr "" #: ../documentation/system-documentation-requirements.rst:82 msgid "An overview of all services running within the cloud infrastructure." msgstr "" #: ../documentation/system-documentation-requirements.rst:84 msgid "" "It is highly recommended that OpenStack deployments have information similar " "to this on record. The table can be created from information derived from a " "CMDB or can be constructed manually." msgstr "" #: ../documentation/system-documentation-requirements.rst:88 msgid "A table example is provided below:" msgstr "" #: ../documentation/system-documentation-requirements.rst:94 msgid "Service" msgstr "" #: ../documentation/system-documentation-requirements.rst:95 msgid "Protocols" msgstr "" #: ../documentation/system-documentation-requirements.rst:96 msgid "Ports" msgstr "" #: ../documentation/system-documentation-requirements.rst:97 msgid "Purpose" msgstr "" #: ../documentation/system-documentation-requirements.rst:98 msgid "Used by" msgstr "" #: ../documentation/system-documentation-requirements.rst:99 msgid "Security domains(s)" msgstr "" #: ../documentation/system-documentation-requirements.rst:101 msgid "beam.smp" msgstr "" #: ../documentation/system-documentation-requirements.rst:102 msgid "AMQP" msgstr "" #: ../documentation/system-documentation-requirements.rst:103 msgid "5672/tcp" msgstr "" #: ../documentation/system-documentation-requirements.rst:104 msgid "AMQP message service" msgstr "" #: ../documentation/system-documentation-requirements.rst:105 #: ../messaging.rst:8 msgid "RabbitMQ" msgstr "" #: ../documentation/system-documentation-requirements.rst:106 #: ../documentation/system-documentation-requirements.rst:127 msgid "MGMT" msgstr "" #: ../documentation/system-documentation-requirements.rst:108 msgid "tgtd" msgstr "" #: ../documentation/system-documentation-requirements.rst:109 #: ../documentation/system-documentation-requirements.rst:112 msgid "iSCSI" msgstr "" #: ../documentation/system-documentation-requirements.rst:110 msgid "3260/tcp" msgstr "" #: ../documentation/system-documentation-requirements.rst:111 msgid "iSCSI initiator service" msgstr "" #: ../documentation/system-documentation-requirements.rst:113 msgid "PRIVATE(data network)" msgstr "" #: ../documentation/system-documentation-requirements.rst:115 msgid "sshd" msgstr "" #: ../documentation/system-documentation-requirements.rst:116 msgid "ssh" msgstr "" #: ../documentation/system-documentation-requirements.rst:117 msgid "22/tcp" msgstr "" #: ../documentation/system-documentation-requirements.rst:118 msgid "Allows secure login to nodes and guest VMs" msgstr "" #: ../documentation/system-documentation-requirements.rst:119 #: ../documentation/system-documentation-requirements.rst:126 msgid "Various" msgstr "" #: ../documentation/system-documentation-requirements.rst:120 msgid "MGMT, GUEST, and PUBLIC as configured" msgstr "" #: ../documentation/system-documentation-requirements.rst:122 msgid "mysqld" msgstr "" #: ../documentation/system-documentation-requirements.rst:123 msgid "mysql" msgstr "" #: ../documentation/system-documentation-requirements.rst:124 msgid "3306/tcp" msgstr "" #: ../documentation/system-documentation-requirements.rst:125 msgid "MySQL database service" msgstr "" #: ../documentation/system-documentation-requirements.rst:129 msgid "apache2" msgstr "" #: ../documentation/system-documentation-requirements.rst:130 msgid "http" msgstr "" #: ../documentation/system-documentation-requirements.rst:131 msgid "443/tcp" msgstr "" #: ../documentation/system-documentation-requirements.rst:133 msgid "Tenants" msgstr "" #: ../documentation/system-documentation-requirements.rst:134 msgid "PUBLIC" msgstr "" #: ../documentation/system-documentation-requirements.rst:136 msgid "dnsmasq" msgstr "" #: ../documentation/system-documentation-requirements.rst:137 msgid "dns" msgstr "" #: ../documentation/system-documentation-requirements.rst:138 msgid "53/tcp" msgstr "" #: ../documentation/system-documentation-requirements.rst:139 msgid "DNS services" msgstr "" #: ../documentation/system-documentation-requirements.rst:140 msgid "Guest VMs" msgstr "" #: ../documentation/system-documentation-requirements.rst:141 msgid "GUEST" msgstr "" #: ../identity.rst:5 msgid "" "Identity service (keystone) provides identity, token, catalog, and policy " "services for use specifically by services in the OpenStack family. Identity " "service is organized as a group of internal services exposed on one or many " "endpoints. Many of these services are used in a combined fashion by the " "front end. For example, an authentication call validates user and project " "credentials with the identity service. If successful, it will create and " "return a token with the token service. More information can be found by " "reading the `keystone Developer Documentation <https://docs.openstack.org/" "keystone/latest/index.html>`_." msgstr "" #: ../identity/authentication-methods.rst:3 msgid "Authentication methods" msgstr "" #: ../identity/authentication-methods.rst:8 msgid "Internally implemented authentication methods" msgstr "" #: ../identity/authentication-methods.rst:10 msgid "" "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." msgstr "" #: ../identity/authentication-methods.rst:15 msgid "" "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." msgstr "" #: ../identity/authentication-methods.rst:22 msgid "" "LDAP simplifies integration of Identity authentication into an " "organization's existing directory service and user account management " "processes." msgstr "" #: ../identity/authentication-methods.rst:26 msgid "" "Authentication and authorization policy in OpenStack may be delegated to " "another service. A typical use case is an organization that seeks to deploy " "a private cloud and already has a database of employees and users in an LDAP " "system. Using this as the authentication authority, requests to the Identity " "service are delegated to the LDAP system, which will then authorize or deny " "based on its policies. Upon successful authentication, the Identity service " "then generates a token that is used for access to authorized services." msgstr "" #: ../identity/authentication-methods.rst:35 msgid "" "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 ``/etc/keystone/" "keystone.conf`` file maps LDAP attributes to Identity attributes." msgstr "" #: ../identity/authentication-methods.rst:41 msgid "" "The Identity service **MUST NOT** 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." msgstr "" #: ../identity/authentication-methods.rst:51 msgid "" "There is an `OpenStack Security Note (OSSN) regarding keystone.conf " "permissions <https://bugs.launchpad.net/ossn/+bug/1168252>`__." msgstr "" #: ../identity/authentication-methods.rst:54 msgid "" "There is an `OpenStack Security Note (OSSN) regarding potential DoS attacks " "<https://bugs.launchpad.net/ossn/+bug/1155566>`__." msgstr "" #: ../identity/authentication-methods.rst:58 msgid "External authentication methods" msgstr "" #: ../identity/authentication-methods.rst:60 msgid "" "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." msgstr "" #: ../identity/authentication-methods.rst:68 msgid "These include:" msgstr "" #: ../identity/authentication-methods.rst:71 msgid "" "Requires user passwords to conform to minimum standards for length, " "diversity of characters, expiration, or failed login attempts. In an " "external authentication scenario this would be the password policy on the " "original identity store." msgstr "" #: ../identity/authentication-methods.rst:74 msgid "Password policy enforcement" msgstr "" #: ../identity/authentication-methods.rst:77 msgid "" "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." msgstr "" #: ../identity/authentication-methods.rst:79 ../identity/authentication.rst:55 msgid "Multi-factor authentication" msgstr "" #: ../identity/authentication-methods.rst:82 msgid "" "A mutual authentication network protocol using 'tickets' to secure " "communication between client and server. The Kerberos ticket-granting ticket " "can be used to securely provide tickets for a given service." msgstr "" #: ../identity/authentication-methods.rst:83 #: ../shared-file-systems/security-services.rst:64 msgid "Kerberos" msgstr "" #: ../identity/authentication.rst:3 msgid "Authentication" msgstr "" #: ../identity/authentication.rst:5 msgid "" "Authentication is an integral part of any real world OpenStack deployment " "and so careful thought should be given to this aspect of system design. A " "complete treatment of this topic is beyond the scope of this guide however " "some key topics are presented in the following sections." msgstr "" #: ../identity/authentication.rst:11 msgid "" "At its most basic, authentication is the process of confirming identity - " "that a user is actually who they claim to be. A familiar example is " "providing a username and password when logging in to a system." msgstr "" #: ../identity/authentication.rst:15 msgid "" "The OpenStack Identity service (keystone) supports multiple methods of " "authentication, including user name & password, LDAP, and external " "authentication methods. Upon successful authentication, The Identity service " "provides the user with an authorization token used for subsequent service " "requests." msgstr "" #: ../identity/authentication.rst:21 msgid "" "Transport Layer Security (TLS) provides authentication between services and " "persons using X.509 certificates. Although the default mode for TLS is " "server-side only authentication, certificates may also be used for client " "authentication." msgstr "" #: ../identity/authentication.rst:27 msgid "Invalid login attempts" msgstr "" #: ../identity/authentication.rst:29 msgid "" "As of the Newton release, the Identity service can limit access to accounts " "after repeated unsuccessful login attempts. A pattern of repetitive failed " "login attempts is generally an indicator of brute-force attacks (refer to :" "ref:`introduction_attack_types`). This type of attack is more prevalent in " "public cloud deployments." msgstr "" #: ../identity/authentication.rst:36 msgid "" "For older deployments needing this functionality, prevention is possible by " "using an external authentication system that locks out an account after some " "configured number of failed login attempts. The account then may only be " "unlocked with further side-channel intervention." msgstr "" #: ../identity/authentication.rst:41 msgid "" "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." msgstr "" #: ../identity/authentication.rst:49 msgid "" "In addition, it is useful to examine account activity for unusual login " "times and suspicious actions, and take corrective actions such as disabling " "the account. Oftentimes this approach is taken by credit card providers for " "fraud detection and alert." msgstr "" #: ../identity/authentication.rst:57 msgid "" "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." msgstr "" #: ../identity/authentication.rst:62 msgid "" "This recommendation provides insulation from brute force, social " "engineering, and both spear and mass phishing attacks that may compromise " "administrator passwords." msgstr "" #: ../identity/authorization.rst:3 msgid "Authorization" msgstr "" #: ../identity/authorization.rst:5 msgid "" "The Identity service supports the notion of groups and roles. Users belong " "to groups while 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 then the user's group/roles and association to determine if " "access is allowed to the requested resource." msgstr "" #: ../identity/authorization.rst:12 msgid "" "The policy enforcement middleware enables fine-grained access control to " "OpenStack resources. The behaviour of the policy is discussed in depth in :" "ref:`policy-section`." msgstr "" #: ../identity/authorization.rst:18 msgid "Establish formal access control policies" msgstr "" #: ../identity/authorization.rst:20 msgid "" "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 the 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 the configuration is in compliance with " "approved policies." msgstr "" #: ../identity/authorization.rst:31 msgid "Service authorization" msgstr "" #: ../identity/authorization.rst:33 msgid "" "Cloud administrators must define a user with the role of admin for each " "service, as described in the `OpenStack Administrator Guide <https://docs." "openstack.org/admin-guide/index.html>`__. This service account provides the " "service with the authorization to authenticate users." msgstr "" #: ../identity/authorization.rst:39 msgid "" "The Compute and Object Storage services can be configured to use the " "Identity service to store authentication information. Other options to store " "authentication information include the use of the \"tempAuth\" file, however " "this should not be deployed in a production environment as the password is " "displayed in plain text." msgstr "" #: ../identity/authorization.rst:45 msgid "" "The Identity service supports client authentication for TLS which may be " "enabled. TLS client authentication provides an additional authentication " "factor, in addition to the user name and 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." msgstr "" #: ../identity/authorization.rst:55 msgid "" "We recommend that you use client authentication with TLS for the " "authentication of services to the Identity service." msgstr "" #: ../identity/authorization.rst:58 msgid "" "The cloud administrator should protect sensitive configuration files from " "unauthorized modification. This can be achieved with mandatory access " "control frameworks such as SELinux, including ``/etc/keystone/keystone." "conf`` and X.509 certificates." msgstr "" #: ../identity/authorization.rst:63 msgid "" "Client authentication with TLS requires certificates be issued to services. " "These certificates can be signed by an external or internal certificate " "authority. OpenStack services check the validity of certificate signatures " "against trusted CAs by default and connections will fail if the signature is " "not valid or the CA is not trusted. Cloud deployers may use self-signed " "certificates. In this case, the validity check must be disabled or the " "certificate should be marked as trusted. To disable validation of self-" "signed certificates, set ``insecure=False`` in the ``[filter:authtoken]`` " "section in the ``/etc/nova/api.paste.ini`` file. This setting also disables " "certificates for other components." msgstr "" #: ../identity/authorization.rst:76 msgid "Administrative users" msgstr "" #: ../identity/authorization.rst:78 msgid "" "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." msgstr "" #: ../identity/authorization.rst:86 msgid "End users" msgstr "" #: ../identity/authorization.rst:88 msgid "" "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." msgstr "" #: ../identity/checklist.rst:6 msgid "" "Check-Identity-01: Is user/group ownership of config files set to keystone?" msgstr "" #: ../identity/checklist.rst:8 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues causing a " "denial of service to the other end users. Thus user and group ownership of " "such critical configuration files must be set to that component owner. " "Additionally, the containing directory should have the same ownership to " "ensure that new files are owned correctly." msgstr "" #: ../identity/checklist.rst:30 msgid "" "**Pass:** If user and group ownership of all these config files is set to " "keystone. The above commands show output of keystone keystone." msgstr "" #: ../identity/checklist.rst:33 msgid "" "**Fail:** If the above commands does not return any output as the user or " "group ownership might have set to any user other than keystone." msgstr "" #: ../identity/checklist.rst:36 ../identity/checklist.rst:66 msgid "Recommended in: :ref:`internally-implemented-authentication-methods`." msgstr "" #: ../identity/checklist.rst:39 msgid "" "Check-Identity-02: Are strict permissions set for Identity configuration " "files?" msgstr "" #: ../identity/checklist.rst:61 msgid "" "**Pass:** If permissions are set to 640 or stricter, or the containing " "directory is set to 750." msgstr "" #: ../identity/checklist.rst:69 msgid "Check-Identity-03: is TLS enabled for Identity?" msgstr "" #: ../identity/checklist.rst:71 msgid "" "OpenStack components communicate with each other using various protocols and " "the communication might involve sensitive or confidential data. An attacker " "may try to eavesdrop on the channel in order to get access to sensitive " "information. Thus all the components must communicate with each other using " "a secured communication protocol like HTTPS." msgstr "" #: ../identity/checklist.rst:77 msgid "" "If you use the HTTP/WSGI server for Identity, you should enable TLS on the " "HTTP/WSGI server." msgstr "" #: ../identity/checklist.rst:80 msgid "**Pass:** If TLS is enabled on the HTTP server." msgstr "" #: ../identity/checklist.rst:82 msgid "**Fail:** If TLS is not enabled on the HTTP server." msgstr "" #: ../identity/checklist.rst:84 msgid "Recommended in: :doc:`../secure-communication`." msgstr "" #: ../identity/checklist.rst:87 msgid "Check-Identity-04: (Obsolete)" msgstr "" #: ../identity/checklist.rst:91 msgid "" "Check-Identity-05: Is ``max_request_body_size`` set to default (114688)?" msgstr "" #: ../identity/checklist.rst:93 msgid "" "The parameter ``max_request_body_size`` defines the maximum body size per " "request in bytes. If the maximum size is not defined, the attacker could " "craft an arbitrary request of large size causing the service to crash and " "finally resulting in Denial Of Service attack. Assigning the maximum value " "ensures that any malicious oversized request gets blocked ensuring continued " "availability of the component." msgstr "" #: ../identity/checklist.rst:100 msgid "" "**Pass:** If value of parameter ``max_request_body_size`` in ``/etc/keystone/" "keystone.conf`` is set to default (114688) or some reasonable value based on " "your environment." msgstr "" #: ../identity/checklist.rst:104 msgid "**Fail:** If value of parameter ``max_request_body_size`` is not set." msgstr "" #: ../identity/checklist.rst:107 msgid "" "Check-Identity-06: Disable admin token in ``/etc/keystone/keystone.conf``" msgstr "" #: ../identity/checklist.rst:109 msgid "" "The admin token is generally used to bootstrap Identity. This token is the " "most valuable Identity asset, which could be used to gain cloud admin " "privileges." msgstr "" #: ../identity/checklist.rst:113 msgid "" "**Pass:** If ``admin_token`` under ``[DEFAULT]`` section in ``/etc/keystone/" "keystone.conf`` is disabled. And, ``AdminTokenAuthMiddleware`` under " "``[filter:admin_token_auth]`` is deleted from ``/etc/keystone/keystone-paste." "ini``" msgstr "" #: ../identity/checklist.rst:118 msgid "" "**Fail:** If ``admin_token`` under ``[DEFAULT]`` section is set and " "``AdminTokenAuthMiddleware`` exists in ``keystone-paste.ini``." msgstr "" #: ../identity/checklist.rst:122 msgid "Disabling ``admin_token`` means it has a value of ``<none>``." msgstr "" #: ../identity/checklist.rst:125 msgid "" "Check-Identity-07: insecure_debug false in ``/etc/keystone/keystone.conf``" msgstr "" #: ../identity/checklist.rst:127 msgid "" "If ``insecure_debug`` is set to true, then the server will return " "information in HTTP responses that may allow an unauthenticated or " "authenticated user to get more information than normal, such as additional " "details about why authentication failed." msgstr "" #: ../identity/checklist.rst:132 msgid "" "**Pass:** If ``insecure_debug`` under ``[DEFAULT]`` section in ``/etc/" "keystone/keystone.conf`` is false." msgstr "" #: ../identity/checklist.rst:135 msgid "" "**Fail:** If ``insecure_debug`` under ``[DEFAULT]`` section in ``/etc/" "keystone/keystone.conf`` is true." msgstr "" #: ../identity/checklist.rst:139 msgid "Check-Identity-08: Use fernet token in ``/etc/keystone/keystone.conf``" msgstr "" #: ../identity/checklist.rst:141 msgid "" "OpenStack Identity service provides ``uuid`` and ``fernet`` as token " "providers. The ``uuid`` tokens must be persisted and is considered as " "insecure." msgstr "" #: ../identity/checklist.rst:144 msgid "" "**Pass:** If value of parameter ``provider`` under ``[token]`` section in ``/" "etc/keystone/keystone.conf`` is set to fernet." msgstr "" #: ../identity/checklist.rst:147 msgid "" "**Fail:** If value of parameter ``provider`` under ``[token]`` section is " "set to uuid." msgstr "" #: ../identity/domains.rst:3 msgid "Domains" msgstr "" #: ../identity/domains.rst:5 msgid "" "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." msgstr "" #: ../identity/domains.rst:14 msgid "" "The Identity V3 API supports multiple domains. Users of different domains " "may be represented in different authentication back ends 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." msgstr "" #: ../identity/domains.rst:20 msgid "" "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." msgstr "" #: ../identity/domains.rst:24 msgid "" "Domain-specific authentication drivers allow the Identity service to be " "configured for multiple domains using domain-specific configuration files. " "Enabling the drivers and setting the domain-specific configuration file " "location occur in the ``[identity]`` section of the ``keystone.conf`` file:" msgstr "" #: ../identity/domains.rst:35 msgid "" "Any domains without a domain-specific configuration file will use options in " "the primary ``keystone.conf`` file." msgstr "" #: ../identity/federated-keystone.rst:3 msgid "Federated keystone" msgstr "" #: ../identity/federated-keystone.rst:5 msgid "Some important definitions:" msgstr "" #: ../identity/federated-keystone.rst:8 msgid "" "A system entity that provides services to principals or other system " "entities, in this case, OpenStack Identity is the Service Provider." msgstr "" #: ../identity/federated-keystone.rst:9 msgid "Service Provider (SP)" msgstr "" #: ../identity/federated-keystone.rst:12 msgid "" "A directory service, such as LDAP, RADIUS and Active Directory, which allows " "users to login with a user name and password, is a typical source of " "authentication tokens (e.g. passwords) at an :term:`identity provider`." msgstr "" #: ../identity/federated-keystone.rst:15 msgid "Identity Provider (IdP)" msgstr "" #: ../identity/federated-keystone.rst:17 msgid "" ":term:`Federated Identity<federated identity>` is a mechanism to establish " "trusts between IdPs and SPs, in this case, between Identity Providers and " "the services provided by an OpenStack Cloud. It provides a secure way to use " "existing credentials to access cloud resources such as servers, volumes, and " "databases, across multiple endpoints. The credential is maintained by the " "user's IdP." msgstr "" #: ../identity/federated-keystone.rst:25 msgid "Why use Federated Identity?" msgstr "" #: ../identity/federated-keystone.rst:27 msgid "Two underlying reasons:" msgstr "" #: ../identity/federated-keystone.rst:29 msgid "Reduced complexity makes your deployment easier to secure." msgstr "" #: ../identity/federated-keystone.rst:30 msgid "It saves time for you and your users." msgstr "" #: ../identity/federated-keystone.rst:32 msgid "" "Centralize account management to prevent duplication of effort inside " "OpenStack infrastructure." msgstr "" #: ../identity/federated-keystone.rst:35 msgid "" "Reduce burden on users. Single sign on lets a single authentication method " "be used to access many different services & environments." msgstr "" #: ../identity/federated-keystone.rst:38 msgid "Move responsibility of password recovery process to IdP." msgstr "" #: ../identity/federated-keystone.rst:40 msgid "" "Futher justification and details can be found in Keystone's `documentation " "on federation <https://docs.openstack.org/keystone/latest/admin/federation/" "introduction.html>`_." msgstr "" #: ../identity/policies.rst:5 ../shared-file-systems/policies.rst:5 msgid "Policies" msgstr "" #: ../identity/policies.rst:7 msgid "" "Each OpenStack service defines the access policies for its resources in an " "associated policy file. A resource, for example, could be API access, the " "ability to attach to a volume, or to fire up instances. The policy rules are " "specified in JSON format and the file is called ``policy.json``. The syntax " "and format of this file is discussed in the `Configuration Reference " "<https://docs.openstack.org/ocata/config-reference/policy-json-file.html>`__." msgstr "" #: ../identity/policies.rst:14 msgid "" "These policies can be modified or updated by the cloud administrator to " "control the access to the various resources. Ensure that any changes to the " "access control policies do not unintentionally weaken the security of any " "resource. Also note that changes to the ``policy.json`` file become " "effective immediately and do not require the service to be restarted." msgstr "" #: ../identity/policies.rst:20 msgid "" "The following example shows how the service can restrict access to create, " "update and delete resources to only those users which have the role of " "``cloud_admin``, which has been defined as being the conjunction of ``role = " "admin`` and ``domain_id = admin_domain_id``, while the get and list " "resources are made available to users which have the role of ``cloud_admin`` " "or ``admin``." msgstr "" #: ../identity/tokens.rst:3 msgid "Tokens" msgstr "" #: ../identity/tokens.rst:5 msgid "" "Once a user is authenticated, a token is generated for authorization and " "access to an OpenStack environment. A token can have a variable life span; " "however the default value for expiry is one hour. The recommended expiry " "value should be set to a lower value that allows enough time for internal " "services to complete tasks. In the event that the token expires before tasks " "complete, the cloud may become unresponsive or stop providing services. An " "example of expended time during use would be the time needed by the Compute " "service to transfer a disk image onto the hypervisor for local caching. " "Fetching expired tokens when using a valid service token is allowed." msgstr "" #: ../identity/tokens.rst:16 msgid "" "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." msgstr "" #: ../identity/tokens.rst:21 msgid "Tokens can be revoked using the identity API." msgstr "" #: ../identity/tokens.rst:23 msgid "" "In the Stein release, there are two supported token types: fernet and JWT." msgstr "" #: ../identity/tokens.rst:26 msgid "" "Neither fernet or JWT tokens require persistence. The keystone token " "database no longer suffers bloat as a side effect of authentication. Pruning " "of expired tokens happens automatically. Replication across multiple nodes " "is also no longer needed. As long as each keystone node shares the same " "repository, tokens can be created and validated instantly across all nodes." msgstr "" #: ../identity/tokens.rst:33 msgid "Fernet tokens" msgstr "" #: ../identity/tokens.rst:34 msgid "" "Fernet tokens are the supported token provider for Stein (default). Fernet " "is a secure messaging format explicitly designed for use in API tokens. They " "are lightweight (fall in range of 180 to 240 bytes) and reduce the " "operational overhead required to run a cloud. Authentication and " "authorization metadata is neatly bundled into a message packed payload, " "which is then encrypted and signed in as a fernet token." msgstr "" #: ../identity/tokens.rst:42 msgid "JWT tokens" msgstr "" #: ../identity/tokens.rst:43 msgid "" "JSON Web Signature (JWS) tokens were introduced in the Stein release. " "Compared to fernet, JWS offer a potential benefit to operators by limiting " "the number of hosts that need to share a symmetric encryption key. This " "helps prevent malicious actors who might already have a foothold in your " "deployment from spreading into additional nodes." msgstr "" #: ../identity/tokens.rst:49 msgid "" "Further details on the differences between these token providers can be " "found here https://docs.openstack.org/keystone/stein/admin/tokens-overview." "html#token-providers" msgstr "" #: ../image-storage.rst:3 msgid "Image Storage" msgstr "" #: ../image-storage.rst:5 msgid "" "OpenStack Image Storage (glance) is a service where users can upload and " "discover data assets that are meant to be used with other services. This " "currently includes images and metadata definitions." msgstr "" #: ../image-storage.rst:9 msgid "" "Image services include discovering, registering, and retrieving virtual " "machine images. Glance has a RESTful API that allows querying of VM image " "metadata as well as retrieval of the actual image." msgstr "" #: ../image-storage.rst:13 msgid "" "For more details on the service see the `OpenStack Glance documentation " "<https://docs.openstack.org/glance/latest/>`__." msgstr "" #: ../image-storage/checklist.rst:8 msgid "" "Check-Image-01: Is user/group ownership of config files set to root/glance?" msgstr "" #: ../image-storage/checklist.rst:10 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally, modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues resulting in " "a denial of service to the other end users. Therefore, user ownership of " "such critical configuration files must be set to ``root`` and group " "ownership must be set to ``glance``. Additionally, the containing directory " "should have the same ownership to ensure that new files are owned correctly." msgstr "" #: ../image-storage/checklist.rst:36 msgid "" "**Pass:** If user and group ownership of all these configuration files is " "set to root and glance respectively. The above commands show output of root " "glance." msgstr "" #: ../image-storage/checklist.rst:39 msgid "**Fail:** If the above commands do not return any output." msgstr "" #: ../image-storage/checklist.rst:44 msgid "Check-Image-02: Are strict permissions set for configuration files?" msgstr "" #: ../image-storage/checklist.rst:46 msgid "" "Similar to the previous check, we recommend you set strict access " "permissions for such configuration files." msgstr "" #: ../image-storage/checklist.rst:70 msgid "" "**Pass:** If permissions are set to 640 or stricter, or the containing " "directory is set to 750. The permissions of 640/750 translates into owner r/" "w, group r, and no rights to others. For example, ``u=rw,g=r,o=``." msgstr "" #: ../image-storage/checklist.rst:76 msgid "" "With :ref:`check_image_01`, and permissions set to 640, root has read/write " "access and glance has read access to these configuration files. The access " "rights can also be validated using the following command. This command will " "only be available on your system if it supports ACLs." msgstr "" #: ../image-storage/checklist.rst:96 msgid "Check-Image-03: Is keystone used for authentication?" msgstr "" #: ../image-storage/checklist.rst:103 msgid "" "OpenStack supports various authentication strategies including noauth, and " "keystone. If the ``noauth`` strategy is used, then users can interact with " "OpenStack services without any authentication. This could be a potential " "risk since an attacker might gain unauthorized access to the OpenStack " "components. We strongly recommend that all services must be authenticated " "with keystone using their service accounts." msgstr "" #: ../image-storage/checklist.rst:110 msgid "" "**Pass:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section in ``/etc/glance/glance-api.conf`` is set to ``keystone`` and value " "of parameter ``auth_strategy`` under ``[DEFAULT]`` section in ``/etc/glance /" "glance-registry.conf`` is set to ``keystone``." msgstr "" #: ../image-storage/checklist.rst:115 msgid "" "**Fail:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section in ``/etc/glance/glance-api.conf`` is set to ``noauth`` or value of " "parameter ``auth_strategy`` under ``[DEFAULT]`` section in ``/etc/glance/" "glance- registry.conf`` is set to ``noauth``." msgstr "" #: ../image-storage/checklist.rst:123 msgid "Check-Image-04: Is TLS enabled for authentication?" msgstr "" #: ../image-storage/checklist.rst:125 msgid "" "OpenStack components communicate with each other using various protocols and " "the communication might involve sensitive or confidential data. An attacker " "may try to eavesdrop on the channel in order to get access to sensitive " "information. All components must communicate with each other using a secured " "communication protocol." msgstr "" #: ../image-storage/checklist.rst:131 msgid "" "**Pass:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/glance/glance-api.conf`` is set " "to the Identity API endpoint starting with ``https://``, and the value of " "the parameter ``insecure`` is under the same ``[keystone_authtoken]`` " "section in the same ``/etc/glance/glance-registry.conf`` is set to ``False``." msgstr "" #: ../image-storage/checklist.rst:137 msgid "" "**Fail:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/glance/glance-api.conf`` is not " "set to Identity API endpoint starting with ``https://``, or value of " "parameter ``insecure`` under the same ``[keystone_authtoken]`` section in " "the same ``/etc/glance/glance-api.conf`` is set to ``True``." msgstr "" #: ../image-storage/checklist.rst:146 msgid "Check-Image-05: Are masked port scans prevented?" msgstr "" #: ../image-storage/checklist.rst:148 msgid "" "The ``copy_from`` feature in Image Service API v1 supplied by Glance can " "allow an attacker to perform masked network port scans. If the v1 API is " "enabled, this policy should be set to a restricted value." msgstr "" #: ../image-storage/checklist.rst:152 msgid "" "**Pass:** If value of parameter ``copy_from`` in ``/etc/glance/policy.json`` " "is set to a restricted value, for example ``role:admin``." msgstr "" #: ../image-storage/checklist.rst:155 msgid "" "**Fail:** If value of parameter ``copy_from`` in ``/etc/glance/policy.json`` " "is not set." msgstr "" #: ../index.rst:3 msgid "OpenStack Security Guide" msgstr "" #: ../index.rst:6 msgid "Abstract" msgstr "" #: ../index.rst:8 msgid "" "This book provides best practices and conceptual information about securing " "an OpenStack cloud." msgstr "" #: ../index.rst:13 msgid "" "This guide was last updated during the Train release, documenting the " "OpenStack Train, Stein, and Rocky releases. It may not apply to EOL releases " "(for example Newton)." msgstr "" #: ../index.rst:17 msgid "" "We advise that you read this at your own discretion when planning on " "implementing security measures for your OpenStack cloud." msgstr "" #: ../index.rst:20 msgid "This guide is intended as advice only." msgstr "" #: ../index.rst:22 msgid "" "The OpenStack Security team is based on voluntary contributions from the " "OpenStack community. You can contact the security community directly in the " "#openstack-security channel on OFTC IRC, or by sending mail to the openstack-" "discuss mailing list with the [security] prefix in the subject header." msgstr "" #: ../index.rst:29 msgid "Contents" msgstr "" #: ../instance-management.rst:3 msgid "Instance security management" msgstr "" #: ../instance-management.rst:5 msgid "" "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." msgstr "" #: ../instance-management.rst:11 msgid "" "Deployers or users of OpenStack with strong security requirements may want " "to consider deploying these technologies. Not all are applicable in every " "situation. 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." msgstr "" #: ../instance-management.rst:18 msgid "" "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:" msgstr "" #: ../instance-management.rst:25 #: ../instance-management/security-services-for-instances.rst:6 msgid "Entropy to instances" msgstr "" #: ../instance-management.rst:26 #: ../instance-management/security-services-for-instances.rst:42 msgid "Scheduling instances to nodes" msgstr "" #: ../instance-management.rst:27 #: ../instance-management/security-services-for-instances.rst:105 msgid "Trusted images" msgstr "" #: ../instance-management.rst:28 #: ../instance-management/security-services-for-instances.rst:243 msgid "Instance migrations" msgstr "" #: ../instance-management.rst:29 #: ../instance-management/security-services-for-instances.rst:331 msgid "Monitoring, alerting, and reporting" msgstr "" #: ../instance-management.rst:30 #: ../instance-management/security-services-for-instances.rst:359 msgid "Updates and patches" msgstr "" #: ../instance-management.rst:31 #: ../instance-management/security-services-for-instances.rst:379 msgid "Firewalls and other host-based security controls" msgstr "" #: ../instance-management/security-services-for-instances.rst:3 msgid "Security services for instances" msgstr "" #: ../instance-management/security-services-for-instances.rst:8 msgid "" "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, which is referred to as entropy starvation. " "Entropy starvation can manifest in instances as something seemingly " "unrelated. For example, slow boot time may be caused by the instance 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." msgstr "" #: ../instance-management/security-services-for-instances.rst:21 msgid "" "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." msgstr "" #: ../instance-management/security-services-for-instances.rst:33 msgid "" "The Virtio RNG is a random number generator that uses ``/dev/random`` as the " "source of entropy by default, however can be configured to use a hardware " "RNG or a tool such as the entropy gathering daemon (`EGD <http://egd." "sourceforge.net>`_) to provide a way to fairly and securely distribute " "entropy through a distributed system. The Virtio RNG is enabled using the " "``hw_rng`` property of the metadata used to create the instance." msgstr "" #: ../instance-management/security-services-for-instances.rst:44 msgid "" "Before an instance is created, a host for the image instantiation must be " "selected. This selection is performed by the ``nova-scheduler`` which " "determines how to dispatch compute and volume requests." msgstr "" #: ../instance-management/security-services-for-instances.rst:49 msgid "" "The ``FilterScheduler`` is the default scheduler for OpenStack Compute, " "although other schedulers exist (see the section `Scheduling <https://docs." "openstack.org/ocata/config-reference/compute/schedulers.html>`_ in the " "`OpenStack Configuration Reference <https://docs.openstack.org/ocata/config-" "reference/config-overview.html>`_ ). This works in collaboration with " "'filter hints' to decide where an instance should be started. This process " "of host selection allows administrators to fulfill many different security " "and compliance 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." msgstr "" #: ../instance-management/security-services-for-instances.rst:63 msgid "Filter schedulers fall under four main categories:" msgstr "" #: ../instance-management/security-services-for-instances.rst:66 msgid "" "These filters will create an instance based on the utilizations of the " "hypervisor host sets and can trigger on free or used properties such as RAM, " "IO, or CPU utilization." msgstr "" #: ../instance-management/security-services-for-instances.rst:68 msgid "Resource based filters" msgstr "" #: ../instance-management/security-services-for-instances.rst:71 msgid "" "This delegates instance creation based on the image used, such as the " "operating system of the VM or type of image used." msgstr "" #: ../instance-management/security-services-for-instances.rst:72 msgid "Image based filters" msgstr "" #: ../instance-management/security-services-for-instances.rst:75 msgid "" "This filter will create an instance based on external details such as in a " "specific IP range, across availability zones, or on the same host as another " "instance." msgstr "" #: ../instance-management/security-services-for-instances.rst:77 msgid "Environment based filters" msgstr "" #: ../instance-management/security-services-for-instances.rst:80 msgid "" "This filter will delegate instance creation based on user or administrator " "provided criteria such as trusts or metadata parsing." msgstr "" #: ../instance-management/security-services-for-instances.rst:81 msgid "Custom criteria" msgstr "" #: ../instance-management/security-services-for-instances.rst:83 msgid "" "Multiple filters can be applied at once, such as the ``ServerGroupAffinity`` " "filter to ensure an instance is created on a member of a specific set of " "hosts and ``ServerGroupAntiAffinity`` filter to ensure that same instance is " "not created on another specific set of hosts. These filters should be " "analyzed carefully to ensure they do not conflict with each other and result " "in rules that prevent the creation of instances." msgstr "" #: ../instance-management/security-services-for-instances.rst:93 msgid "" "The ``GroupAffinity`` and ``GroupAntiAffinity`` filters conflict and should " "not both be enabled at the same time." msgstr "" #: ../instance-management/security-services-for-instances.rst:96 msgid "" "The ``DiskFilter`` filter is capable of oversubscribing disk space. While " "not normally an issue, this can be a concern on storage devices that are " "thinly provisioned, and this filter should be used with well-tested quotas " "applied." msgstr "" #: ../instance-management/security-services-for-instances.rst:101 msgid "" "We recommend you disable filters that parse things that are provided by " "users or are able to be manipulated such as metadata." msgstr "" #: ../instance-management/security-services-for-instances.rst:106 msgid "" "In a cloud environment, users work with either pre-installed images or " "images they upload themselves. In both cases, users should be able to ensure " "the image they are utilizing has not been tampered with. The ability to " "verify images is a fundamental imperative for security. A chain of trust is " "needed from the source of the image to the destination where it's used. This " "can be accomplished by signing images obtained from trusted sources and by " "verifying the signature prior to use. Various ways to obtain and create " "verified images will be discussed below, followed by a description of the " "image signature verification feature." msgstr "" #: ../instance-management/security-services-for-instances.rst:119 msgid "Image creation process" msgstr "" #: ../instance-management/security-services-for-instances.rst:121 msgid "" "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 transferred securely into OpenStack. There are a variety of " "options for obtaining images. Each has specific steps that help validate the " "image's provenance." msgstr "" #: ../instance-management/security-services-for-instances.rst:129 msgid "The first option is to obtain boot media from a trusted source." msgstr "" #: ../instance-management/security-services-for-instances.rst:141 msgid "" "The second option is to use the `OpenStack Virtual Machine Image Guide " "<https://docs.openstack.org/image-guide/>`_. In this case, you will want to " "follow your organizations OS hardening guidelines or those provided by a " "trusted third-party such as the `Linux STIGs <http://iase.disa.mil/stigs/os/" "unix-linux/Pages/index.aspx>`_." msgstr "" #: ../instance-management/security-services-for-instances.rst:147 msgid "" "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." msgstr "" #: ../instance-management/security-services-for-instances.rst:152 msgid "" "Example of RHEL 6 CCE-26976-1 which will help implement NIST 800-53 Section " "*AC-19(d)* in Oz." msgstr "" #: ../instance-management/security-services-for-instances.rst:194 msgid "" "It is recommended to avoid the manual image building process as it is " "complex and prone to error. Additionally, using an automated system like Oz " "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." msgstr "" #: ../instance-management/security-services-for-instances.rst:201 msgid "" "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 " "using it to create an instance. To do this, refer to the following section " "on Image Signature Verification, or the following paragraph if signatures " "cannot be used." msgstr "" #: ../instance-management/security-services-for-instances.rst:209 msgid "" "Images come from the Image service to the Compute service on a node. This " "transfer should be protected by running over TLS. Once the image is on the " "node, it is verified with a basic checksum and then its 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 is " "launched from the same expanded image. Since this expanded image is not re-" "verified by default before launching, it is possible that it has undergone " "tampering. The user would not be aware of tampering, unless a manual " "inspection of the files is performed in the resulting image." msgstr "" #: ../instance-management/security-services-for-instances.rst:221 #: ../secrets-management/secrets-management-use-cases.rst:6 msgid "Image signature verification" msgstr "" #: ../instance-management/security-services-for-instances.rst:222 msgid "" "Several features related to image signing are now available in OpenStack. As " "of the Mitaka release, the Image service can verify these signed images, " "and, to provide a full chain of trust, the Compute service has the option to " "perform image signature verification prior to image boot. Successful " "signature validation before image boot ensures the signed image hasn't " "changed. With this feature enabled, unauthorized modification of images (e." "g., modifying the image to include malware or rootkits) can be detected." msgstr "" #: ../instance-management/security-services-for-instances.rst:231 msgid "" "Administrators can enable instance signature verification by setting the " "``verify_glance_signatures`` flag to ``True`` in the ``/etc/nova/nova.conf`` " "file. When enabled, the Compute service automatically validates the signed " "instance when it is retrieved from the Image service. If this verification " "fails, the boot won't occur. The OpenStack Operations Guide provides " "guidance on how to create and upload a signed image, and how to use this " "feature. For more information, see `Adding Signed Images <https://docs." "openstack.org/operations-guide/ops-user-facing-operations.html#adding-signed-" "images>`_ in the Operations Guide." msgstr "" #: ../instance-management/security-services-for-instances.rst:245 msgid "" "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 carry significant risk. To " "understand the risks involved, the following are the high-level steps " "performed during a live migration:" msgstr "" #: ../instance-management/security-services-for-instances.rst:253 msgid "Start instance on destination host" msgstr "" #: ../instance-management/security-services-for-instances.rst:254 msgid "Transfer memory" msgstr "" #: ../instance-management/security-services-for-instances.rst:255 msgid "Stop the guest and sync disks" msgstr "" #: ../instance-management/security-services-for-instances.rst:256 msgid "Transfer state" msgstr "" #: ../instance-management/security-services-for-instances.rst:257 msgid "Start the guest" msgstr "" #: ../instance-management/security-services-for-instances.rst:260 msgid "Live migration risks" msgstr "" #: ../instance-management/security-services-for-instances.rst:262 msgid "" "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:" msgstr "" #: ../instance-management/security-services-for-instances.rst:268 msgid "" "*Denial of Service (DoS)*: If something fails during the migration process, " "the instance could be lost." msgstr "" #: ../instance-management/security-services-for-instances.rst:270 msgid "*Data exposure*: Memory or disk transfers must be handled securely." msgstr "" #: ../instance-management/security-services-for-instances.rst:271 msgid "" "*Data manipulation*: If memory or disk transfers are not handled securely, " "then an attacker could manipulate user data during the migration." msgstr "" #: ../instance-management/security-services-for-instances.rst:274 msgid "" "*Code injection*: If memory or disk transfers are not handled securely, then " "an attacker could manipulate executables, either on disk or in memory, " "during the migration." msgstr "" #: ../instance-management/security-services-for-instances.rst:279 msgid "Live migration mitigations" msgstr "" #: ../instance-management/security-services-for-instances.rst:281 msgid "" "There are several methods to mitigate some of the risk associated with live " "migrations, the following list details some of these:" msgstr "" #: ../instance-management/security-services-for-instances.rst:284 #: ../instance-management/security-services-for-instances.rst:289 msgid "Disable live migration" msgstr "" #: ../instance-management/security-services-for-instances.rst:285 msgid "Isolated migration network" msgstr "" #: ../instance-management/security-services-for-instances.rst:286 #: ../instance-management/security-services-for-instances.rst:315 msgid "Encrypted live migration" msgstr "" #: ../instance-management/security-services-for-instances.rst:291 msgid "" "At this time, live migration is enabled in OpenStack by default. Live " "migrations can be disabled by adding the following lines to the nova " "``policy.json`` file:" msgstr "" #: ../instance-management/security-services-for-instances.rst:303 msgid "Migration network" msgstr "" #: ../instance-management/security-services-for-instances.rst:305 msgid "" "As a general practice, live migration traffic should be restricted to the " "management security domain, see :doc:`../introduction/security-boundaries-" "and-threats`. With 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." msgstr "" #: ../instance-management/security-services-for-instances.rst:317 msgid "" "If there is a sufficient business case for keeping live migration enabled, " "then libvirtd can provide encrypted tunnels for the live migrations. " "However, this feature is not currently exposed in either the OpenStack " "Dashboard or nova-client commands, and can only be accessed through manual " "configuration of libvirtd. The live migration process then changes to the " "following high-level steps:" msgstr "" #: ../instance-management/security-services-for-instances.rst:324 msgid "Instance data is copied from the hypervisor to libvirtd." msgstr "" #: ../instance-management/security-services-for-instances.rst:325 msgid "" "An encrypted tunnel is created between libvirtd processes on both source and " "destination hosts." msgstr "" #: ../instance-management/security-services-for-instances.rst:327 msgid "" "Destination libvirtd host copies the instances back to an underlying " "hypervisor." msgstr "" #: ../instance-management/security-services-for-instances.rst:333 msgid "" "As an OpenStack virtual machine is a server image able to be replicated " "across hosts, best practice in logging applies similarly between physical " "and virtual hosts. Operating system-level and application-level events " "should be logged, including access events to hosts and data, user additions " "and removals, changes in privilege, and others as dictated by the " "environment. Ideally, you can configure these logs to export to a log " "aggregator that collects log events, correlates them for analysis, and " "stores them for reference or further action. One common tool to do this is " "an `ELK stack, or Elasticsearch, Logstash, and Kibana <https://www.elastic." "co/>`_." msgstr "" #: ../instance-management/security-services-for-instances.rst:345 msgid "" "These logs should be reviewed at a regular cadence such as a live view by a " "network operations center (NOC), or if the environment is not large enough " "to necessitate a NOC, then logs should undergo a regular log review process." msgstr "" #: ../instance-management/security-services-for-instances.rst:350 msgid "" "Many times interesting events trigger an alert which is sent to a responder " "for action. Frequently this alert takes the form of an email with the " "messages of interest. An interesting event could be a significant failure, " "or known health indicator of a pending failure. Two common utilities for " "managing alerts are `Nagios <https://www.nagios.org>`_ and `Zabbix <https://" "www.zabbix.com/>`_." msgstr "" #: ../instance-management/security-services-for-instances.rst:361 msgid "" "A hypervisor runs independent virtual machines. This hypervisor can run in " "an operating system or directly on the hardware (called baremetal). Updates " "to the hypervisor are not propagated down to the virtual machines. For " "example, if a deployment is using XenServer and has a set of Debian virtual " "machines, an update to XenServer will not update anything running on the " "Debian virtual machines." msgstr "" #: ../instance-management/security-services-for-instances.rst:369 msgid "" "Therefore, we recommend that clear ownership of virtual machines be " "assigned, and that those owners be responsible for the hardening, " "deployment, and continued functionality of the virtual machines. We also " "recommend that updates be deployed on a regular schedule. These patches " "should be tested in an environment as closely resembling production as " "possible to ensure both stability and resolution of the issue behind the " "patch." msgstr "" #: ../instance-management/security-services-for-instances.rst:381 msgid "" "Most common operating systems include host-based firewalls for additional " "security. While we recommend that virtual machines run as few applications " "as possible (to the point of being single-purpose instances, if possible), " "all applications running on a virtual machine should be profiled to " "determine what system resources the application needs access to, the lowest " "level of privilege required for it to run, and what the expected network " "traffic is that will be going into and coming from the virtual machine. This " "expected traffic should be added to the host-based firewall as allowed " "traffic (or whitelisted), along with any necessary logging and management " "communication such as SSH or RDP. All other traffic should be explicitly " "denied in the firewall configuration." msgstr "" #: ../instance-management/security-services-for-instances.rst:395 msgid "" "On Linux virtual machines, the application profile above can be used in " "conjunction with a tool like `audit2allow <http://wiki.centos.org/HowTos/" "SELinux#head-faa96b3fdd922004cdb988c1989e56191c257c01>`_ to build an SELinux " "policy that will further protect sensitive system information on most Linux " "distributions. SELinux uses a combination of users, policies and security " "contexts to compartmentalize the resources needed for an application to run, " "and segmenting it from other system resources that are not needed." msgstr "" #: ../instance-management/security-services-for-instances.rst:404 msgid "" "OpenStack provides security groups for both hosts and the network to add " "defense in depth to the virtual machines in a given project. These are " "similar to host-based firewalls as they allow or deny incoming traffic based " "on port, protocol, and address, however security group rules are applied to " "incoming traffic only, while host-based firewall rules are able to be " "applied to both incoming and outgoing traffic. It is also possible for host " "and network security group rules to conflict and deny legitimate traffic. We " "recommend ensuring that security groups are configured correctly for the " "networking being used. See :ref:`networking-security-groups` in this guide " "for more detail." msgstr "" #: ../introduction.rst:3 ../shared-file-systems/intro.rst:4 msgid "Introduction" msgstr "" #: ../introduction.rst:5 msgid "" "The OpenStack Security Guide is the result of a five day sprint of " "collaborative work of many individuals. The purpose of this document is to " "provide the best practice guidelines for deploying a secure OpenStack cloud. " "It is designed to reflect the current state of security within the OpenStack " "community and provide frameworks for decision making where listing specific " "security controls are not feasible due to complexity or other environment " "specific details." msgstr "" #: ../introduction/acknowledgements.rst:3 msgid "Acknowledgements" msgstr "" #: ../introduction/acknowledgements.rst:5 msgid "" "The OpenStack Security Group would like to acknowledge contributions from " "the following organizations that were instrumental in making this book " "possible. The organizations are:" msgstr "" #: ../introduction/introduction-to-openstack.rst:3 msgid "Introduction to OpenStack" msgstr "" #: ../introduction/introduction-to-openstack.rst:5 msgid "" "This guide provides security insight into :term:`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." msgstr "" #: ../introduction/introduction-to-openstack.rst:12 msgid "" "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 used like a reference." msgstr "" #: ../introduction/introduction-to-openstack.rst:22 msgid "" "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." msgstr "" #: ../introduction/introduction-to-openstack.rst:26 msgid "" "Throughout the book, we refer to several types of OpenStack cloud users: :" "term:`administrator`, :term:`operator`, and :term:`user`. We use these terms " "to identify the level of security access each role has, although, in " "reality, we understand that varying roles are often held by the same " "individual." msgstr "" #: ../introduction/introduction-to-openstack.rst:33 msgid "Cloud types" msgstr "" #: ../introduction/introduction-to-openstack.rst:35 msgid "" "OpenStack is a key enabler in the 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) `definition of cloud <http://" "nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf>`__ to " "introduce these different types of cloud as they apply to OpenStack." msgstr "" #: ../introduction/introduction-to-openstack.rst:43 msgid "Public cloud" msgstr "" #: ../introduction/introduction-to-openstack.rst:45 msgid "" "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 :term:`service provider` and can be consumed by individuals, " "corporations, or any paying customer. A public-cloud provider might expose a " "full set of features such as software-defined networking or block storage, " "in addition to multiple instance types." msgstr "" #: ../introduction/introduction-to-openstack.rst:52 msgid "" "By their nature, public clouds 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 might 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." msgstr "" #: ../introduction/introduction-to-openstack.rst:62 msgid "Private cloud" msgstr "" #: ../introduction/introduction-to-openstack.rst:64 msgid "" "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. The " "cloud 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 and, as such, their individual security " "concerns vary." msgstr "" #: ../introduction/introduction-to-openstack.rst:72 msgid "Community cloud" msgstr "" #: ../introduction/introduction-to-openstack.rst:74 msgid "" "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, or compliance considerations). The cloud might be " "owned, managed, and operated by one or more of organizations in the " "community, a third-party, or some combination of them, and it may exist on " "or off premises." msgstr "" #: ../introduction/introduction-to-openstack.rst:82 msgid "Hybrid cloud" msgstr "" #: ../introduction/introduction-to-openstack.rst:84 msgid "" "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 " "might present their advertising and catalogue 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 a more secure private cloud that is PCI " "compliant." msgstr "" #: ../introduction/introduction-to-openstack.rst:95 msgid "" "In 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." msgstr "" #: ../introduction/introduction-to-openstack.rst:101 msgid "OpenStack service overview" msgstr "" #: ../introduction/introduction-to-openstack.rst:103 msgid "" "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." msgstr "" #: ../introduction/introduction-to-openstack.rst:114 msgid "" "OpenStack :term:`Compute service (nova)` provides services to support the " "management of virtual machine instances at scale, instances that host multi-" "tiered applications, dev or test environments, \"Big Data\" crunching Hadoop " "clusters, or high-performance computing." msgstr "" #: ../introduction/introduction-to-openstack.rst:119 msgid "" "The Compute service facilitates this management through an abstraction layer " "that interfaces with supported hypervisors (we address this later on in more " "detail)." msgstr "" #: ../introduction/introduction-to-openstack.rst:123 msgid "" "Later in the guide, we focus generically on the virtualization stack as it " "relates to hypervisors." msgstr "" #: ../introduction/introduction-to-openstack.rst:126 msgid "" "For information about the current state of feature support, see `OpenStack " "Hypervisor Support Matrix <https://docs.openstack.org/nova/latest/user/" "support-matrix.html>`__." msgstr "" #: ../introduction/introduction-to-openstack.rst:130 msgid "" "Compute security 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 API endpoints." msgstr "" #: ../introduction/introduction-to-openstack.rst:138 msgid "" "The OpenStack :term:`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." msgstr "" #: ../introduction/introduction-to-openstack.rst:144 msgid "" "It is important to understand that object storage differs from traditional " "file system storage. Object storage is best used for static data such as " "media files (MP3s, images, or videos), virtual machine images, and backup " "files." msgstr "" #: ../introduction/introduction-to-openstack.rst:148 msgid "" "Object security should focus on access control and encryption of data in " "transit and at rest. Other concerns might relate to system abuse, illegal or " "malicious content storage, and cross-authentication attack vectors." msgstr "" #: ../introduction/introduction-to-openstack.rst:155 msgid "" "The OpenStack :term:`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." msgstr "" #: ../introduction/introduction-to-openstack.rst:160 msgid "" "Security considerations for block storage are similar to that of object " "storage." msgstr "" #: ../introduction/introduction-to-openstack.rst:164 #: ../shared-file-systems.rst:3 msgid "Shared File Systems" msgstr "" #: ../introduction/introduction-to-openstack.rst:166 msgid "" "The :term:`Shared File Systems service (manila)` provides a set of services " "for managing shared file systems in a multi-tenant cloud environment, " "similar to how OpenStack provides for block-based storage management through " "the OpenStack Block Storage service project. With the Shared File Systems " "service, you can create a remote file system, mount the file system on your " "instances, and then read and write data from your instances to and from your " "file system." msgstr "" #: ../introduction/introduction-to-openstack.rst:177 msgid "" "The OpenStack :term:`Networking service <Networking service (neutron)>` " "(neutron, previously called quantum) provides various networking services to " "cloud users (tenants) such as IP address management, DNS, DHCP, load " "balancing, and security groups (network access rules, like firewall " "policies). This service provides a framework for software defined networking " "(SDN) that allows for pluggable integration with various networking " "solutions." msgstr "" #: ../introduction/introduction-to-openstack.rst:184 msgid "" "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." msgstr "" #: ../introduction/introduction-to-openstack.rst:191 msgid "" "The OpenStack :term:`Dashboard (horizon)` provides a web-based interface for " "both cloud administrators and cloud tenants. Using this interface, " "administrators and tenants can provision, manage, and monitor cloud " "resources. The dashboard is commonly deployed in a public-facing manner with " "all the usual security concerns of public web portals." msgstr "" #: ../introduction/introduction-to-openstack.rst:198 msgid "Identity service" msgstr "" #: ../introduction/introduction-to-openstack.rst:200 msgid "" "The OpenStack :term:`Identity service (keystone)` is a **shared service** " "that provides authentication and authorization services throughout the " "entire cloud infrastructure. The Identity service has pluggable support for " "multiple forms of authentication." msgstr "" #: ../introduction/introduction-to-openstack.rst:205 msgid "" "Security concerns with the Identity service include trust in authentication, " "the management of authorization tokens, and secure communication." msgstr "" #: ../introduction/introduction-to-openstack.rst:209 msgid "Image service" msgstr "" #: ../introduction/introduction-to-openstack.rst:211 msgid "" "The OpenStack :term:`Image service (glance)` provides disk-image management " "services, including image discovery, registration, and delivery services to " "the Compute service, as needed." msgstr "" #: ../introduction/introduction-to-openstack.rst:215 msgid "" "Trusted processes for managing the life cycle of disk images are required, " "as are all the previously mentioned issues with respect to data security." msgstr "" #: ../introduction/introduction-to-openstack.rst:219 msgid "Data processing service" msgstr "" #: ../introduction/introduction-to-openstack.rst:221 msgid "" "The :term:`Data Processing service (sahara)` provides a platform for the " "provisioning, management, and usage of clusters running popular processing " "frameworks." msgstr "" #: ../introduction/introduction-to-openstack.rst:225 msgid "" "Security considerations for data processing should focus on data privacy and " "secure communications to provisioned clusters." msgstr "" #: ../introduction/introduction-to-openstack.rst:229 msgid "Other supporting technology" msgstr "" #: ../introduction/introduction-to-openstack.rst:231 msgid "" "Messaging is used for internal communication between several OpenStack " "services. By default, OpenStack uses message queues based on the :term:`AMQP " "<Advanced Message Queuing Protocol (AMQP)>`. Like most OpenStack services, " "AMQP supports pluggable components. Today the implementation back end could " "be RabbitMQ, Qpid, or ZeroMQ." msgstr "" #: ../introduction/introduction-to-openstack.rst:237 msgid "" "Because most management commands flow through the message queuing system, " "message-queue security is a primary security concern for any OpenStack " "deployment, and is discussed in detail later in this guide." msgstr "" #: ../introduction/introduction-to-openstack.rst:241 msgid "" "Several of the components use databases though it is not explicitly called " "out. Securing database access is yet another security concern, and " "consequently discussed in more detail later in this guide." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:3 msgid "Security boundaries and threats" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:5 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:13 msgid "Security domains" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:15 msgid "" "A security domain comprises users, applications, servers or networks that " "share common trust requirements and expectations within a system. Typically " "they have the same :term:`authentication` and :term:`authorization` (AuthN/" "Z) requirements and users." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:20 msgid "" "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:" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:25 #: ../introduction/security-boundaries-and-threats.rst:43 msgid "Public" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:26 #: ../introduction/security-boundaries-and-threats.rst:54 msgid "Guest" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:27 #: ../introduction/security-boundaries-and-threats.rst:68 ../management.rst:3 msgid "Management" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:28 #: ../introduction/security-boundaries-and-threats.rst:84 msgid "Data" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:30 msgid "" "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 may " "consist of a combination of guest and data domains onto one physical network " "while other topologies have these domains 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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:45 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:51 msgid "This domain should always be considered *untrusted*." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:56 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:60 msgid "" "Public and private cloud providers that do not have stringent controls on " "instance use or allow unrestricted internet access to VMs should consider " "this domain to be *untrusted*. Private cloud providers may want to consider " "this network as internal and *trusted* only if the proper controls are " "implemented to assert that the instances and all associated tenants are to " "be trusted." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:70 msgid "" "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, user names, and " "passwords. Command and Control traffic typically resides in this domain, " "which necessitates strong integrity requirements. Access to this domain " "should be highly restricted and monitored. At the same time, this domain " "should still employ all of the security best practices described in this " "guide." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:78 msgid "" "In most deployments this domain is considered *trusted*. 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 :ref:`Bridging_security_domains` for more information." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:86 msgid "" "The data security domain is concerned primarily with information pertaining " "to the storage services within OpenStack. Most of the data transmitted " "across this network requires high levels of integrity and confidentiality. " "In some cases, depending on the type of deployment there may also be strong " "availability requirements." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:92 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:98 msgid "Bridging security domains" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:100 msgid "" "A *bridge* 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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:110 msgid "" "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, " "which should be configured to protect against attacks from the public domain " "propagating through to the management domain." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:119 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:125 msgid "" "The design of OpenStack is such that separation of security domains is " "difficult. Because core services will usually bridge at least two domains, " "special consideration must be given when applying security controls to them." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:130 msgid "Threat classification, actors and attack vectors" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:132 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:137 msgid "Threat actors" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:139 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:148 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:152 msgid "Intelligence services" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:155 msgid "" "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 serious organized crime group." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:160 msgid "Serious organized crime" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:163 msgid "" "This refers to 'Hacktivist' type organizations who are not typically " "commercially funded but can pose a serious threat to service providers and " "cloud operators." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:165 msgid "Highly capable groups" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:168 msgid "" "Acting alone, these attackers come in many guises, such as rogue or " "malicious employees, disaffected customers, or small-scale industrial " "espionage." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:170 msgid "Motivated individuals" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:173 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:175 msgid "Script kiddies" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:180 msgid "Public and private cloud considerations" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:182 msgid "" "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 regularly " "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 *untrusted* " "state for public cloud providers." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:194 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:200 msgid "" "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 :term:`data loss prevention (DLP) <Data loss prevention " "(DLP) software>` protection, file inspection, deep packet inspection and " "prescriptive firewalling. In contrast, privacy is one of the primary " "barriers for the adoption of public cloud infrastructures, as many of the " "previously mentioned controls do not exist." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:210 msgid "Outbound attacks and reputational risk" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:212 msgid "" "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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:229 #: ../introduction/security-boundaries-and-threats.rst:237 msgid "Attack types" msgstr "" #: ../introduction/security-boundaries-and-threats.rst:231 msgid "" "The diagram shows the typical 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." msgstr "" #: ../introduction/security-boundaries-and-threats.rst:239 msgid "" "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)." msgstr "" #: ../introduction/selecting-supporting-software.rst:3 msgid "Selecting supporting software" msgstr "" #: ../introduction/selecting-supporting-software.rst:5 msgid "" "Your selection of supporting software, such as messaging and load balancing, " "can have serious security impacts on your cloud. It is important that you " "make the proper choices for your organization. This section provides some " "general guidelines for selecting supporting software." msgstr "" #: ../introduction/selecting-supporting-software.rst:11 msgid "" "In order to select the best supporting software, consider these factors:" msgstr "" #: ../introduction/selecting-supporting-software.rst:15 #: ../introduction/selecting-supporting-software.rst:40 msgid "Common Criteria" msgstr "" #: ../introduction/selecting-supporting-software.rst:21 msgid "" "The more familiar your team is with a given product, its configuration, and " "its eccentricities, the fewer configuration mistakes are made. Additionally, " "having staff expertise spread across an organization increases availability " "of your systems, allows segregation of duties, and mitigates problems in the " "event that a team member is unavailable." msgstr "" #: ../introduction/selecting-supporting-software.rst:30 msgid "" "The maturity of a given product or project is critical to your security " "posture. Product maturity has a number of effects after you deploy your " "cloud:" msgstr "" #: ../introduction/selecting-supporting-software.rst:42 msgid "" "`Common Criteria <https://www.commoncriteriaportal.org/>`_ is an " "internationally standardized software evaluation process, used by " "governments and commercial companies to validate that software technologies " "perform as advertised." msgstr "" #: ../introduction/selecting-supporting-software.rst:50 msgid "" "Consider the supportability of the hardware on which the software will run. " "Additionally, consider the additional features available in the hardware and " "how those features are supported by the software you choose." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:3 msgid "Why and how we wrote this book" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:5 msgid "" "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 **OpenStack " "Security Guide** 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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:13 msgid "" "This guide augments the `OpenStack Operations Guide <https://docs.openstack." "org/ops/>`__ and can be referenced to harden existing OpenStack deployments " "or to evaluate the security controls of OpenStack cloud providers." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:19 msgid "Objectives" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:21 msgid "Identify the security domains in OpenStack" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:22 msgid "Provide guidance to secure your OpenStack deployment" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:23 msgid "" "Highlight security concerns and potential mitigations in present day " "OpenStack" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:25 msgid "Discuss upcoming security features" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:26 msgid "" "To provide a community driven facility for knowledge capture and " "dissemination" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:30 msgid "How" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:32 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:39 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:47 msgid "The team included:" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:49 msgid "**Bryan D. Payne**, Nebula" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:51 msgid "" "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. Bryan " "was the editor and lead for the OpenStack Security Guide, responsible for " "its continued growth for the two years after it was written." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:59 msgid "**Robert Clark**, HP" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:61 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:68 msgid "**Keith Basil**, Red Hat" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:70 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:76 msgid "**Cody Bunch**, Rackspace" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:78 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:82 msgid "**Malini Bhandaru**, Intel" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:84 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:90 msgid "**Gregg Tally**, Johns Hopkins University Applied Physics Laboratory" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:92 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:98 msgid "**Eric Lopez**, VMware" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:100 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:108 msgid "**Shawn Wells**, Red Hat" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:110 msgid "" "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 aa NSA civilian, Shawn developed SIGINT collection systems " "utilizing large distributed computing infrastructures." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:118 msgid "**Ben de Bont**, HP" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:120 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:125 msgid "**Nathanael Burton**, National Security Agency" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:127 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:133 msgid "**Vibha Fauver**" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:135 msgid "" "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 & Information Science and a M.S. in Engineering Management with " "specialization and a certificate in Systems Engineering." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:141 msgid "**Eric Windisch**, Cloudscaling" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:143 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:150 msgid "**Andrew Hay**, CloudPassage" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:152 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:157 msgid "**Adam Hyde**" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:159 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:166 msgid "" "During the sprint we also had help from Anne Gentle, Warren Wang, Paul " "McMillan, Brian Schott and Lorin Hochstein." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:169 msgid "" "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 `BookSprints <http://www.booksprints.net>`__." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:176 msgid "How to contribute to this book" msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:178 msgid "" "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." msgstr "" #: ../introduction/why-and-how-we-wrote-this-book.rst:181 msgid "" "Learn more about how to contribute to the OpenStack docs, see the `OpenStack " "Documentation Contributor Guide <https://docs.openstack.org/doc-contrib-" "guide/index.html>`__." msgstr "" #: ../management.rst:5 msgid "" "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." msgstr "" #: ../management.rst:12 msgid "" "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." msgstr "" #: ../management.rst:18 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:3 msgid "Continuous systems management" msgstr "" #: ../management/continuous-systems-management.rst:5 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:14 msgid "" "For announcements regarding security relevant changes, subscribe to the " "`OpenStack Announce mailing list <http://lists.openstack.org/cgi-bin/mailman/" "listinfo/openstack-announce>`__. 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." msgstr "" #: ../management/continuous-systems-management.rst:21 msgid "" "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 certain data sources will be deployment specific, it " "is important that a cloud administrator subscribe to the necessary mailing " "lists in order to receive notification of any security updates applicable to " "the organization's environment. Often this is as simple as tracking an " "upstream Linux distribution." msgstr "" #: ../management/continuous-systems-management.rst:31 msgid "OpenStack releases security information through two channels." msgstr "" #: ../management/continuous-systems-management.rst:33 msgid "" "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 in " "`Vulnerability Management Process <https://security.openstack.org/vmt-" "process.html>`_." msgstr "" #: ../management/continuous-systems-management.rst:39 msgid "" "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 are referenced " "throughout this guide. Security Notes are archived at `OSSN <https://wiki." "openstack.org/wiki/OSSN>`_." msgstr "" #: ../management/continuous-systems-management.rst:46 msgid "Triage" msgstr "" #: ../management/continuous-systems-management.rst:48 msgid "" "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) do not properly " "account for cloud deployments." msgstr "" #: ../management/continuous-systems-management.rst:54 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:60 msgid "" "Privilege Escalation describes the ability of a user to act with the " "privileges of some other user in a system, bypassing appropriate " "authorization checks. A guest user performing an operation that allows them " "to conduct unauthorized operations with the privileges of an administrator " "is an example of this type of vulnerability." msgstr "" #: ../management/continuous-systems-management.rst:66 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:72 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:83 msgid "Attacker position / Privilege level" msgstr "" #: ../management/continuous-systems-management.rst:89 msgid "External" msgstr "" #: ../management/continuous-systems-management.rst:90 msgid "Cloud user" msgstr "" #: ../management/continuous-systems-management.rst:91 msgid "Cloud admin" msgstr "" #: ../management/continuous-systems-management.rst:92 msgid "Control plane" msgstr "" #: ../management/continuous-systems-management.rst:94 msgid "Privilege elevation (3 levels)" msgstr "" #: ../management/continuous-systems-management.rst:95 #: ../management/continuous-systems-management.rst:101 #: ../management/continuous-systems-management.rst:102 #: ../management/continuous-systems-management.rst:107 #: ../management/continuous-systems-management.rst:108 #: ../management/continuous-systems-management.rst:109 msgid "Critical" msgstr "" #: ../management/continuous-systems-management.rst:96 #: ../management/continuous-systems-management.rst:97 #: ../management/continuous-systems-management.rst:98 #: ../management/continuous-systems-management.rst:103 #: ../management/continuous-systems-management.rst:104 #: ../management/continuous-systems-management.rst:110 msgid "n/a" msgstr "" #: ../management/continuous-systems-management.rst:100 msgid "Privilege elevation (2 levels)" msgstr "" #: ../management/continuous-systems-management.rst:106 msgid "Privilege elevation (1 level)" msgstr "" #: ../management/continuous-systems-management.rst:112 msgid "Denial of service" msgstr "" #: ../management/continuous-systems-management.rst:113 msgid "High" msgstr "" #: ../management/continuous-systems-management.rst:114 msgid "Medium" msgstr "" #: ../management/continuous-systems-management.rst:115 #: ../management/continuous-systems-management.rst:116 #: ../management/continuous-systems-management.rst:122 msgid "Low" msgstr "" #: ../management/continuous-systems-management.rst:118 msgid "Information disclosure" msgstr "" #: ../management/continuous-systems-management.rst:119 #: ../management/continuous-systems-management.rst:120 msgid "Critical / high" msgstr "" #: ../management/continuous-systems-management.rst:121 msgid "Medium / low" msgstr "" #: ../management/continuous-systems-management.rst:125 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:131 msgid "" "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 " "quickly whereas a low-level update might take longer to be completed." msgstr "" #: ../management/continuous-systems-management.rst:138 msgid "Testing the updates" msgstr "" #: ../management/continuous-systems-management.rst:140 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:150 msgid "Deploying the updates" msgstr "" #: ../management/continuous-systems-management.rst:152 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:157 msgid "Configuration management" msgstr "" #: ../management/continuous-systems-management.rst:159 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:164 msgid "" "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 business continuity plan (BCP) " "and data recovery (DR) plans wherein you can rebuild a node or service back " "to a known state in a DR event or given a compromise." msgstr "" #: ../management/continuous-systems-management.rst:176 msgid "" "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 ``nova.conf`` 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." msgstr "" #: ../management/continuous-systems-management.rst:188 msgid "" "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: :term:`Chef` and :term:`Puppet`. A non-exhaustive " "listing of tools in this space is provided below:" msgstr "" #: ../management/continuous-systems-management.rst:193 msgid "Chef" msgstr "" #: ../management/continuous-systems-management.rst:195 msgid "Puppet" msgstr "" #: ../management/continuous-systems-management.rst:197 msgid "Salt Stack" msgstr "" #: ../management/continuous-systems-management.rst:199 msgid "Ansible" msgstr "" #: ../management/continuous-systems-management.rst:202 msgid "Policy changes" msgstr "" #: ../management/continuous-systems-management.rst:204 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:210 msgid "Secure backup and recovery" msgstr "" #: ../management/continuous-systems-management.rst:212 msgid "" "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, refer to the `OpenStack Operations Guide on " "backup and recovery <https://docs.openstack.org/operations-guide/ops-backup-" "recovery.html>`__." msgstr "" #: ../management/continuous-systems-management.rst:217 msgid "" "Ensure only authenticated users and backup clients have access to the backup " "server." msgstr "" #: ../management/continuous-systems-management.rst:220 msgid "Use data encryption options for storage and transmission of backups." msgstr "" #: ../management/continuous-systems-management.rst:222 msgid "" "Use a dedicated and hardened backup servers. The logs for the backup server " "must be monitored daily and accessible by only few individuals." msgstr "" #: ../management/continuous-systems-management.rst:226 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:233 msgid "Security auditing tools" msgstr "" #: ../management/continuous-systems-management.rst:235 msgid "" "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, `SCAP <https://fedorahosted.org/scap-security-" "guide/>`__ 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." msgstr "" #: ../management/continuous-systems-management.rst:246 msgid "" "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." msgstr "" #: ../management/continuous-systems-management.rst:254 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:3 msgid "Integrity life-cycle" msgstr "" #: ../management/integrity-life-cycle.rst:5 msgid "" "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 :term:`secure " "bootstrapping <secure boot>` and is maintained through configuration " "management and security monitoring. This chapter provides recommendations on " "how to approach the integrity life-cycle process." msgstr "" #: ../management/integrity-life-cycle.rst:15 msgid "Secure bootstrapping" msgstr "" #: ../management/integrity-life-cycle.rst:17 msgid "" "Nodes in the cloud—including compute, storage, network, service, and hybrid " "nodes—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." msgstr "" #: ../management/integrity-life-cycle.rst:26 msgid "" "There are a variety of technologies that enable verification of these early " "boot stages. These typically require hardware support such as the :term:" "`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 *secure boot technologies*. 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." msgstr "" #: ../management/integrity-life-cycle.rst:41 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:48 msgid "Node provisioning" msgstr "" #: ../management/integrity-life-cycle.rst:50 msgid "" "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—that is " "progressively more complex software to execute— from a server." msgstr "" #: ../management/integrity-life-cycle.rst:57 msgid "" "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 uses TLS to download the remaining information required to " "deploy the node. This may be an operating system installer, a basic install " "managed by `Chef <https://www.chef.io/chef/>`__ or `Puppet <https://" "puppetlabs.com/>`__, or even a complete file system image that is written " "directly to disk." msgstr "" #: ../management/integrity-life-cycle.rst:68 msgid "" "While utilizing TLS 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 TLS 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." msgstr "" #: ../management/integrity-life-cycle.rst:77 msgid "Verified boot" msgstr "" #: ../management/integrity-life-cycle.rst:79 msgid "" "In general, there are two different strategies for verifying the boot " "process. Traditional *secure boot* will validate the code run at each step " "in the process, and stop the boot if code is incorrect. *Boot attestation* " "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." msgstr "" #: ../management/integrity-life-cycle.rst:91 msgid "SHA-1 is used here because this is what the TPM chips support." msgstr "" #: ../management/integrity-life-cycle.rst:93 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:107 msgid "Register" msgstr "" #: ../management/integrity-life-cycle.rst:108 msgid "What is measured" msgstr "" #: ../management/integrity-life-cycle.rst:109 msgid "Context" msgstr "" #: ../management/integrity-life-cycle.rst:111 msgid "PCR-00" msgstr "" #: ../management/integrity-life-cycle.rst:112 msgid "" "Core Root of Trust Measurement (CRTM), BIOS code, Host platform extensions" msgstr "" #: ../management/integrity-life-cycle.rst:113 #: ../management/integrity-life-cycle.rst:117 #: ../management/integrity-life-cycle.rst:121 #: ../management/integrity-life-cycle.rst:125 msgid "Hardware" msgstr "" #: ../management/integrity-life-cycle.rst:115 msgid "PCR-01" msgstr "" #: ../management/integrity-life-cycle.rst:116 msgid "Host platform configuration" msgstr "" #: ../management/integrity-life-cycle.rst:119 msgid "PCR-02" msgstr "" #: ../management/integrity-life-cycle.rst:120 msgid "Option ROM code" msgstr "" #: ../management/integrity-life-cycle.rst:123 msgid "PCR-03" msgstr "" #: ../management/integrity-life-cycle.rst:124 msgid "Option ROM configuration and data" msgstr "" #: ../management/integrity-life-cycle.rst:127 msgid "PCR-04" msgstr "" #: ../management/integrity-life-cycle.rst:128 msgid "Initial Program Loader (IPL) code. For example, master boot record." msgstr "" #: ../management/integrity-life-cycle.rst:129 #: ../management/integrity-life-cycle.rst:133 #: ../management/integrity-life-cycle.rst:137 #: ../management/integrity-life-cycle.rst:141 #: ../management/integrity-life-cycle.rst:145 #: ../management/integrity-life-cycle.rst:149 #: ../management/integrity-life-cycle.rst:153 msgid "Software" msgstr "" #: ../management/integrity-life-cycle.rst:131 msgid "PCR-05" msgstr "" #: ../management/integrity-life-cycle.rst:132 msgid "IPL code configuration and data" msgstr "" #: ../management/integrity-life-cycle.rst:135 msgid "PCR-06" msgstr "" #: ../management/integrity-life-cycle.rst:136 msgid "State transition and wake events" msgstr "" #: ../management/integrity-life-cycle.rst:139 msgid "PCR-07" msgstr "" #: ../management/integrity-life-cycle.rst:140 msgid "Host platform manufacturer control" msgstr "" #: ../management/integrity-life-cycle.rst:143 msgid "PCR-08" msgstr "" #: ../management/integrity-life-cycle.rst:144 msgid "Platform specific, often kernel, kernel extensions, and drivers" msgstr "" #: ../management/integrity-life-cycle.rst:147 msgid "PCR-09" msgstr "" #: ../management/integrity-life-cycle.rst:148 msgid "Platform specific, often Initramfs" msgstr "" #: ../management/integrity-life-cycle.rst:151 msgid "PCR-10 to PCR-23" msgstr "" #: ../management/integrity-life-cycle.rst:152 msgid "Platform specific" msgstr "" #: ../management/integrity-life-cycle.rst:155 msgid "" "Secure boot may be an option for building your cloud, but requires careful " "planning 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." msgstr "" #: ../management/integrity-life-cycle.rst:166 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:177 msgid "" "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, the PXE firmware, and the kernel image. " "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." msgstr "" #: ../management/integrity-life-cycle.rst:185 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:199 msgid "Node hardening" msgstr "" #: ../management/integrity-life-cycle.rst:201 msgid "" "At this point we know that the node has booted with the correct kernel and " "underlying components. The next step is to harden the operating system and " "it starts with a set of industry-accepted hardening controls. The following " "guides are good examples:" msgstr "" #: ../management/integrity-life-cycle.rst:207 msgid "" "The Defense Information Systems Agency (DISA) (part of the United States " "Department of Defense) publishes STIG content for various operating systems, " "applications, and hardware. The controls are published without any license " "attached." msgstr "" #: ../management/integrity-life-cycle.rst:210 msgid "" "`Security Technical Implementation Guide (STIG) <http://iase.disa.mil/stigs/" "Pages/index.aspx>`_" msgstr "" #: ../management/integrity-life-cycle.rst:213 msgid "" "CIS regularly publishes security benchmarks as well as automated tools that " "apply those security controls automatically. These benchmarks are published " "under a `Creative Commons license <https://creativecommons.org/licenses/by-" "nc-sa/4.0/legalcode>`_ that has some limitations." msgstr "" #: ../management/integrity-life-cycle.rst:217 msgid "" "`Center for Internet Security (CIS) Benchmarks <https://www.cisecurity.org/" "cis-benchmarks/>`_" msgstr "" #: ../management/integrity-life-cycle.rst:219 msgid "" "These security controls are best applied via automated methods. Automation " "ensures that the controls are applied the same way each time for each system " "and they also provide a quick method for auditing an existing system. There " "are multiple options for automation:" msgstr "" #: ../management/integrity-life-cycle.rst:225 msgid "" "OpenSCAP is an open source tool which takes SCAP content (XML files that " "describe security controls) and applies that content to various systems. " "Most of the available content available today is for Red Hat Enterprise " "Linux and CentOS, but the tools work on any Linux or Windows system." msgstr "" #: ../management/integrity-life-cycle.rst:228 msgid "`OpenSCAP <https://www.open-scap.org/>`_" msgstr "" #: ../management/integrity-life-cycle.rst:231 msgid "" "The ansible-hardening project provides an Ansible role that applies security " "controls to a wide array of Linux operating systems. It can also be used to " "audit an existing system. Each control is carefully reviewed to determine if " "it could cause harm to a production system. The controls are based on the " "Red Hat Enterprise Linux 7 STIG." msgstr "" #: ../management/integrity-life-cycle.rst:235 msgid "" "`ansible-hardening <https://docs.openstack.org/ansible-hardening/latest/>`_" msgstr "" #: ../management/integrity-life-cycle.rst:237 msgid "" "Fully hardening a system is a challenging process and it may require a " "substantial amount of changes to some systems. Some of these changes could " "impact production workloads. If a system cannot be fully hardened, the " "following two changes are highly recommended to increase security without " "large disruptions:" msgstr "" #: ../management/integrity-life-cycle.rst:244 msgid "" "Mandatory access controls affect all users on the system, including root, " "and it is the kernel's job to review the activity against the current " "security policy. If the activity isn't within the allowed policy, it is " "blocked, even for the root user. Review the discussion on sVirt, SELinux, " "and AppArmor below for more details." msgstr "" #: ../management/integrity-life-cycle.rst:248 msgid "Mandatory Access Control (MAC)" msgstr "" #: ../management/integrity-life-cycle.rst:251 msgid "" "Ensure that the system has the fewest number of packages installed and " "services running as possible. Removing unneeded packages makes patching " "easier and it reduces the number of items on the system which could lead to " "a breach. Stopping unneeded services shrinks the attack surface on the " "system and makes it more difficult to attack." msgstr "" #: ../management/integrity-life-cycle.rst:255 msgid "Remove packages and stop services" msgstr "" #: ../management/integrity-life-cycle.rst:257 msgid "We also recommend the following additional steps for production nodes:" msgstr "" #: ../management/integrity-life-cycle.rst:260 msgid "" "Use a read-only file system where possible. Ensure that writeable file " "systems do not permit execution. This can be handled with the ``noexec``, " "``nosuid``, and ``nodev`` mount options in ``/etc/fstab``." msgstr "" #: ../management/integrity-life-cycle.rst:262 msgid "Read-only file system" msgstr "" #: ../management/integrity-life-cycle.rst:265 msgid "" "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 `dm-verity <https://gitlab.com/cryptsetup/cryptsetup/wikis/" "DMVerity>`__." msgstr "" #: ../management/integrity-life-cycle.rst:271 msgid "System validation" msgstr "" #: ../management/integrity-life-cycle.rst:274 msgid "Runtime verification" msgstr "" #: ../management/integrity-life-cycle.rst:276 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:284 msgid "Intrusion detection system" msgstr "" #: ../management/integrity-life-cycle.rst:286 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:297 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:308 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:317 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:322 msgid "`OSSEC <http://www.ossec.net/>`__" msgstr "" #: ../management/integrity-life-cycle.rst:324 msgid "`Samhain <http://la-samhna.de/samhain/>`__" msgstr "" #: ../management/integrity-life-cycle.rst:326 msgid "`Tripwire <http://sourceforge.net/projects/tripwire/>`__" msgstr "" #: ../management/integrity-life-cycle.rst:328 msgid "`AIDE <http://aide.sourceforge.net/>`__" msgstr "" #: ../management/integrity-life-cycle.rst:330 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:338 msgid "" "Similar to host-based tools, the selection and configuration of a network-" "based intrusion detection tool is deployment specific. `Snort <https://www." "snort.org/>`__ is the leading open source networking intrusion detection " "tool, and a good starting place to learn more." msgstr "" #: ../management/integrity-life-cycle.rst:343 msgid "" "There are a few important security considerations for network and host-based " "intrusion detection systems." msgstr "" #: ../management/integrity-life-cycle.rst:346 msgid "" "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 TLS, 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." msgstr "" #: ../management/integrity-life-cycle.rst:355 msgid "" "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." msgstr "" #: ../management/integrity-life-cycle.rst:362 msgid "Server hardening" msgstr "" #: ../management/integrity-life-cycle.rst:364 msgid "" "Servers in the cloud, including undercloud and overcloud infrastructure, " "should implement hardening best practices. As OS and server hardening is " "common, applicable best practices including but not limited to logging, user " "account restrictions, and regular updates will not be covered here, but " "should be applied to all infrastructure." msgstr "" #: ../management/integrity-life-cycle.rst:371 msgid "File integrity management (FIM)" msgstr "" #: ../management/integrity-life-cycle.rst:373 msgid "" "File integrity management (FIM) is the method of ensuring that files such as " "sensitive system or application configuration files are not corrupted or " "changed to allow unauthorized access or malicious behavior. This can be done " "through a utility such as Samhain that will create a checksum hash of the " "specified resource and then validate that hash at regular intervals, or " "through a tool such as DMVerity that can take a hash of block devices and " "will validate those hashes as they are accessed by the system before they " "are presented to the user." msgstr "" #: ../management/integrity-life-cycle.rst:382 msgid "" "These should be put in place to monitor and report on changes to system, " "hypervisor, and application configuration files such as ``/etc/pam.d/system-" "auth`` and ``/etc/keystone/keystone.conf``, as well as kernel modules (such " "as virtio). Best practice is to use the :command:`lsmod` command to show " "what is regularly being loaded on a system to help determine what should or " "should not be included in FIM checks." msgstr "" #: ../management/management-interfaces.rst:3 msgid "Management interfaces" msgstr "" #: ../management/management-interfaces.rst:5 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:9 msgid "" "OpenStack provides several management interfaces for operators and tenants:" msgstr "" #: ../management/management-interfaces.rst:12 msgid "OpenStack dashboard (horizon)" msgstr "" #: ../management/management-interfaces.rst:14 #: ../management/management-interfaces.rst:83 msgid "OpenStack API" msgstr "" #: ../management/management-interfaces.rst:16 msgid ":term:`Secure shell (SSH)<secure shell (SSH)>`" msgstr "" #: ../management/management-interfaces.rst:18 msgid "OpenStack management utilities such as nova-manage and glance-manage" msgstr "" #: ../management/management-interfaces.rst:20 msgid "Out-of-band management interfaces, such as IPMI" msgstr "" #: ../management/management-interfaces.rst:25 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:33 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:38 msgid "" "The dashboard provides tenant-users a self-service portal to provision their " "own resources within the limits set by administrators." msgstr "" #: ../management/management-interfaces.rst:42 msgid "" "The dashboard provides GUI support for routers and load-balancers. For " "example, the dashboard now implements all of the main Networking features." msgstr "" #: ../management/management-interfaces.rst:46 msgid "" "It is an extensible :term:`Django` web application that allows easy plug-in " "of third-party products and services, such as billing, monitoring, and " "additional management tools." msgstr "" #: ../management/management-interfaces.rst:50 msgid "" "The dashboard can also be branded for service providers and other commercial " "vendors." msgstr "" #: ../management/management-interfaces.rst:56 msgid "" "The dashboard requires cookies and JavaScript to be enabled in the web " "browser." msgstr "" #: ../management/management-interfaces.rst:59 msgid "" "The web server that hosts the dashboard should be configured for TLS to " "ensure data is encrypted." msgstr "" #: ../management/management-interfaces.rst:62 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:66 msgid "" "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 ``glance`` " "CLI." msgstr "" #: ../management/management-interfaces.rst:72 msgid "" "Create and manage security groups through dashboard. The security groups " "allows L3-L4 packet filtering for security policies to protect virtual " "machines." msgstr "" #: ../management/management-interfaces.rst:79 msgid "" "OpenStack.org, ReleaseNotes/Liberty. 2015. `OpenStack Liberty Release Notes " "<https://wiki.openstack.org/wiki/ReleaseNotes/Liberty>`__" msgstr "" #: ../management/management-interfaces.rst:85 msgid "" "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, ``nova`` or ``glance``), " "language-specific libraries, or third-party tools." msgstr "" #: ../management/management-interfaces.rst:93 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:98 msgid "" "The API provides a tenant interface for provisioning, managing, and " "accessing their resources." msgstr "" #: ../management/management-interfaces.rst:104 msgid "" "The API service should be configured for TLS to ensure data is encrypted." msgstr "" #: ../management/management-interfaces.rst:107 msgid "" "As a web service, OpenStack API is susceptible to familiar web site attack " "vectors such as denial of service attacks." msgstr "" #: ../management/management-interfaces.rst:111 msgid "Secure shell (SSH)" msgstr "" #: ../management/management-interfaces.rst:113 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:120 msgid "Host key fingerprints" msgstr "" #: ../management/management-interfaces.rst:122 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:129 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:136 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:141 msgid "" "Once the SSH host key is generated, the host key fingerprint should be " "stored in a secure and queryable 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." msgstr "" #: ../management/management-interfaces.rst:147 msgid "Management utilities" msgstr "" #: ../management/management-interfaces.rst:149 msgid "" "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, nova, glance). 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." msgstr "" #: ../management/management-interfaces.rst:159 msgid "" "The dedicated management utilities (\\*-manage) in some cases use the direct " "database connection." msgstr "" #: ../management/management-interfaces.rst:162 msgid "" "Ensure that the .rc file which has your credential information is secured." msgstr "" #: ../management/management-interfaces.rst:168 msgid "" "OpenStack.org, OpenStack End User Guide section. 2016. `OpenStack command-" "line clients overview <https://docs.openstack.org/user-guide/common/" "cli_overview.html>`__" msgstr "" #: ../management/management-interfaces.rst:171 msgid "" "OpenStack.org, Set environment variables using the OpenStack RC file. 2016. " "`Download and source the OpenStack RC file <https://docs.openstack.org/user-" "guide/common/cli_set_environment_variables_using_openstack_rc.html#download-" "and-source-the-openstack-rc-file>`__" msgstr "" #: ../management/management-interfaces.rst:175 msgid "Out-of-band management interface" msgstr "" #: ../management/management-interfaces.rst:177 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:186 msgid "" "Use strong passwords and safeguard them, or use client-side TLS " "authentication." msgstr "" #: ../management/management-interfaces.rst:189 msgid "" "Ensure that the network interfaces are on their own private(management or a " "separate) network. Segregate management domains with firewalls or other " "network gear." msgstr "" #: ../management/management-interfaces.rst:193 msgid "" "If you use a web interface to interact with the :term:`BMC <BMC (Baseboard " "Management Controller)>`/IPMI, always use the TLS interface, such as HTTPS " "or port 443. This TLS interface should **NOT** use self-signed certificates, " "as is often default, but should have trusted certificates using the " "correctly defined fully qualified domain names (FQDNs)." msgstr "" #: ../management/management-interfaces.rst:200 msgid "" "Monitor the traffic on the management network. The anomalies might be easier " "to track than on the busier compute nodes." msgstr "" #: ../management/management-interfaces.rst:203 msgid "" "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." msgstr "" #: ../management/management-interfaces.rst:211 msgid "" "SANS Technology Institute, InfoSec Handlers Diary Blog. 2012. `Hacking " "servers that are turned off <https://isc.sans.edu/diary/IPMI%3A+Hacking" "+servers+that+are+turned+%22off%22/13399>`__" msgstr "" #: ../messaging.rst:3 msgid "Message queuing" msgstr "" #: ../messaging.rst:5 msgid "" "Message queuing services facilitate inter-process communication in " "OpenStack. OpenStack supports these message queuing service back ends:" msgstr "" #: ../messaging.rst:10 msgid "Qpid" msgstr "" #: ../messaging.rst:12 msgid "ZeroMQ or 0MQ" msgstr "" #: ../messaging.rst:14 msgid "" "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." msgstr "" #: ../messaging.rst:20 msgid "" "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." msgstr "" #: ../messaging.rst:28 msgid "" "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." msgstr "" #: ../messaging.rst:33 msgid "" "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." msgstr "" #: ../messaging/security.rst:3 msgid "Messaging security" msgstr "" #: ../messaging/security.rst:5 msgid "" "This section discusses security hardening approaches for the three most " "common message queuing solutions used in OpenStack: RabbitMQ, Qpid, and " "ZeroMQ." msgstr "" #: ../messaging/security.rst:10 msgid "Messaging transport security" msgstr "" #: ../messaging/security.rst:12 msgid "" "AMQP based solutions (Qpid and RabbitMQ) support transport-level security " "using TLS. ZeroMQ messaging does not natively support TLS, but transport-" "level security is possible using labelled IPsec or CIPSO network labels." msgstr "" #: ../messaging/security.rst:17 msgid "" "We highly recommend enabling transport-level cryptography for your message " "queue. Using TLS 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 TLS 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 TLS " "connection. Note, when installing the certificate and key files, ensure that " "the file permissions are restricted, for example using ``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." msgstr "" #: ../messaging/security.rst:35 msgid "RabbitMQ server SSL configuration" msgstr "" #: ../messaging/security.rst:37 msgid "" "The following lines should be added to the system-wide RabbitMQ " "configuration file, typically ``/etc/rabbitmq/rabbitmq.config``:" msgstr "" #: ../messaging/security.rst:54 msgid "" "Note, the ``tcp_listeners`` option is set to ``[]`` to prevent it from " "listening on a non-SSL port. The ``ssl_listeners`` option should be " "restricted to only listen on the management network for the services." msgstr "" #: ../messaging/security.rst:58 msgid "For more information on RabbitMQ SSL configuration see:" msgstr "" #: ../messaging/security.rst:60 msgid "`RabbitMQ Configuration <http://www.rabbitmq.com/configure.html>`__" msgstr "" #: ../messaging/security.rst:62 msgid "`RabbitMQ SSL <http://www.rabbitmq.com/ssl.html>`__" msgstr "" #: ../messaging/security.rst:65 msgid "Qpid server SSL configuration" msgstr "" #: ../messaging/security.rst:67 msgid "The Apache Foundation has a messaging security guide for Qpid. See:" msgstr "" #: ../messaging/security.rst:69 msgid "" "`Apache Qpid SSL <http://qpid.apache.org/releases/qpid-0.32/cpp-broker/book/" "chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Security-" "Encryption_using_SSL>`__" msgstr "" #: ../messaging/security.rst:75 msgid "Queue authentication and access control" msgstr "" #: ../messaging/security.rst:77 msgid "" "RabbitMQ and Qpid offer authentication and access control mechanisms for " "controlling access to queues. ZeroMQ offers no such mechanisms." msgstr "" #: ../messaging/security.rst:80 msgid "" "Simple Authentication and Security Layer (SASL) is a framework for " "authentication and data security in Internet protocols. Both RabbitMQ and " "Qpid offer SASL and other pluggable authentication mechanisms beyond simple " "user names and passwords that allow for increased authentication security. " "While RabbitMQ supports SASL, support in OpenStack does not currently allow " "for requesting a specific SASL authentication mechanism. RabbitMQ support in " "OpenStack allows for either user name and password authentication over an " "unencrypted connection or user name and password in conjunction with X.509 " "client certificates to establish the secure TLS connection." msgstr "" #: ../messaging/security.rst:91 msgid "" "We recommend configuring X.509 client certificates on all the OpenStack " "service nodes for client connections to the messaging queue and where " "possible (currently only Qpid) perform authentication with X.509 client " "certificates. When using user names and passwords, accounts should be " "created per-service and node for finer grained auditability of access to the " "queue." msgstr "" #: ../messaging/security.rst:98 msgid "" "Before deployment, consider the TLS libraries that the queuing servers use. " "Qpid uses Mozilla's NSS library, whereas RabbitMQ uses Erlang's TLS module " "which uses OpenSSL." msgstr "" #: ../messaging/security.rst:103 msgid "Authentication configuration example: RabbitMQ" msgstr "" #: ../messaging/security.rst:105 msgid "On the RabbitMQ server, delete the default ``guest`` user:" msgstr "" #: ../messaging/security.rst:111 msgid "" "On the RabbitMQ server, for each OpenStack service or node that communicates " "with the message queue set up user accounts and privileges:" msgstr "" #: ../messaging/security.rst:119 msgid "Replace RABBIT\\_PASS with a suitable password." msgstr "" #: ../messaging/security.rst:121 msgid "For additional configuration information see:" msgstr "" #: ../messaging/security.rst:123 msgid "" "`RabbitMQ Access Control <https://www.rabbitmq.com/access-control.html>`__" msgstr "" #: ../messaging/security.rst:126 msgid "" "`RabbitMQ Authentication <https://www.rabbitmq.com/authentication.html>`__" msgstr "" #: ../messaging/security.rst:129 msgid "`RabbitMQ Plugins <https://www.rabbitmq.com/plugins.html>`__" msgstr "" #: ../messaging/security.rst:131 msgid "" "`RabbitMQ SASL External Auth <http://hg.rabbitmq.com/rabbitmq-auth-mechanism-" "ssl/file/rabbitmq_v3_1_3/README>`__" msgstr "" #: ../messaging/security.rst:135 msgid "OpenStack service configuration: RabbitMQ" msgstr "" #: ../messaging/security.rst:151 msgid "Authentication configuration example: Qpid" msgstr "" #: ../messaging/security.rst:153 msgid "For configuration information see:" msgstr "" #: ../messaging/security.rst:155 msgid "" "`Apache Qpid Authentication <http://qpid.apache.org/releases/qpid-0.32/cpp-" "broker/book/chap-Messaging_User_Guide-Security.html#sect-" "Messaging_User_Guide-Security-User_Authentication>`__" msgstr "" #: ../messaging/security.rst:158 msgid "" "`Apache Qpid Authorization <http://qpid.apache.org/releases/qpid-0.32/cpp-" "broker/book/chap-Messaging_User_Guide-Security.html#sect-" "Messaging_User_Guide-Security-Authorization>`__" msgstr "" #: ../messaging/security.rst:162 msgid "OpenStack service configuration: Qpid" msgstr "" #: ../messaging/security.rst:174 msgid "" "Optionally, if using SASL with Qpid specify the SASL mechanisms in use by " "adding:" msgstr "" #: ../messaging/security.rst:182 msgid "Message queue process isolation and policy" msgstr "" #: ../messaging/security.rst:184 msgid "" "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." msgstr "" #: ../messaging/security.rst:188 msgid "" "Message queue service processes should be isolated from each other and other " "processes on a machine." msgstr "" #: ../messaging/security.rst:194 msgid "" "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." msgstr "" #: ../messaging/security.rst:199 msgid "" "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." msgstr "" #: ../messaging/security.rst:208 msgid "" "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." msgstr "" #: ../messaging/security.rst:213 msgid "" "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." msgstr "" #: ../messaging/security.rst:220 msgid "" "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)." msgstr "" #: ../monitoring-logging.rst:5 msgid "Monitoring and logging" msgstr "" #: ../monitoring-logging.rst:7 msgid "" "Within a cloud environment there is a mixture of hardware, operating " "systems, virtual machine managers, OpenStack services, cloud-user activity " "(such as creating instances and attaching storage), networking, and end-" "users using the applications running on the various instances." msgstr "" #: ../monitoring-logging.rst:12 msgid "" "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 `OpenStack Operations Guide " "<https://docs.openstack.org/ops/>`_." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:3 msgid "Forensics and incident response" msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:5 msgid "" "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." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:11 msgid "" "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." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:15 msgid "" "For instance, analyzing the access logs of Identity service or its " "replacement authentication system would alert us to failed logins, " "frequency, origin IP, whether the events are restricted to select accounts " "and other pertinent information. Log analysis supports detection." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:21 msgid "" "Actions may be taken to mitigate potential malicious activity such as " "blacklisting an IP address, recommending the strengthening of user " "passwords, or de-activating a user account if it is deemed dormant." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:26 msgid "Monitoring use cases" msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:28 msgid "" "Event monitoring is a more pro-active approach to securing an environment, " "providing real-time detection and response. Several tools exist which can " "aid in monitoring." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:32 msgid "" "In the case of an OpenStack cloud instance, we need to monitor the hardware, " "the OpenStack services, and the cloud resource usage. The latter stems from " "wanting to be elastic, to scale to the dynamic needs of the users." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:37 msgid "" "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 applications, tools or scripts. There are open " "source and commercial solutions and some operators develop their own in-" "house solutions. These tools and scripts can generate events that can be " "sent to administrators through email or viewed in the integrated dashboard. " "It is important to consider additional use cases that may apply to your " "specific network and what you may consider anomalous behavior." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:47 msgid "" "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." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:52 msgid "" "Application events such as start or stop events that were unscheduled would " "also be events to monitor and examine for possible security implications." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:56 msgid "" "Operating system events on the OpenStack service machines such as user " "logins or restarts also provide valuable insight into proper and improper " "usage of systems." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:60 msgid "" "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." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:64 msgid "" "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." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:68 msgid "" "To reduce security risks from orphan instances on a user, tenant, or 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 and so on." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:75 msgid "" "A cloud will host many virtual instances, and monitoring these instances " "goes beyond hardware monitoring and log files which may just contain CRUD " "events." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:79 msgid "" "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." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:89 msgid "" "Siwczak, Piotr. `Some Practical Considerations for Monitoring in the " "OpenStack Cloud <https://www.mirantis.com/blog/openstack-monitoring/>`_. " "2012." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:92 msgid "" "blog.sflow.com, sflow: `Host sFlow distributed agent <http://blog.sflow." "com/2012/01/host-sflow-distributed-agent.html>`_. 2012." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:95 msgid "" "blog.sflow.com, sflow: `LAN and WAN <http://blog.sflow.com/2009/09/lan-and-" "wan.html>`_. 2009." msgstr "" #: ../monitoring-logging/forensics-and-incident-response.rst:98 msgid "" "blog.sflow.com, sflow: `Rapidly detecting large flows sFlow vs <http://blog." "sflow.com/2013/01/rapidly-detecting-large-flows-sflow-vs.html>`_. NetFlow/" "IPFIX. 2013." msgstr "" #: ../networking.rst:5 msgid "" "The OpenStack Networking service (neutron) enables the end-user or tenant to " "define, utilize, and consume networking resources. 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." msgstr "" #: ../networking.rst:14 msgid "" "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." msgstr "" #: ../networking.rst:22 msgid "" "This section is a high-level overview of what processes and best practices " "should be considered when implementing OpenStack Networking." msgstr "" #: ../networking/architecture.rst:3 msgid "Networking architecture" msgstr "" #: ../networking/architecture.rst:5 msgid "" "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 *neutron-server*, a Python daemon that exposes the OpenStack " "Networking API and passes tenant requests to a suite of plug-ins for " "additional processing." msgstr "" #: ../networking/architecture.rst:12 msgid "The OpenStack Networking components are:" msgstr "" #: ../networking/architecture.rst:15 msgid "" "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 requires indirect access to a persistent database. " "This is accomplished through plugins, which communicate with the database " "using AMQP (Advanced Message Queuing Protocol)." msgstr "" #: ../networking/architecture.rst:19 msgid "neutron server (*neutron-server* and *neutron-\\*-plugin*)" msgstr "" #: ../networking/architecture.rst:22 msgid "" "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 and depends on the plugin used. *Some " "plugins like OpenDaylight(ODL) and Open Virtual Network (OVN) do not require " "any python agents on compute nodes.*" msgstr "" #: ../networking/architecture.rst:26 msgid "plugin agent (*neutron-\\*-agent*)" msgstr "" #: ../networking/architecture.rst:29 msgid "" "Provides DHCP services to tenant networks. This agent is the same across all " "plug-ins and is responsible for maintaining DHCP configuration. The *neutron-" "dhcp-agent* requires message queue access. *Optional depending on plug-in.*" msgstr "" #: ../networking/architecture.rst:32 msgid "DHCP agent (*neutron-dhcp-agent*)" msgstr "" #: ../networking/architecture.rst:35 msgid "" "Provides L3/NAT forwarding for external network access of VMs on tenant " "networks. Requires message queue access. *Optional depending on plug-in.*" msgstr "" #: ../networking/architecture.rst:36 msgid "L3 agent (*neutron-l3-agent*)" msgstr "" #: ../networking/architecture.rst:39 msgid "" "Provides additional networking services to tenant networks. These SDN " "services may interact with *neutron-server*, *neutron-plugin*, and plugin-" "agents through communication channels such as REST APIs." msgstr "" #: ../networking/architecture.rst:41 msgid "network provider services (SDN server/services)" msgstr "" #: ../networking/architecture.rst:43 msgid "" "The following figure shows an architectural and networking flow diagram of " "the OpenStack Networking components:" msgstr "" #: ../networking/architecture.rst:50 msgid "OpenStack Networking service placement on physical servers" msgstr "" #: ../networking/architecture.rst:52 msgid "" "This guide focuses on a standard architecture that includes a *cloud " "controller* host, a *network* host, and a set of *compute* hypervisors for " "running VMs." msgstr "" #: ../networking/architecture.rst:57 msgid "Network connectivity of physical servers" msgstr "" #: ../networking/architecture.rst:62 msgid "" "A standard OpenStack Networking setup has up to four distinct physical data " "center networks:" msgstr "" #: ../networking/architecture.rst:66 msgid "" "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." msgstr "" #: ../networking/architecture.rst:68 msgid "Management network" msgstr "" #: ../networking/architecture.rst:71 msgid "" "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." msgstr "" #: ../networking/architecture.rst:75 msgid "Guest network" msgstr "" #: ../networking/architecture.rst:78 msgid "" "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. " "This network is considered to be in the Public Security Domain." msgstr "" #: ../networking/architecture.rst:80 msgid "External network" msgstr "" #: ../networking/architecture.rst:83 msgid "" "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." msgstr "" #: ../networking/architecture.rst:88 msgid "API network" msgstr "" #: ../networking/architecture.rst:90 msgid "" "For additional information see the `OpenStack Administrator Guide <https://" "docs.openstack.org/admin-guide/networking.html>`__." msgstr "" #: ../networking/checklist.rst:8 msgid "" "Check-Neutron-01: Is user/group ownership of config files set to root/" "neutron?" msgstr "" #: ../networking/checklist.rst:10 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues causing a " "denial of service to the other end users. Thus user ownership of such " "critical configuration files must be set to root and group ownership must be " "set to neutron. Additionally, the containing directory should have the same " "ownership to ensure that new files are owned correctly." msgstr "" #: ../networking/checklist.rst:29 msgid "" "**Pass:** If user and group ownership of all these config files is set to " "root and neutron respectively. The above commands show output of root " "neutron." msgstr "" #: ../networking/checklist.rst:33 msgid "" "**Fail:** If the above commands does not return any output as the user and " "group ownership might have set to any user other than root or any group " "other than neutron." msgstr "" #: ../networking/checklist.rst:40 msgid "Check-Neutron-02: Are strict permissions set for configuration files?" msgstr "" #: ../networking/checklist.rst:59 msgid "" "**Pass:** If permissions are set to 640 or stricter, or the containing " "directory is set to 750. The permissions of 640 translates into owner r/w, " "group r, and no rights to others i.e. \"u=rw,g=r,o=\"." msgstr "" #: ../networking/checklist.rst:63 msgid "" "Note that with :ref:`check_neutron_01` and permissions set to 640, root has " "read/write access and neutron has read access to these configuration files. " "The access rights can also be validated using the following command. This " "command will only be available on your system if it supports ACLs." msgstr "" #: ../networking/checklist.rst:83 msgid "Check-Neutron-03: Is keystone used for authentication?" msgstr "" #: ../networking/checklist.rst:90 msgid "" "OpenStack supports various authentication strategies like noauth, keystone " "etc. If the 'noauth' strategy is used then the users could interact with " "OpenStack services without any authentication. This could be a potential " "risk since an attacker might gain unauthorized access to the OpenStack " "components. Thus it is strongly recommended that all services must be " "authenticated with keystone using their service accounts." msgstr "" #: ../networking/checklist.rst:97 msgid "" "**Pass:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section in ``/etc/neutron/neutron.conf`` is set to ``keystone``." msgstr "" #: ../networking/checklist.rst:106 msgid "Check-Neutron-04: Is secure protocol used for authentication?" msgstr "" #: ../networking/checklist.rst:114 msgid "" "**Pass:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/neutron/neutron.conf`` is set to " "Identity API endpoint starting with ``https://`` and value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/neutron/neutron.conf`` is set to ``False``." msgstr "" #: ../networking/checklist.rst:120 msgid "" "**Fail:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/neutron/neutron.conf`` is not set " "to Identity API endpoint starting with ``https://`` or value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/neutron/neutron.conf`` is set to ``True``." msgstr "" #: ../networking/checklist.rst:129 msgid "Check-Neutron-05: Is TLS enabled on Neutron API server?" msgstr "" #: ../networking/checklist.rst:131 msgid "" "Similar to the previous check, it is recommended to enable secure " "communication on API server." msgstr "" #: ../networking/checklist.rst:134 msgid "" "**Pass:** If value of parameter ``use_ssl`` under ``[DEFAULT]`` section in " "``/etc/neutron/neutron.conf`` is set to ``True``." msgstr "" #: ../networking/checklist.rst:137 msgid "" "**Fail:** If value of parameter ``use_ssl`` under ``[DEFAULT]`` section in " "``/etc/neutron/neutron.conf`` is set to ``False``." msgstr "" #: ../networking/securing-services.rst:3 msgid "Networking services security best practices" msgstr "" #: ../networking/securing-services.rst:5 msgid "" "To secure OpenStack Networking, you must understand how the workflow process " "for tenant instance creation needs to be mapped to security domains." msgstr "" #: ../networking/securing-services.rst:9 msgid "" "There are four main services that interact with OpenStack Networking. In a " "typical OpenStack deployment these services map to the following security " "domains:" msgstr "" #: ../networking/securing-services.rst:13 msgid "OpenStack dashboard: Public and management" msgstr "" #: ../networking/securing-services.rst:15 msgid "OpenStack Identity: Management" msgstr "" #: ../networking/securing-services.rst:17 msgid "OpenStack compute node: Management and guest" msgstr "" #: ../networking/securing-services.rst:19 msgid "" "OpenStack network node: Management, guest, and possibly public depending " "upon neutron-plugin in use." msgstr "" #: ../networking/securing-services.rst:22 msgid "" "SDN services node: Management, guest and possibly public depending upon " "product used." msgstr "" #: ../networking/securing-services.rst:28 msgid "" "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." msgstr "" #: ../networking/securing-services.rst:34 msgid "OpenStack Networking service configuration" msgstr "" #: ../networking/securing-services.rst:37 msgid "Restrict bind address of the API server: neutron-server" msgstr "" #: ../networking/securing-services.rst:39 msgid "" "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:" msgstr "" #: ../networking/securing-services.rst:53 msgid "Restrict DB and RPC communication of the OpenStack Networking services" msgstr "" #: ../networking/securing-services.rst:55 msgid "" "Various components of the OpenStack Networking services use either the " "messaging queue or database connections to communicate with other components " "in OpenStack Networking." msgstr "" #: ../networking/securing-services.rst:59 msgid "" "It is recommended that you follow the guidelines provided in :ref:`database-" "authentication-and-access-control` for all components which require direct " "DB connections." msgstr "" #: ../networking/securing-services.rst:63 msgid "" "It is recommended that you follow the guidelines provided in :ref:`queue-" "authentication-and-access-control` for all components which require RPC " "communication." msgstr "" #: ../networking/services-security-best-practices.rst:3 msgid "Securing OpenStack networking services" msgstr "" #: ../networking/services-security-best-practices.rst:5 msgid "" "This section discusses OpenStack Networking configuration best practices as " "they apply to project network security within your OpenStack deployment." msgstr "" #: ../networking/services-security-best-practices.rst:10 msgid "Project network services workflow" msgstr "" #: ../networking/services-security-best-practices.rst:12 msgid "" "OpenStack Networking provides users 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." msgstr "" #: ../networking/services-security-best-practices.rst:18 msgid "Networking resource policy engine" msgstr "" #: ../networking/services-security-best-practices.rst:20 msgid "" "A policy engine and its configuration file, ``policy.json``, within " "OpenStack Networking provides a method to provide finer grained " "authorization of users on project networking methods and objects. The " "OpenStack Networking policy definitions affect network availability, network " "security and overall OpenStack security. Cloud architects and operators " "should carefully evaluate their policy towards user and project access to " "administration of network resources. For a more detailed explanation of " "OpenStack Networking policy definition, please refer to the `Authentication " "and authorization section <https://docs.openstack.org/admin-guide/" "networking_auth.html>`__ in the OpenStack Administrator Guide." msgstr "" #: ../networking/services-security-best-practices.rst:34 msgid "" "It is important to review the default networking resource policy, as this " "policy can be modified to suit your security posture." msgstr "" #: ../networking/services-security-best-practices.rst:37 msgid "" "If your deployment of OpenStack provides multiple external access points " "into different security domains it is important that you limit the project's " "ability to attach multiple vNICs to multiple external access points—this " "would bridge these security domains and could lead to unforeseen security " "compromise. It is possible mitigate this risk by utilizing the host " "aggregates functionality provided by OpenStack Compute or through splitting " "the project VMs into multiple project projects with different virtual " "network configurations." msgstr "" #: ../networking/services-security-best-practices.rst:51 msgid "" "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, ``nova.conf`` should always " "disable built-in security groups and proxy all security group calls to the " "OpenStack Networking API when using OpenStack Networking. Failure to do so " "results in conflicting security policies being simultaneously applied by " "both services. To proxy security groups to OpenStack Networking, use the " "following configuration values:" msgstr "" #: ../networking/services-security-best-practices.rst:60 msgid "" "``firewall_driver`` must be set to ``nova.virt.firewall.NoopFirewallDriver`` " "so that nova-compute does not perform iptables-based filtering itself." msgstr "" #: ../networking/services-security-best-practices.rst:64 msgid "" "``security_group_api`` must be set to ``neutron`` so that all security group " "requests are proxied to the OpenStack Networking service." msgstr "" #: ../networking/services-security-best-practices.rst:68 msgid "" "A security group is a container for security group rules. Security groups " "and their rules allow administrators and projects the ability to specify the " "type of traffic and direction (ingress/egress) that is allowed to pass " "through a virtual interface port. When a virtual interface port is created " "in OpenStack Networking it is associated with a security group. For further " "details on the default behavior of port security groups, reference the " "`Networking Security Group Behavior <https://wiki.openstack.org/wiki/Neutron/" "SecurityGroups#Behavior>`__ documentation. Rules can be added to the default " "security group in order to change the behavior on a per-deployment basis." msgstr "" #: ../networking/services-security-best-practices.rst:79 msgid "" "When using the OpenStack Compute API to modify security groups, the updated " "security group applies to all virtual interface ports on an instance. This " "is due to the OpenStack Compute security group APIs being instance-based " "rather than port-based, as found in OpenStack Networking." msgstr "" #: ../networking/services-security-best-practices.rst:85 msgid "Quotas" msgstr "" #: ../networking/services-security-best-practices.rst:87 msgid "" "Quotas provide the ability to limit the number of network resources " "available to projects. You can enforce default quotas for all projects. The " "``/etc/neutron/neutron.conf`` includes these options for quota:" msgstr "" #: ../networking/services-security-best-practices.rst:118 msgid "" "OpenStack Networking also supports per-project quotas limit through a quota " "extension API. To enable per-project quotas, you must set the " "``quota_driver`` option in ``neutron.conf``." msgstr "" #: ../networking/services-security-best-practices.rst:127 msgid "Mitigate ARP spoofing" msgstr "" #: ../networking/services-security-best-practices.rst:129 msgid "" "When using flat networking, you cannot assume that projects which share the " "same layer 2 network (or broadcast domain) are fully isolated from each " "other. These projects may be vulnerable to ARP spoofing, risking the " "possibility of man-in-the-middle attacks." msgstr "" #: ../networking/services-security-best-practices.rst:134 msgid "" "If using a version of Open vSwitch that supports ARP field matching, you can " "help mitigate this risk by enabling the ``prevent_arp_spoofing`` option for " "the Open vSwitch agent. This option prevents instances from performing spoof " "attacks; it does not protect them from spoof attacks. Note that this setting " "is expected to be removed in Ocata, with the behavior becoming permanently " "active." msgstr "" #: ../networking/services-security-best-practices.rst:141 msgid "For example, in ``/etc/neutron/plugins/ml2/openvswitch_agent.ini``:" msgstr "" #: ../networking/services-security-best-practices.rst:147 msgid "" "Plug-ins other than Open vSwitch may also include similar mitigation " "measures; it is recommended you enable this feature, where appropriate." msgstr "" #: ../networking/services-security-best-practices.rst:150 msgid "" "Even with ``prevent_arp_spoofing`` enabled, flat networking does not provide " "a complete level of project isolation, as all project traffic is still sent " "to the same VLAN." msgstr "" #: ../networking/services.rst:3 msgid "Networking services" msgstr "" #: ../networking/services.rst:5 msgid "" "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." msgstr "" #: ../networking/services.rst:11 msgid "" "OpenStack Networking adds a layer of virtualized network services which " "gives tenants the capability to architect their own virtual networks. " "Currently, these virtualized services are not as mature as their traditional " "networking counterparts. Consider the current state of these virtualized " "services before adopting them as it dictates what controls you may have to " "implement at the virtualized and traditional network boundaries." msgstr "" #: ../networking/services.rst:20 msgid "L2 isolation using VLANs and tunneling" msgstr "" #: ../networking/services.rst:22 msgid "" "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. The scope and scale of your OpenStack " "deployment determines which method you should utilize for traffic " "segregation or isolation." msgstr "" #: ../networking/services.rst:29 msgid "VLANs" msgstr "" #: ../networking/services.rst:31 msgid "" "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." msgstr "" #: ../networking/services.rst:39 msgid "" "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." msgstr "" #: ../networking/services.rst:46 msgid "" "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." msgstr "" #: ../networking/services.rst:52 msgid "L2 tunneling" msgstr "" #: ../networking/services.rst:54 msgid "" "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." msgstr "" #: ../networking/services.rst:64 msgid "" "OpenStack Networking currently supports both GRE and VXLAN encapsulation." msgstr "" #: ../networking/services.rst:67 msgid "" "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." msgstr "" #: ../networking/services.rst:74 msgid "Network services" msgstr "" #: ../networking/services.rst:76 msgid "" "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." msgstr "" #: ../networking/services.rst:83 msgid "Access control lists" msgstr "" #: ../networking/services.rst:85 msgid "" "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." msgstr "" #: ../networking/services.rst:89 msgid "" "Note, legacy nova-network security groups are applied to all virtual " "interface ports on an instance using iptables." msgstr "" #: ../networking/services.rst:92 msgid "" "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." msgstr "" #: ../networking/services.rst:97 msgid "" "When using the Networking service, we recommend that you enable security " "groups in this service and disable it in the Compute service." msgstr "" #: ../networking/services.rst:101 msgid "L3 routing and NAT" msgstr "" #: ../networking/services.rst:103 msgid "" "OpenStack Networking routers can connect multiple L2 networks, and can also " "provide a *gateway* that connects one or more private L2 networks to a " "shared *external* network, such as a public network for access to the " "Internet." msgstr "" #: ../networking/services.rst:108 msgid "" "The L3 router provides basic Network Address Translation (NAT) capabilities " "on *gateway* 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." msgstr "" #: ../networking/services.rst:115 msgid "" "It is our recommendation to leverage per tenant L3 routing and Floating IPs " "for more granular connectivity of tenant VMs." msgstr "" #: ../networking/services.rst:119 msgid "Quality of Service (QoS)" msgstr "" #: ../networking/services.rst:121 msgid "" "By default, Quality of Service (QoS) policies and rules are managed by the " "cloud administrator, which results in tenants being unable to create " "specific QoS rules, or to attach specific ports to policies. In some use " "cases, such as some telecommunications applications, the administrator may " "trust the tenants and therefore let them create and attach their own " "policies to ports. This can be achieved by modifying the ``policy.json`` " "file and `specific documentation <https://specs.openstack.org/openstack/" "neutron-specs/specs/liberty/qos-api-extension.html>`_. will be released with " "the extension." msgstr "" #: ../networking/services.rst:131 msgid "" "The Networking service (neutron) supports bandwidth-limiting QoS rules in " "Liberty and later. This QoS rule is named ``QosBandwidthLimitRule`` and it " "accepts two non-negative integers measured in kilobits per second:" msgstr "" #: ../networking/services.rst:135 msgid "``max-kbps``: bandwidth" msgstr "" #: ../networking/services.rst:136 msgid "``max-burst-kbps``: burst buffer" msgstr "" #: ../networking/services.rst:138 msgid "" "The ``QoSBandwidthLimitRule`` has been implemented in the neutron Open " "vSwitch, Linux bridge and single root input/output virtualization (SR-IOV) " "drivers." msgstr "" #: ../networking/services.rst:142 msgid "" "In Newton, the QoS rule ``QosDscpMarkingRule`` was added. This rule marks " "the Differentiated Service Code Point (DSCP) value in the type of service " "header on IPv4 (RFC 2474) and traffic class header on IPv6 on all traffic " "leaving a virtual machine, where the rule is applied. This is a 6-bit header " "with 21 valid values that denote the drop priority of a packet as it crosses " "networks should it meet congestion. It can also be used by firewalls to " "match valid or invalid traffic against its access control list." msgstr "" #: ../networking/services.rst:150 msgid "" "Port mirroring service involves sending a copy of packets entering or " "leaving one port to another port, which is usually different from the " "original destinations of the packets being mirrored. Tap-as-a-Service (TaaS) " "is an extension to the OpenStack networking service (neutron). It provides " "remote port mirroring capability for tenant virtual networks. This service " "has been primarily designed to help tenants (or the cloud administrator) " "debug complex virtual networks and gain visibility into their VMs, by " "monitoring the network traffic associated with them. TaaS honors tenant " "boundaries and its mirror sessions are capable of spanning across multiple " "compute and network nodes. It serves as an essential infrastructure " "component that can be utilized for supplying data to a variety of network " "analytics and security applications." msgstr "" #: ../networking/services.rst:165 msgid "Load balancing" msgstr "" #: ../networking/services.rst:167 msgid "" "Another feature in OpenStack Networking is Load-Balancer-as-a-service " "(LBaaS). The LBaaS 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." msgstr "" #: ../networking/services.rst:174 msgid "Firewalls" msgstr "" #: ../networking/services.rst:176 msgid "" "FW-as-a-Service (FWaaS) is considered an experimental feature for the Kilo " "release of OpenStack Networking. FWaaS addresses 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. Both Freescale and Intel developed third-party " "plug-ins as extensions in OpenStack Networking to support this component in " "the Kilo release. For more details on the administration of FWaaS, see " "`Firewall-as-a-Service (FWaaS) overview <https://docs.openstack.org/admin-" "guide/networking-introduction.html#firewall-as-a-service-fwaas-overview>`__ " "in the OpenStack Administrator Guide." msgstr "" #: ../networking/services.rst:187 msgid "" "During the design of an OpenStack Networking infrastructure it is important " "that you understand the current features and limitations of available " "network services. Understanding the boundaries of your virtual and physical " "networks will assist in adding required security controls in your " "environment." msgstr "" #: ../networking/services.rst:194 msgid "Network services extensions" msgstr "" #: ../networking/services.rst:196 msgid "" "A list of known plug-ins provided by the open source community or by SDN " "companies that work with OpenStack Networking is available at `OpenStack " "neutron plug-ins and drivers wiki page <https://wiki.openstack.org/wiki/" "Neutron_Plugins_and_Drivers>`__." msgstr "" #: ../networking/services.rst:202 msgid "Networking services limitations" msgstr "" #: ../networking/services.rst:204 msgid "OpenStack Networking has the following known limitations:" msgstr "" #: ../networking/services.rst:207 msgid "" "If nodes that run either neutron-l3-agent or neutron-dhcp-agent use " "overlapping IP addresses, those nodes must use Linux network namespaces. By " "default, the DHCP and L3 agents use Linux network namespaces and run in " "their own respective namespaces. However, if the host does not support " "multiple namespaces, the DHCP and L3 agents should be run on separate hosts. " "This is due to the fact that there is no isloation between the IP addresses " "created by the L3 agent and the DHCP agent." msgstr "" #: ../networking/services.rst:216 msgid "" "If network namespace support is not present, a further limitation of the L3 " "agent is that only a single logical router is supported." msgstr "" #: ../networking/services.rst:217 msgid "Overlapping IP addresses" msgstr "" #: ../networking/services.rst:220 msgid "" "OpenStack Networking supports multiple L3 and DHCP agents with load " "balancing. However, tight coupling of the location of the virtual machine is " "not supported. In other words, the default Virtual Machine scheduler will " "not take the location of the agents into account when creating virtual " "machines." msgstr "" #: ../networking/services.rst:224 msgid "Multi-host DHCP-agent" msgstr "" #: ../networking/services.rst:227 msgid "No IPv6 support for L3 agents" msgstr "" #: ../networking/services.rst:227 msgid "" "The neutron-l3-agent, used by many plug-ins to implement L3 forwarding, " "supports only IPv4 forwarding." msgstr "" #: ../object-storage.rst:5 msgid "" "OpenStack Object Storage (swift) service provides software that stores and " "retrieves data over HTTP. Objects (blobs of data) are stored in an " "organizational hierarchy that offers anonymous read-only access, ACL defined " "access, or even temporary access. Object Storage supports multiple token-" "based authentication mechanisms implemented via middleware." msgstr "" #: ../object-storage.rst:11 msgid "" "Applications store and retrieve data in Object Storage via an industry-" "standard HTTP RESTful API. Back end components of Object Storage follow the " "same RESTful model, although some APIs, such as those managing durability, " "are kept private to the cluster. For more details on the API see the " "`OpenStack Storage API <https://docs.openstack.org/api-ref/object-store/>`_." msgstr "" #: ../object-storage.rst:19 msgid "" "The components of Object Storage are grouped into the following primary " "groups:" msgstr "" #: ../object-storage.rst:21 msgid "Proxy services" msgstr "" #: ../object-storage.rst:22 msgid "Auth services" msgstr "" #: ../object-storage.rst:23 msgid "Storage services" msgstr "" #: ../object-storage.rst:25 ../object-storage.rst:125 msgid "Account service" msgstr "" #: ../object-storage.rst:26 ../object-storage.rst:128 msgid "Container service" msgstr "" #: ../object-storage.rst:27 msgid "Object service" msgstr "" #: ../object-storage.rst:32 msgid "" "An example diagram from the OpenStack Object Storage Administration Guide " "(2013)" msgstr "" #: ../object-storage.rst:37 msgid "" "An Object Storage installation does not have to be on the Internet and could " "also be a private cloud with the public switch a part of the organization's " "internal network infrastructure." msgstr "" #: ../object-storage.rst:42 msgid "Network security" msgstr "" #: ../object-storage.rst:44 msgid "" "Securing the Object Storage service begins with securing the networking " "component. If you skipped the networking chapter, return to :doc:" "`networking`." msgstr "" #: ../object-storage.rst:47 msgid "" "The rsync protocol is used between storage service nodes to replicate data " "for high availability. In addition, the proxy service communicates with the " "storage service when relaying data back and forth between the client end-" "point and the cloud environment." msgstr "" #: ../object-storage.rst:54 msgid "" "Object Storage does not employ encryption or authentication with inter-node " "communications. This is why you see a private switch or private network " "([V]LAN) in the architecture diagrams. This data domain should be separate " "from other OpenStack data networks as well. For further discussion on " "security domains please see :doc:`introduction/security-boundaries-and-" "threats`." msgstr "" #: ../object-storage.rst:62 msgid "" "Use a private (V)LAN network segment for your storage nodes in the data " "domain." msgstr "" #: ../object-storage.rst:65 msgid "" "This necessitates that the proxy nodes have dual interfaces (physical or " "virtual):" msgstr "" #: ../object-storage.rst:68 msgid "One as a public interface for consumers to reach." msgstr "" #: ../object-storage.rst:69 msgid "Another as a private interface with access to the storage nodes." msgstr "" #: ../object-storage.rst:71 msgid "The following figure demonstrates one possible network architecture." msgstr "" #: ../object-storage.rst:76 msgid "Object Storage network architecture with a management node (OSAM)" msgstr "" #: ../object-storage.rst:79 msgid "General service security" msgstr "" #: ../object-storage.rst:82 msgid "Run services as non-root user" msgstr "" #: ../object-storage.rst:84 msgid "" "We recommend that you configure the Object Storage service to run under a " "non-root (UID 0) service account. One recommendation is the user name " "``swift`` with the primary group ``swift``. Object Storage services include, " "for example, ``proxy-server``, ``container-server``, ``account-server``. " "Detailed steps for setup and configuration can be found in the `Add Object " "Storage chapter <https://docs.openstack.org/project-install-guide/object-" "storage/ocata/>`_ of the Installation Guide in the `OpenStack Documentation " "index <https://docs.openstack.org>`_." msgstr "" #: ../object-storage.rst:95 msgid "The above link defaults to the Ubuntu version." msgstr "" #: ../object-storage.rst:98 msgid "File permissions" msgstr "" #: ../object-storage.rst:100 msgid "" "The ``/etc/swift`` directory contains information about the ring topology " "and environment configuration. The following permissions are recommended:" msgstr "" #: ../object-storage.rst:109 msgid "" "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." msgstr "" #: ../object-storage.rst:114 msgid "Securing storage services" msgstr "" #: ../object-storage.rst:116 msgid "" "The following are the default listening ports for the various storage " "services:" msgstr "" #: ../object-storage.rst:122 msgid "Service name" msgstr "" #: ../object-storage.rst:123 msgid "Port" msgstr "" #: ../object-storage.rst:124 msgid "Type" msgstr "" #: ../object-storage.rst:126 msgid "6002" msgstr "" #: ../object-storage.rst:127 ../object-storage.rst:130 #: ../object-storage.rst:133 ../object-storage.rst:136 msgid "TCP" msgstr "" #: ../object-storage.rst:129 msgid "6001" msgstr "" #: ../object-storage.rst:131 msgid "Object Service" msgstr "" #: ../object-storage.rst:132 msgid "6000" msgstr "" #: ../object-storage.rst:134 msgid "Rsync [1]_" msgstr "" #: ../object-storage.rst:135 msgid "873" msgstr "" #: ../object-storage.rst:139 msgid "" "If ssync is used instead of rsync, the object service port is used for " "maintaining durability." msgstr "" #: ../object-storage.rst:144 msgid "" "Authentication does not take place at the storage nodes. If you are able to " "connect to a storage node on one of these ports, you can 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." msgstr "" #: ../object-storage.rst:151 msgid "Object Storage account terminology" msgstr "" #: ../object-storage.rst:153 msgid "" "An Object Storage account is not a user account or credential. The following " "explains the relations:" msgstr "" #: ../object-storage.rst:159 msgid "OpenStack Object Storage account" msgstr "" #: ../object-storage.rst:160 msgid "" "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 :ref:`Object_Storage_authentication`." msgstr "" #: ../object-storage.rst:164 msgid "OpenStack Object Storage containers" msgstr "" #: ../object-storage.rst:165 msgid "" "Collection of objects. Metadata on the container is available for ACLs. The " "meaning of ACLs is dependent on the authentication system used." msgstr "" #: ../object-storage.rst:168 msgid "OpenStack Object Storage objects" msgstr "" #: ../object-storage.rst:169 msgid "" "The actual data objects. ACLs at the object level are also possible with " "metadata and are dependent on the authentication system used." msgstr "" #: ../object-storage.rst:172 msgid "" "At each level, you 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 Identity service " "(keystone) and TempAuth. Custom authentication providers are also possible. " "See :ref:`object_storage_authentication` for more information." msgstr "" #: ../object-storage.rst:179 msgid "Securing proxy services" msgstr "" #: ../object-storage.rst:181 msgid "" "A proxy 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 " "nodes on the private storage network." msgstr "" #: ../object-storage.rst:190 msgid "HTTP listening port" msgstr "" #: ../object-storage.rst:192 msgid "" "You should configure your web service 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. " "Normally, clients using the HTTP REST API and performing authentication " "automatically retrieve the full REST API URL they require from 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. For example, a Client authenticates to https://" "identity.cloud.example.org:55443/v1/auth and gets a response with their " "authentication key and Storage URL (the URL of the proxy nodes or load " "balancer) of https://swift.cloud.example.org:44443/v1/AUTH_8980." msgstr "" #: ../object-storage.rst:205 msgid "" "The method for configuring your web server to start and run as a non-root " "user varies by web server and operating system." msgstr "" #: ../object-storage.rst:209 msgid "Load balancer" msgstr "" #: ../object-storage.rst:211 msgid "" "If the option of using Apache is not feasible, or for performance you wish " "to offload your TLS work, you may employ a dedicated network device load " "balancer. This is a common way to provide redundancy and load balancing when " "using multiple proxy nodes." msgstr "" #: ../object-storage.rst:216 msgid "" "If you choose to offload your TLS, ensure that the network link between the " "load balancer and your proxy nodes are 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." msgstr "" #: ../object-storage.rst:223 msgid "" "The authentication service you use, such as Identity service (keystone) or " "TempAuth, will determine how you configure a different URL in the responses " "to end-point clients so they use your load balancer instead of an individual " "proxy node." msgstr "" #: ../object-storage.rst:231 msgid "Object Storage authentication" msgstr "" #: ../object-storage.rst:233 msgid "" "Object Storage uses a WSGI model to provide for a middleware capability that " "not only provides general extensibility, but is also used for authentication " "of end-point clients. The authentication provider defines what roles and " "user types exist. Some use traditional user name and password credentials, " "while others may leverage API key tokens or even client-side x.509 " "certificates. Custom providers can be integrated in using custom middleware." msgstr "" #: ../object-storage.rst:240 msgid "" "Object Storage comes with two authentication middleware modules by default, " "either of which can be used as sample code for developing a custom " "authentication middleware." msgstr "" #: ../object-storage.rst:245 msgid "TempAuth" msgstr "" #: ../object-storage.rst:247 msgid "" "TempAuth is the default authentication for Object Storage. In contrast to " "Identity, it stores the user accounts, credentials, and metadata in object " "storage itself. More information can be found in the section `The Auth " "System <https://docs.openstack.org/swift/latest/overview_auth.html>`_ of the " "Object Storage (swift) documentation." msgstr "" #: ../object-storage.rst:254 msgid "Keystone" msgstr "" #: ../object-storage.rst:256 msgid "" "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 :doc:`identity`." msgstr "" #: ../object-storage.rst:261 msgid "Other notable items" msgstr "" #: ../object-storage.rst:263 msgid "" "In ``/etc/swift``, on every node, there is a ``swift_hash_path_prefix`` " "setting and a ``swift_hash_path_suffix`` setting. These are provided to " "reduce the chance of hash collisions for objects being stored and avert one " "user overwriting the data of another user." msgstr "" #: ../object-storage.rst:268 msgid "" "This value should be initially set with a cryptographically secure random " "number generator and consistent across all nodes. Ensure that it is " "protected with proper ACLs and that you have a backup copy to avoid data " "loss." msgstr "" #: ../secrets-management.rst:5 msgid "Secrets Management" msgstr "" #: ../secrets-management.rst:7 msgid "" "Operators protect sensitive information in cloud deployments by using " "various applications of cryptography. For example, encrypting data at rest " "or signing an image to prove that it has not been tampered with. In all " "cases, these cryptographic capabilities require some sort of *key material* " "in order to operate." msgstr "" #: ../secrets-management.rst:13 msgid "" "Secrets Management describes a group of technologies that are designed to " "protect key materials within a software system. Traditionally, key " "management involves deployment of `Hardware Security Modules (HSM) <https://" "en.wikipedia.org/wiki/Hardware_security_module>`_. These devices have been " "physically hardened against tampering." msgstr "" #: ../secrets-management.rst:18 msgid "" "As technology has advanced the number of secret things that need to be " "protected has increased beyond key materials to include certificate pairs, " "API keys, system passwords, signing keys and so on. This increase has " "created a need for a more scalable approach to key management, and resulted " "in the creation of a number of software services that provide scalable " "dynamic key management. This chapter describes the services that exist today " "and focus on those that are able to be integrated into OpenStack clouds." msgstr "" #: ../secrets-management/barbican.rst:3 msgid "Barbican" msgstr "" #: ../secrets-management/barbican.rst:6 ../secrets-management/castellan.rst:6 msgid "Overview" msgstr "" #: ../secrets-management/barbican.rst:8 msgid "" "Barbican is a REST API designed for the secure storage, provisioning and " "management of secrets such as passwords, encryption keys and X.509 " "certificates. It is aimed at being useful for all environments, including " "large ephemeral clouds." msgstr "" #: ../secrets-management/barbican.rst:13 msgid "" "Barbican is integrated with several OpenStack features, either directly or " "as a back end of `Castellan <https://wiki.openstack.org/wiki/Castellan>`_." msgstr "" #: ../secrets-management/barbican.rst:16 msgid "" "Barbican is often used as a key management system to enable use cases such " "as Image signature verification, Volume encryption. These use cases are " "outlined in the :doc:`secrets-management-use-cases`" msgstr "" #: ../secrets-management/barbican.rst:21 msgid "Barbican Role Based Access Control" msgstr "" #: ../secrets-management/barbican.rst:23 msgid "pending" msgstr "" #: ../secrets-management/barbican.rst:26 msgid "Secret store back ends" msgstr "" #: ../secrets-management/barbican.rst:28 msgid "" "The Key Manager service has a plugin architecture that allows the deployer " "to store secrets in one or more secret stores. Secret stores can be software-" "based, such as a software token, or hardware devices such as a hardware " "security module (HSM). This section describes the plugins that are currently " "available and discusses the security posture of each one. Plugins are " "enabled and configured with settings in the ``/etc/barbican/barbican.conf`` " "configuration file." msgstr "" #: ../secrets-management/barbican.rst:36 msgid "" "There are two types of plugins: crypto plugins and secret store plugins." msgstr "" #: ../secrets-management/barbican.rst:39 msgid "Crypto plugins" msgstr "" #: ../secrets-management/barbican.rst:41 msgid "" "Crypto plugins store secrets as encrypted blobs within the Barbican " "database. The plugin is invoked to encrypt the secret on secret storage, and " "decrypt the secret on secret retrieval. There are two flavors of storage " "plugins currently available: the Simple Crypto plugin and the PKCS#11 crypto " "plugin." msgstr "" #: ../secrets-management/barbican.rst:48 msgid "Simple crypto plugin" msgstr "" #: ../secrets-management/barbican.rst:50 msgid "" "The simple crypto plugin is configured by default in ``barbican.conf``. This " "plugin uses single symmetric key (KEK - or 'Key Encryption Key') which is " "stored in plain text in the ``barbican.conf`` file to encrypt and decrypt " "all secrets. This plugin is considered a less secure option and is only " "suitable for development and testing as the master key is stored within a " "config file in plain text, and is therefore not recommended for use in " "production deployments." msgstr "" #: ../secrets-management/barbican.rst:59 msgid "PKCS#11 crypto plugin" msgstr "" #: ../secrets-management/barbican.rst:61 msgid "" "The PKCS#11 crypto plugin can be used to interface with a Hardware Security " "Module (HSM) using the PKCS#11 protocol. Secrets are encrypted (and " "decrypted on retrieval) by a project specific Key Encryption Key (KEK). The " "KEK is protected (encrypted) with a Master KEK (MKEK). The MKEK resides in " "the HSM along with a HMAC. Since the different KEK is used for each project, " "and since the KEKs are stored inside a database in an encrypted form " "(instead of a plaintext in the configuration file) the PKCS#11 plugin is " "much more secure than the simple crypto plugin. It is the most popular back " "end amongst Barbican deployments." msgstr "" #: ../secrets-management/barbican.rst:72 msgid "Secret store plugins" msgstr "" #: ../secrets-management/barbican.rst:74 msgid "" "Secret store plugins interface with secure storage systems to store the " "secrets within those systems. There are three types of secret store plugins: " "the KMIP plugin, the Dogtag plugin, and the Vault plugin." msgstr "" #: ../secrets-management/barbican.rst:79 msgid "KMIP plugin" msgstr "" #: ../secrets-management/barbican.rst:81 msgid "" "The `Key Management Interoperability Protocol (KMIP) <https://www.oasis-open." "org/committees/tc_home.php?wg_abbrev=kmip>`_ secret store plugin is used to " "communicate with a KMIP-enabled device, such as a Hardware Security Module " "(HSM). The secret is securely stored in the KMIP-enabled device directly, " "rather than in the Barbican database. The Barbican database maintains a " "reference to the secret's location for later retrieval. The plugin can be " "configured to authenticate to the KMIP-enabled device using either a " "username and password, or using a client certificate. This information is " "stored in the Barbican configuration file." msgstr "" #: ../secrets-management/barbican.rst:91 msgid "Dogtag plugin" msgstr "" #: ../secrets-management/barbican.rst:93 msgid "" "The Dogtag secret store plugin is used to communicate with `Dogtag <http://" "pki.fedoraproject.org/wiki/PKI_Main_Page>`_. Dogtag is the upstream project " "corresponding to the Red Hat Certificate System, a Common Criteria/FIPS " "certified PKI solution that contains a Certificate Manager (CA) and a Key " "Recovery Authority (KRA) which is use to securely store secrets. The KRA " "stores secrets as encrypted blobs in its internal database, with the master " "encryption keys being stored either in a software-based NSS security " "database, or in a Hardware Security Module (HSM). The software-based NSS " "database configuration provides a secure option for deployments that do not " "wish to use a HSM. The KRA is a component of FreeIPA, therefore it is " "possible to configure the plugin with a FreeIPA server. More detailed " "instructions on how to set up Barbican with FreeIPA are provided `in the " "following blog post <https://vakwetu.wordpress.com/2015/11/30/barbican-and-" "dogtagipa/>`_." msgstr "" #: ../secrets-management/barbican.rst:107 msgid "Vault plugin" msgstr "" #: ../secrets-management/barbican.rst:109 msgid "" "`Vault <https://www.vaultproject.io/>`_ is a secret storage developed by " "Hashicorp for securely accessing secrets and other objects, such as API " "keys, passwords, or certificates. Vault provides a unified interface to any " "secret, while providing tight access control and recording a detailed audit " "log. The enterprise version of Vault also allows to integrate with HSM for " "auto-unseal, provide FIPS KeyStorage and entropy augmentation. However, the " "downside of the Vault plugin is that it does not support multitenancy, thus " "all secrets will be stored under the same `Key/Value secret engine <https://" "www.vaultproject.io/docs/secrets/kv/kv-v2>`_. mountpoint." msgstr "" #: ../secrets-management/barbican.rst:121 msgid "Threat analysis" msgstr "" #: ../secrets-management/barbican.rst:123 msgid "" "The Barbican team worked with the OpenStack Security Project to perform a " "security review of a best practise Barbican deployment. The objective of the " "security review is to identify weaknesses and defects in the design and " "architecture of services, and propose controls or fixes to resolve these " "issues." msgstr "" #: ../secrets-management/barbican.rst:129 msgid "" "The Barbican threat analysis identified eight security findings and two " "recommendations to improve the security of a barbican deployment. These " "results can be reviewed in the `security analysis repo <https://opendev.org/" "openstack/security-analysis/src/commit/ac43025/doc/source/artifacts/barbican/" "newton>`_., along with the Barbican architecture diagram and architecture " "description page." msgstr "" #: ../secrets-management/castellan.rst:3 msgid "Castellan" msgstr "" #: ../secrets-management/castellan.rst:8 msgid "" "Castellan is a generic Key Manager interface developed by the Barbican team. " "It enables projects to use a configurable key manager that can be deployment " "specific." msgstr "" #: ../secrets-management/checklist.rst:10 msgid "" "Check-Key-Manager-01: Is the ownership of config files set to root/barbican?" msgstr "" #: ../secrets-management/checklist.rst:12 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally, modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues resulting in " "a denial of service to the other end users. User ownership of such critical " "configuration files must be set to root and group ownership must be set to " "barbican. Additionally, the containing directory should have the same " "ownership to ensure that new files are owned correctly." msgstr "" #: ../secrets-management/checklist.rst:30 msgid "" "**Pass:** If user and group ownership of all these config files is set to " "root and barbican respectively. The above commands show output of root / " "barbican." msgstr "" #: ../secrets-management/checklist.rst:34 msgid "" "**Fail:** If the above commands do not return any output, it is possible " "that the user and group ownership may have been set to any user other than " "root or any group other than barbican." msgstr "" #: ../secrets-management/checklist.rst:41 msgid "" "Check-Key-Manager-02: Are strict permissions set for configuration files?" msgstr "" #: ../secrets-management/checklist.rst:43 msgid "" "Similar to the previous check, we recommended to set strict access " "permissions for such configuration files." msgstr "" #: ../secrets-management/checklist.rst:59 msgid "" "**Pass:** If permissions are set to 640 or stricter, or the containing " "directory is set to 750. The permissions of 640 translates into owner r/w, " "group r, and no rights to others, for example \"u=rw,g=r,o=\"." msgstr "" #: ../secrets-management/checklist.rst:64 msgid "" "With :ref:`check_key_mgr_01` and permissions set to 640, root has read/write " "access and barbican has read access to these configuration files. The access " "rights can also be validated using the following command. This command will " "only be available on your system if it supports ACLs." msgstr "" #: ../secrets-management/checklist.rst:80 msgid "**Fail:** If permissions are set greater than 640." msgstr "" #: ../secrets-management/checklist.rst:85 msgid "Check-Key-Manager-03: Is OpenStack Identity used for authentication?" msgstr "" #: ../secrets-management/checklist.rst:87 msgid "" "OpenStack supports various authentication strategies like ``noauth`` and " "``keystone``. If the ``noauth`` strategy is used then the users can interact " "with OpenStack services without any authentication. This could be a " "potential risk since an attacker might gain unauthorized access to the " "OpenStack components. We strongly recommend that all services must be " "authenticated with keystone using their service accounts." msgstr "" #: ../secrets-management/checklist.rst:94 msgid "" "**Pass:** If the parameter ``authtoken`` is listed under the ``pipeline:" "barbican-api-keystone`` section in ``barbican-api-paste.ini``." msgstr "" #: ../secrets-management/checklist.rst:97 msgid "" "**Fail:** If the parameter ``authtoken`` is missing under the ``pipeline:" "barbican-api-keystone`` section in ``barbican-api-paste.ini``." msgstr "" #: ../secrets-management/checklist.rst:103 msgid "Check-Key-Manager-04: Is TLS enabled for authentication?" msgstr "" #: ../secrets-management/checklist.rst:111 msgid "" "**Pass:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/barbican/barbican.conf`` is set " "to Identity API endpoint starting with ``https://`` and value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/barbican/barbican.conf`` is set to ``False``." msgstr "" #: ../secrets-management/checklist.rst:117 msgid "" "**Fail:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/barbican/barbican.conf`` is not " "set to Identity API endpoint starting with ``https://`` or value of " "parameter ``insecure`` under the same ``[keystone_authtoken]`` section in " "the same ``/etc/barbican/barbican.conf`` is set to ``True``." msgstr "" #: ../secrets-management/faq.rst:3 msgid "Frequently Asked Questions" msgstr "" #: ../secrets-management/faq.rst:5 msgid "What is the recommended way to securely store secrets in OpenStack?" msgstr "" #: ../secrets-management/faq.rst:7 msgid "" "The recommended way to securely store and manage secrets in OpenStack is to " "use Barbican." msgstr "" #: ../secrets-management/faq.rst:10 msgid "Why should I use Barbican?" msgstr "" #: ../secrets-management/faq.rst:12 msgid "" "Barbican is an OpenStack service that is multi-tenant aware and that uses " "Keystone tokens for authentication. This means that access to secrets is " "controlled via OpenStack policies for tenants and RBAC roles." msgstr "" #: ../secrets-management/faq.rst:16 msgid "" "Barbican has multiple pluggable back-ends which can communicate with " "software and hardware based security modules using PKCS#11 or KMIP." msgstr "" #: ../secrets-management/faq.rst:19 msgid "What if I don't want to use Barbican?" msgstr "" #: ../secrets-management/faq.rst:21 msgid "" "In an Openstack context, there are two types of secrets that need to be " "managed - those that require a keystone token for access, and those that do " "not." msgstr "" #: ../secrets-management/faq.rst:25 msgid "" "An example of those secrets that require keystone authentication are " "passwords and keys owned by specific projects. These include, for instance, " "encryption keys for a project's encrypted cinder volumes or signing keys for " "a project's glance images." msgstr "" #: ../secrets-management/faq.rst:30 msgid "" "Examples of secrets that does not require a keystone token to access are " "passwords for service users in service configuration files, or encryption " "keys that do not belong to any particular project." msgstr "" #: ../secrets-management/faq.rst:34 msgid "Secrets that require a keystone token should be stored using Barbican." msgstr "" #: ../secrets-management/faq.rst:36 msgid "" "Secrets that do not require keystone authentication can be stored in any " "secret store that implements the simple key storage API that is exposed " "through Castellan. This also includes Barbican." msgstr "" #: ../secrets-management/faq.rst:40 msgid "How can I use Vault, Keywhiz, Custodia etc ...?" msgstr "" #: ../secrets-management/faq.rst:42 msgid "" "The key manager of your choice can be used with Openstack if Castellan " "plugin has been written for that key manager. Once that plugin has been " "written, it is relatively trivial to use the plugin either directly or " "behind Barbican." msgstr "" #: ../secrets-management/faq.rst:47 msgid "" "Currently, Vault and Custodia plugins are being developed for the Queens " "cycle." msgstr "" #: ../secrets-management/related-projects.rst:3 msgid "Related Openstack Projects" msgstr "" #: ../secrets-management/related-projects.rst:5 msgid "" "`Castellan <https://docs.openstack.org/castellan/latest/>`_ is a library " "that provides a simple common interface to store, generate and retrieve " "secrets. It is used by most Openstack services for secret management. As a " "library, Castellan does not provide a secret store in and of itself. Rather, " "a back-end implementation is required to be deployed." msgstr "" #: ../secrets-management/related-projects.rst:11 msgid "" "Note that Castellan does not provide any authentication. It simply passes " "through the authentication credentials (a Keystone token, for example) to " "the back-end." msgstr "" #: ../secrets-management/related-projects.rst:15 msgid "" "`Barbican <https://docs.openstack.org/barbican/latest/>`_ is an OpenStack " "service that provides a back-end for Castellan. Barbican expects and " "authenticates a keystone authentication token to identify the user and " "project accessing or storing a secret. It then applies policy to determine " "if access is permitted. It also provides a number of additional useful " "features to improve secret management including quotas, per-secret ACLs, " "tracking of secret consumers and grouping of secrets in secret containers. " "Octavia, for example, integrates directly with Barbican (instead of " "Castellan) to take advantage of some of these features." msgstr "" #: ../secrets-management/related-projects.rst:24 msgid "" "Barbican has a number of back-end plugins that can be used to securely store " "secrets in local databases or in HSMs." msgstr "" #: ../secrets-management/related-projects.rst:27 msgid "" "Currently, Barbican is the only available back-end for Castellan. There are, " "however, several back-ends that are being developed, including KMIP, Dogtag, " "Hashicorp Vault and Custodia. For those deployers who do not wish to deploy " "Barbican and have relatively simple key management needs, using one of these " "back-ends could be a viable alternative. What would be lacking though is " "multi-tenancy and tenant-policy enforcement when retrieving the secrets, as " "well as any of the extra features mentioned above." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:3 msgid "Use Cases" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:8 msgid "" "Verification of image signatures assures that an image is not replaced or " "changed since the time of original upload. The image signature verification " "feature uses Castellan as its key manager for storing cryptographic " "signatures. An image signature and certificate UUID is uploaded along with " "the image to the Image (glance) service. Glance verifies the signature after " "retrieving the certificate from the key manager. When the image is booted, " "the Compute service (nova) verifys the signature after it retrieves the " "certificate from the key manager." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:17 msgid "" "For more details, see the `Trusted Images documentation <https://docs." "openstack.org/security-guide/instance-management/security-services-for-" "instances.html#trusted-images/>`_." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:21 #: ../tenant-data/data-encryption.rst:36 msgid "Volume encryption" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:23 msgid "" "The volume encryption feature provides encryption of data-at-rest using " "Castellan. When a user creates an encrypted volume type, and creates a " "volume using that type, the Block Storage (cinder) service requests the key " "manager to create a key to be associated with that volume. When the volume " "is attached to an instance, nova retrieves the key." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:29 msgid "" "For more details, see the `Data Encryption section <https://docs.openstack." "org/security-guide/tenant-data/data-encryption.html>`_. and `Volume " "encryption <https://docs.openstack.org/ocata/config-reference/block-storage/" "volume-encryption.html>`_." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:33 #: ../tenant-data/data-encryption.rst:59 msgid "Ephemeral disk encryption" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:35 msgid "" "The ephemeral disk encryption feature addresses data privacy. The ephemeral " "disk is a temporary work space used by the virtual host operating system. " "Without encryption, sensitive user information could be accessed on this " "disk, and vestigial information could remain after the disk is unmounted." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:41 msgid "" "The ephemeral disk encryption feature, can interface with a key management " "service through a secure wrapper and support data isolation by providing " "ephemeral disk encryption keys on a per-tenant basis. Back-end key storage " "is recommended for enhanced security (for example, an HSM or KMIP server can " "be used as a barbican back-end secret store)." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:47 msgid "" "For more details, see the `Ephemeral disk encryption documentation <https://" "docs.openstack.org/security-guide/tenant-data/data-encryption.html#ephemeral-" "disk-encryption>`_." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:51 msgid "Sahara" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:53 msgid "" "Sahara generates and stores several passwords during the course of " "operation. To harden sahara’s usage of passwords it can be instructed to use " "an external key manager for storage and retrieval of these secrets. To " "enable this feature, there must first be an OpenStack Key Manager service " "deployed within the stack." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:59 msgid "" "With a Key Manager service deployed on the stack, sahara must be configured " "to enable the external storage of secrets. Sahara uses the Castellan library " "to interface with the OpenStack Key Manager service. This library provides " "configurable access to a key manager." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:64 msgid "" "For more information, see the `Sahara advanced configuration guide <https://" "docs.openstack.org/sahara/latest/admin/advanced-configuration-guide." "html#external-key-manager-usage>`_." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:67 msgid "Magnum" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:69 msgid "" "To provide access to Docker Swarm or Kubernetes using the native clients " "(``docker`` or ``kubectl`` respectively) magnum uses TLS certificates. To " "store the certificates, it is recommended to use Barbican , or the Magnum " "Database (``x590keypair``)." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:74 msgid "" "A local directory can also be used (``local``), but is considered insecure " "and not suitable for a production environment." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:77 msgid "" "For more details on setting up a certificate manager for Magnum, see the " "`Container Infrastructure Management service <https://docs.openstack.org/" "magnum/latest/install/>`_ documentation." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:82 msgid "Octavia/LBaaS" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:84 msgid "" "The LBaaS (Load-Balancer-as-a-Service) feature of Neutron and the Octavia " "project need certificates and their private keys to provide load balancing " "for TLS connections. Barbican can be used to store this sensitive " "information." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:89 msgid "" "For more details, see `How to create a TLS Loadbalancer <https://wiki." "openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer>`_ and " "`Deploy a TLS-terminated HTTPS load balancer <https://docs.openstack.org/" "octavia/latest/user/guides/basic-cookbook.html#deploy-a-tls-terminated-https-" "load-balancer>`_." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:94 msgid "Swift" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:96 msgid "" "Symmetric keys can be used to encrypt Swift containers to mitigate the risk " "of users data being read if an unauthorised party were to gain physical " "access to a disk." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:100 msgid "" "For more details, see `Object Encryption <https://docs.openstack.org/swift/" "pike/overview_encryption.html>`_ within the official swift documentation." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:104 msgid "Passwords in Config Files" msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:106 msgid "" "The configuration files for the OpenStack services contain a number of " "passwords which are in plain text. These include, for instance, the " "passwords used by service users to authenticate to keystone to validate " "keystone tokens." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:111 msgid "" "There is no current solution to obfuscate these passwords. It is recommended " "that these files be appropriately secured by file permissions." msgstr "" #: ../secrets-management/secrets-management-use-cases.rst:114 msgid "" "There is currently an effort underway to store these secrets in a Castellan " "back-end and then have oslo.config use Castellan to retrieve these secrets." msgstr "" #: ../secrets-management/summary-of-technologies.rst:3 msgid "Summary of existing technologies" msgstr "" #: ../secrets-management/summary-of-technologies.rst:5 msgid "" "Within OpenStack, there are two solutions recommended for secrets managment, " "those being `Barbican <https://docs.openstack.org/barbican/latest/>`_ and " "`Castellan <https://docs.openstack.org/castellan/latest/>`_. This chapter " "will outline different scenarios to help an operator make a choice on which " "key manager to use." msgstr "" #: ../secrets-management/summary-of-technologies.rst:10 msgid "" "A third non supported method is Fixed/Hardcoded keys. It is known that some " "OpenStack services have the option to specify keys in their configuration " "files. This is the least secure way to operate and we do not recommend this " "for any sort of production environment." msgstr "" #: ../secrets-management/summary-of-technologies.rst:15 msgid "" "Other solutions exist including KeyWhiz, Confidant, Conjur, EJSON, Knox and " "Red October, however it is outside the scope of this document to cover every " "Key Manager available." msgstr "" #: ../secrets-management/summary-of-technologies.rst:19 msgid "" "For storage of secrets, it's strongly recommended to a Hardware Security " "Modules (HSMs). HSMs can come in multiple forms. The traditional device is a " "rack mounted appliance such as the one `shown in the following blog post " "<https://vakwetu.wordpress.com/2015/11/30/barbican-and-dogtagipa/>`_." msgstr "" #: ../secure-communication.rst:3 msgid "Secure communication" msgstr "" #: ../secure-communication.rst:5 msgid "" "Inter-device communication is a serious security concern. Between large " "project errors, such as Heartbleed, or more advanced attacks such as BEAST " "and CRIME, secure methods of communication over a network are becoming more " "important. It should be remembered, however that encryption should be " "applied as one part of a larger security strategy. The compromise of an " "endpoint means that an attacker no longer needs to break the encryption " "used, but is able to view and manipulate messages as they are processed by " "the system." msgstr "" #: ../secure-communication.rst:15 msgid "" "This chapter will review several features around configuring TLS to secure " "both internal and external resources, and will call out specific categories " "of systems that should be given specific attention." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:3 msgid "Introduction to TLS and SSL" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:5 msgid "" "There are situations where there is a security requirement to assure the " "confidentiality or integrity of network traffic in an OpenStack deployment. " "This is generally achieved using cryptographic measures, such as the " "Transport Layer Security (TLS) protocol." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:11 msgid "" "In a typical deployment all traffic transmitted over public networks is " "secured, but security best practice dictates that internal traffic must also " "be secured. It is insufficient to rely on security domain separation for " "protection. If an attacker gains access to the hypervisor or host resources, " "compromises an API endpoint, or any other service, they must not be able to " "easily inject or capture messages, commands, or otherwise affect the " "management capabilities of the cloud." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:20 msgid "" "All domains should be secured with TLS, including the management domain " "services and intra-service communications. 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." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:26 msgid "" "Due to the published vulnerabilities in the Secure Sockets Layer (SSL) " "protocols, we strongly recommend that TLS is used in preference to SSL, and " "that SSL is disabled in all cases, unless compatibility with obsolete " "browsers or libraries is required." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:31 msgid "" "Public Key Infrastructure (PKI) is the framework for securing communication " "in a network. It consists of a set of systems and processes to ensure " "traffic can be sent securely while validating the identity of the parties. " "The PKI profile described here is the Internet Engineering Task Force (:term:" "`IETF`) Public Key Infrastructure (PKIX) profile developed by the PKIX " "working group. The core components of PKI are:" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:40 msgid "" "Signed public key certificates are data structures that have verifiable data " "of an entity, its public key along with some other attributes. These " "certificates are issued by a Certificate Authority (CA). As the certificates " "are signed by a CA that is trusted, once verified, the public key associated " "with the entity is guaranteed to be associated with the said entity. The " "most common standard used to define these certificates is the :term:`X.509` " "standard. The :term:`X.509` v3 which is the current standard is described in " "detail in `RFC5280 <http://tools.ietf.org/html/5280>`_. Certificates are " "issued by CAs as a mechanism to prove the identity of online entities. The " "CA digitally signs the certificate by creating a message digest from the " "certificate and encrypting the digest with its private key." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:52 msgid "Digital Certificates" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:55 msgid "" "User, process, or system that is the subject of a certificate. The end " "entity sends its certificate request to a Registration Authority (RA) for " "approval. If approved, the RA forwards the request to a Certification " "Authority (CA). The Certification Authority verifies the request and if the " "information is correct, a certificate is generated and signed. This signed " "certificate is then send to a Certificate Repository." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:61 msgid "End entity" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:64 msgid "" "The endpoint that receives the digitally signed certificate that is " "verifiable with reference to the public key listed on the certificate. The " "relying party should be in a position to verify the certificate up the " "chain, ensure that it is not present in the :term:`CRL` and also must be " "able to verify the expiry date on the certificate." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:68 msgid "Relying party" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:71 msgid "" "CA is a trusted entity, both by the end party and the party that relies upon " "the certificate for certification policies, management handling, and " "certificate issuance." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:73 msgid "Certification Authority (:term:`CA <certificate authority (CA)>`)" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:76 msgid "" "An optional system to which a CA delegates certain management functions, " "this includes functions such as, authentication of end entities before they " "are issued a certificate by a CA." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:78 msgid "Registration Authority (RA)" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:81 msgid "" "A Certificate Revocation List (CRL) is a list of certificate serial numbers " "that have been revoked. End entities presenting these certificates should " "not be trusted in a PKI model. Revocation can happen because of several " "reasons for example, key compromise, CA compromise." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:84 msgid "Certificate Revocation Lists (CRL)" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:87 msgid "" "An optional system to which a CA delegates the publication of certificate " "revocation lists." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:88 msgid "CRL issuer" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:91 msgid "" "Where the end entity certificates and certificate revocation lists are " "stored and looked up - sometimes referred to as the *certificate bundle*." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:93 msgid "Certificate Repository" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:95 msgid "" "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 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." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:106 msgid "Certification authorities" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:108 msgid "" "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." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:117 msgid "" "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 recognized by another." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:127 msgid "" "Certificates used to support 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 " "Let's Encrypt, Verisign and Thawte but many others exist." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:135 msgid "" "There are management, policy, and technical challenges around creating and " "signing certificates. This 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." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:141 msgid "TLS libraries" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:143 msgid "" "Components, services, and applications within the OpenStack ecosystem or " "dependencies of OpenStack are implemented or can be configured to use TLS " "libraries. The TLS and HTTP services within OpenStack are typically " "implemented using OpenSSL which 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." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:152 msgid "Cryptographic algorithms, cipher modes, and protocols" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:154 msgid "" "We recommend that a minimum of TLS 1.2 be used. Older versions such as TLS " "1.0, 1.1, and all versions of SSL (TLS's predecessor) are vulnerable to " "multiple publicly known attacks and therefore must not be used. TLS 1.2 may " "be used for broad client compatibility, however exercise caution when " "enabling this protocol. Only enable TLS version 1.1 if there is a mandatory " "compatibility requirement and you are aware of the risks involved." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:161 msgid "" "When you are using TLS 1.2 and control both the clients and the server, the " "cipher suite should be limited to ``ECDHE-ECDSA-AES256-GCM-SHA384``. In " "circumstances where you do not control both endpoints and are using TLS 1.1 " "or 1.2 the more general ``HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!" "CAMELLIA`` is a reasonable cipher selection." msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:168 msgid "" "However, 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. There are some authoritative references we would like to recommend " "for further information:" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:174 msgid "" "`National Security Agency, Suite B Cryptography <http://www.nsa.gov/ia/" "programs/suiteb_cryptography/index.shtml>`_" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:175 msgid "" "`OWASP Guide to Cryptography <https://www.owasp.org/index.php/" "Guide_to_Cryptography>`_" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:176 msgid "" "`OWASP Transport Layer Protection Cheat Sheet <https://www.owasp.org/index." "php/Transport_Layer_Protection_Cheat_Sheet>`_" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:177 msgid "" "`SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate " "trust model enhancements <http://www.ieee-security.org/TC/SP2013/" "papers/4977a511.pdf>`_" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:178 msgid "" "`The Most Dangerous Code in the World: Validating SSL Certificates in Non-" "Browser Software <http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>`_" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:179 msgid "" "`OpenSSL and FIPS 140-2 <http://www.openssl.org/docs/fips/fipsnotes.html>`_" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:182 msgid "Summary" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:184 msgid "" "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 TLS certificates, keys, and CAs. " "Subsequent sections discuss the following services:" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:190 msgid "Compute API endpoints" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:191 msgid "Identity API endpoints" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:192 msgid "Networking API endpoints" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:193 msgid "Storage API endpoints" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:194 msgid "Messaging server" msgstr "" #: ../secure-communication/introduction-to-ssl-and-tls.rst:195 msgid "Database server" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:3 msgid "Secure reference architectures" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:5 msgid "" "We recommend using SSL/TLS on both public networks and management networks " "in :doc:`tls-proxies-and-http-services`. However, if actually deploying SSL/" "TLS everywhere is too difficult, we recommend evaluating your OpenStack SSL/" "TLS needs and following one of the architectures discussed here." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:11 msgid "" "The first thing one should do when evaluating their OpenStack SSL/TLS needs " "is to identify the threats. You can divide these threats into external and " "internal attacker categories, but the lines tend to get blurred since " "certain components of OpenStack operate on both the public and management " "networks." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:17 msgid "" "For publicly facing services, the threats are pretty straightforward. Users " "will be authenticating against horizon and keystone with their username and " "password. Users will also be accessing the API endpoints for other services " "using their keystone tokens. If this network traffic is unencrypted, " "passwords and tokens can be intercepted by an attacker using a man-in-the-" "middle attack. The attacker can then use these valid credentials to perform " "malicious operations. All real deployments should be using SSL/TLS to " "protect publicly facing services." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:27 msgid "" "For services that are deployed on management networks, the threats aren't so " "clear due to the bridging of security domains with network security. There " "is always the chance that an administrator with access to the management " "network decides to do something malicious. SSL/TLS isn't going to help in " "this situation if the attacker is allowed to access the private key. Not " "everyone on the management network would be allowed to access the private " "key of course, so there is still value in using SSL/TLS to protect yourself " "from internal attackers. Even if everyone that is allowed to access your " "management network is 100% trusted, there is still a threat that an " "unauthorized user gains access to your internal network by exploiting a " "misconfiguration or software vulnerability. One must keep in mind that you " "have users running their own code on instances in the OpenStack Compute " "nodes, which are deployed on the management network. If a vulnerability " "allows them to break out of the hypervisor, they will have access to your " "management network. Using SSL/TLS on the management network can minimize the " "damage that an attacker can cause." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:49 msgid "SSL/TLS proxy in front" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:51 msgid "" "It is generally accepted that it is best to encrypt sensitive data as early " "as possible and decrypt it as late as possible. Despite this best practice, " "it seems that it's common to use a SSL/TLS proxy in front of the OpenStack " "services and use clear communication afterwards as shown below:" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:59 msgid "Some of the concerns with the use of SSL/TLS proxies as pictured above:" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:62 msgid "" "Native SSL/TLS in OpenStack services does not perform/scale as well as SSL " "proxies (particularly for Python implementations like Eventlet)." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:66 msgid "" "Native SSL/TLS in OpenStack services not as well scrutinized/ audited as " "more proven solutions." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:69 msgid "" "Native SSL/TLS configuration is difficult (not well documented, tested, or " "consistent across services)." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:72 msgid "" "Privilege separation (OpenStack service processes should not have direct " "access to private keys used for SSL/TLS)." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:75 msgid "Traffic inspection needs for load balancing." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:77 msgid "" "All of the above are valid concerns, but none of them prevent SSL/TLS from " "being used on the management network. Let's consider the next deployment " "model." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:84 msgid "SSL/TLS on same physical hosts as API endpoints" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:88 msgid "" "This is very similar to the :ref:`secure-communication-proxy-in-front` but " "the SSL/TLS proxy is on the same physical system as the API endpoint. The " "API endpoint would be configured to only listen on the local network " "interface. All remote communication with the API endpoint would go through " "the SSL/TLS proxy. With this deployment model, we address a number of the " "bullet points in :ref:`secure-communication-proxy-in-front` A proven SSL " "implementation that performs well would be used. The same SSL proxy software " "would be used for all services, so SSL configuration for the API endpoints " "would be consistent. The OpenStack service processes would not have direct " "access to the private keys used for SSL/TLS, as you would run the SSL " "proxies as a different user and restrict access using permissions (and " "additionally mandatory access controls using something like SELinux). We " "would ideally have the API endpoints listen on a Unix socket such that we " "could restrict access to it using permissions and mandatory access controls " "as well. Unfortunately, this does not seem to work currently in Eventlet " "from our testing. It is a good future development goal." msgstr "" #: ../secure-communication/secure-reference-architectures.rst:110 msgid "SSL/TLS over load balancer" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:112 msgid "" "What about high availability or load balanced deployments that need to " "inspect traffic? The previous deployment model (:ref:`secure-communication-" "proxy-on-same-physical-hosts-as-api-endpoints`) would not allow for deep " "packet inspection since the traffic is encrypted. If the traffic only needs " "to be inspected for basic routing purposes, it might not be necessary for " "the load balancer to have access to the unencrypted traffic. HAProxy has the " "ability to extract the SSL/TLS session ID during the handshake, which can " "then be used to achieve session affinity ( `session ID configuration details " "here <http://blog.exceliance.fr/2011/07/04/maintain-affinity-based-on-ssl-" "session-id/>`_ ). HAProxy can also use the TLS Server Name Indication (SNI) " "extension to determine where traffic should be routed to ( `SNI " "configuration details here <http://blog.exceliance.fr/2012/04/13/enhanced-" "ssl-load-balancing-with-server-name-indication-sni-tls-extension/>`_ ). " "These features likely cover some of the most common load balancer needs. " "HAProxy would be able to just pass the HTTPS traffic straight through to the " "API endpoint systems in this case:" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:132 msgid "Cryptographic separation of external and internal environments" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:134 msgid "" "What if you want cryptographic separation of your external and internal " "environments? A public cloud provider would likely want their public facing " "services (or proxies) to use certificates that are issued by a CA that " "chains up to a trusted Root CA that is distributed in popular web browser " "software for SSL/TLS. For the internal services, one might want to instead " "use their own PKI to issue certificates for SSL/TLS. This cryptographic " "separation can be accomplished by terminating SSL at the network boundary, " "then re-encrypting using the internally issued certificates. The traffic " "will be unencrypted for a brief period on the public facing SSL/TLS proxy, " "but it will never be transmitted over the network in the clear. The same re-" "encryption approach that is used to achieve cryptographic separation can " "also be used if deep packet inspection is really needed on a load balancer. " "Here is what this deployment model would look like:" msgstr "" #: ../secure-communication/secure-reference-architectures.rst:152 msgid "" "As with most things, there are trade-offs. The main trade-off is going to be " "between security and performance. Encryption has a cost, but so does being " "hacked. The security and performance requirements are going to be different " "for every deployment, so how SSL/TLS is used will ultimately be an " "individual decision." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:3 msgid "TLS proxies and HTTP services" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:5 msgid "" "OpenStack endpoints are HTTP services providing APIs to both end-users on " "public networks and to other OpenStack services on the management network. " "It is highly recommended that all of these requests, both internal and " "external, operate over TLS. To achieve this goal, API services must be " "deployed behind a TLS proxy that can establish and terminate TLS sessions. " "The following table offers a non-exhaustive list of open source software " "that can be used for this purpose:" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:13 msgid "`Pound <http://www.apsis.ch/pound>`_" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:14 msgid "`Stud <https://github.com/bumptech/stud>`_" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:15 msgid "`Nginx <http://nginx.org/>`_" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:16 msgid "`Apache httpd <http://www.apache.org/>`_" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:18 msgid "" "In cases where software termination offers insufficient performance, " "hardware accelerators may be worth exploring as an alternative option. It is " "important to be mindful of the size of requests that will be processed by " "any chosen TLS proxy." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:24 msgid "Examples" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:26 msgid "" "Below we provide sample recommended configuration settings for enabling TLS " "in some of the more popular web servers/TLS terminators." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:29 msgid "" "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: " "`ciphers <https://www.openssl.org/docs/manmaster/man1/ciphers.html>`_." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:38 msgid "or" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:44 msgid "" "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." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:50 msgid "" "Ephemeral Elliptic Curve Diffie-Hellman (abbreviated as EECDH and ECDHE)." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:52 msgid "" "Ephemeral Diffie-Hellman (abbreviated either as EDH or DHE) uses prime field " "groups." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:55 msgid "" "Both approaches provide `Perfect Forward Secrecy (PFS) <https://en.wikipedia." "org/wiki/Forward_secrecy>`_. See :ref:`secure-communication-perfect-forward-" "secrecy` for additional discussion on properly configuring PFS." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:60 msgid "" "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." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:64 msgid "``kEECDH:kEDH``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:67 msgid "" "Cipher suites using the `RSA <https://en.wikipedia.org/wiki/RSA_" "%28cryptosystem%29>`_ exchange, authentication or either respectively." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:69 msgid "``kRSA``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:72 msgid "" "Selects highest possible security cipher in the negotiation phase. These " "typically have keys of length 128 bits or longer." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:73 msgid "``HIGH``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:76 msgid "" "No RC4. RC4 has flaws in the context of TLS V3. See `On the Security of RC4 " "in TLS and WPA <http://cr.yp.to/streamciphers/rc4biases-20130708.pdf>`_." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:77 msgid "``!RC4``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:80 msgid "" "No MD5. MD5 is not collision resistant, and thus not acceptable for Message " "Authentication Codes (MAC) or signatures." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:81 msgid "``!MD5``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:84 msgid "Disallows clear text." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:84 msgid "``!aNULL:!eNULL``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:87 msgid "" "Disallows export encryption algorithms, which by design tend to be weak, " "typically using 40 and 56 bit keys." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:90 msgid "" "US Export restrictions on cryptography systems have been lifted and no " "longer need to be supported." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:91 msgid "``!EXP``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:94 msgid "" "Disallows low (56 or 64 bit long keys) and medium (128 bit long keys) " "ciphers because of their vulnerability to brute force attacks (example 2-" "DES). This rule still permits 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." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:100 msgid "``!LOW:!MEDIUM``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:103 msgid "" "Protocols are enabled/disabled through SSL_CTX_set_options. We recommend " "disabling SSLv2/v3 and enabling TLS." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:104 msgid "``Protocols``" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:107 msgid "Pound" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:109 msgid "" "This Pound example enables ``AES-NI`` acceleration, which helps to improve " "performance on systems with processors that support this feature. The " "default configuration file is ``/etc/pound/pound.cfg`` on Ubuntu, ``/etc/" "pound.cfg`` on RHEL, CentOS, openSUSE, and SUSE Linux Enterprise." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:168 msgid "Stud" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:170 msgid "" "The *ciphers* line can be tweaked based on your needs, however this is a " "reasonable starting place. The default configuration file is located in the " "``/etc/stud`` directory. However, it is not provided by default." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:213 msgid "Nginx" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:215 msgid "" "This :term:`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. The default configuration file is ``/etc/nginx/" "nginx.conf``." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:239 msgid "Apache" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:241 msgid "" "The default configuration file is ``/etc/apache2/apache2.conf`` on Ubuntu, " "``/etc/httpd/conf/httpd.conf`` on RHEL and CentOS, ``/etc/apache2/httpd." "conf`` on openSUSE and SUSE Linux Enterprise." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:272 msgid "" "Compute API SSL endpoint in Apache, which you must pair with a short WSGI " "script." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:300 msgid "HTTP strict transport security" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:302 msgid "" "We recommend that all production deployments use HTTP strict transport " "security (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:" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:313 msgid "" "Start with a short timeout of 1 day during testing, and raise it to one year " "after testing has shown that you have not introduced problems for users. " "Note that once this header is set to a large timeout, it is (by design) very " "difficult to disable." msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:321 msgid "Perfect forward secrecy" msgstr "" #: ../secure-communication/tls-proxies-and-http-services.rst:323 msgid "" "Configuring TLS servers for perfect forward secrecy requires careful " "planning around key size, session IDs, and session tickets. In addition, for " "multi-server deployments, shared state is also an important consideration. " "The example configurations for Apache and :term:`Nginx` above disable the " "session tickets options to help mitigate some of these concerns. Real-world " "deployments may desire to enable this feature for improved performance. This " "can be done securely, but would require special consideration around key " "management. Such configurations are beyond the scope of this guide. We " "suggest reading `How to botch TLS forward secrecy by ImperialViolet <https://" "www.imperialviolet.org/2013/06/27/botchingpfs.html>`_ as a starting place " "for understanding the problem space." msgstr "" #: ../security-review.rst:3 msgid "Security review" msgstr "" #: ../security-review.rst:5 msgid "" "The goal of security review in the OpenStack community is to identify " "weaknesses in design or implementation of OpenStack projects. While rare, " "these weaknesses could potentially have catastrophic effects on the security " "of an OpenStack deployment, and therefore work should be undertaken to " "minimize the likelihood of these defects in released projects. Over the " "course of a security review, the following should be known and documented:" msgstr "" #: ../security-review.rst:12 msgid "All entry points into a system" msgstr "" #: ../security-review.rst:13 msgid "What assets are at risk" msgstr "" #: ../security-review.rst:14 msgid "Where data is persisted" msgstr "" #: ../security-review.rst:15 msgid "How data travels between components of the system" msgstr "" #: ../security-review.rst:16 msgid "Data formats and transformations" msgstr "" #: ../security-review.rst:17 msgid "External dependencies of the project" msgstr "" #: ../security-review.rst:18 msgid "An agreed set of findings and/or defects" msgstr "" #: ../security-review.rst:19 msgid "How the project interacts with external dependencies" msgstr "" #: ../security-review.rst:21 msgid "" "A common reason to perform a security review on an OpenStack deliverable " "repository is to assist with Vulnerability Management Team (VMT) oversight. " "The OpenStack VMT lists `overseen repositories <https://security.openstack." "org/repos-overseen.html>`_ where the report reception and disclosure of " "vulnerabilities is managed by the VMT. While not a strict requirement, some " "form of security review, audit or threat analysis helps everyone more easily " "pinpoint areas where a system is more prone to vulnerabilities and solve " "them before they become a problem for users." msgstr "" #: ../security-review.rst:30 msgid "" "The OpenStack VMT suggests that an architectural review of the recommended " "deployment for a project is an appropriate form of security review, " "balancing the need for review with the resource requirements for a project " "of the scale of OpenStack. Security architecture review is also often " "referred to as *threat analysis*, *security analysis* or *threat modeling*. " "In the context of OpenStack security review, these terms are synonymous for " "an architectural security review which may identify defects in the design of " "a project or reference architecture, and may lead to further investigative " "work to verify parts of the implementation." msgstr "" #: ../security-review.rst:40 msgid "" "Security review is expected to be the normal route for new projects and for " "cases where third parties have not performed security reviews or are unable " "to share their results. Information for projects that require a security " "review will be available in the upcoming security review process." msgstr "" #: ../security-review.rst:45 msgid "" "In cases where a security review has already been performed by a third " "party, or where a project prefers to use a third party to perform their " "review, information on how to take the output of that third party review and " "submit it for validation will be available in the upcoming third party " "security review process." msgstr "" #: ../security-review.rst:51 msgid "" "In either case, the requirements for documentation artefacts are similar - " "the project must provide an architecture diagram for a best practise " "deployment. Vulnerability scans and static analysis scans are not sufficient " "evidence for a third party review, although they are strongly recommended as " "part of the development cycle for all teams." msgstr "" #: ../security-review/architecture-page-guidance.rst:3 msgid "Architecture page guidance" msgstr "" #: ../security-review/architecture-page-guidance.rst:5 msgid "" "The purpose of an architecture page is to document the architecture, purpose " "and security controls of a service or project. It should document the best " "practice deployment of that project." msgstr "" #: ../security-review/architecture-page-guidance.rst:9 msgid "" "There are some key sections to the architecture page, which are explained in " "more detail below:" msgstr "" #: ../security-review/architecture-page-guidance.rst:12 #: ../security-review/architecture-page-guidance.rst:24 msgid "Title, version information, contact details" msgstr "" #: ../security-review/architecture-page-guidance.rst:13 #: ../security-review/architecture-page-guidance.rst:35 msgid "Project description and purpose" msgstr "" #: ../security-review/architecture-page-guidance.rst:14 #: ../security-review/architecture-page-guidance.rst:51 msgid "Primary users and use-cases" msgstr "" #: ../security-review/architecture-page-guidance.rst:15 #: ../security-review/architecture-page-guidance.rst:65 msgid "External dependencies and associated security assumptions" msgstr "" #: ../security-review/architecture-page-guidance.rst:16 #: ../security-review/architecture-page-guidance.rst:82 msgid "Components" msgstr "" #: ../security-review/architecture-page-guidance.rst:17 msgid "Architecture diagram" msgstr "" #: ../security-review/architecture-page-guidance.rst:18 #: ../security-review/architecture-page-guidance.rst:114 msgid "Data assets" msgstr "" #: ../security-review/architecture-page-guidance.rst:19 #: ../security-review/architecture-page-guidance.rst:138 msgid "Data asset impact analysis" msgstr "" #: ../security-review/architecture-page-guidance.rst:20 #: ../security-review/architecture-page-guidance.rst:173 msgid "Interfaces" msgstr "" #: ../security-review/architecture-page-guidance.rst:26 msgid "" "This section titles the architecture page, gives the status of the review " "(draft, ready for review, reviewed) and captures the release and version of " "the project (where relevant). It also records the PTL for the project, the " "project's architect who is responsible for producing the architecture page, " "diagrams and working through the review (this may or may not be the PTL), " "and the security reviewer(s)." msgstr "" #: ../security-review/architecture-page-guidance.rst:37 msgid "" "This section will contain a brief description of the project to introduce " "third parties to the service. This should be a paragraph or two and can be " "cut/paste from wiki or other documentation. Include links to relevant " "presentations and further documentation if available." msgstr "" #: ../security-review/architecture-page-guidance.rst:42 #: ../security-review/architecture-page-guidance.rst:56 #: ../security-review/architecture-page-guidance.rst:73 #: ../security-review/architecture-page-guidance.rst:88 #: ../security-review/architecture-page-guidance.rst:127 #: ../security-review/architecture-page-guidance.rst:147 #: ../security-review/architecture-page-guidance.rst:193 msgid "For example:" msgstr "" #: ../security-review/architecture-page-guidance.rst:44 msgid "" "\"Anchor is a public key infrastructure (PKI) service, which uses automated " "certificate request validation to automate issuing decisions. Certificates " "are issued for short time periods (typically 12-48 hours) to avoid the " "flawed revocation issues associated with CRLs and OCSP.\"" msgstr "" #: ../security-review/architecture-page-guidance.rst:53 msgid "" "A list of the expected primary users of the implemented architecture and " "their use-cases. 'Users' can either be actors or other services within " "OpenStack." msgstr "" #: ../security-review/architecture-page-guidance.rst:58 msgid "" "End users will use the system to store sensitive data, such as passphrases " "encryption keys, etc." msgstr "" #: ../security-review/architecture-page-guidance.rst:60 msgid "" "Cloud administrators will use the administrative APIs to manage resource " "quotas." msgstr "" #: ../security-review/architecture-page-guidance.rst:67 msgid "" "External dependencies are items outside of the control of the service that " "are required for its operation, and may impact the service if they were " "compromised or became unavailable. These items are usually outside the " "control of the developer but within the control of the deployer, or they may " "be operated by a third party. Appliances should be regarded as external " "dependencies." msgstr "" #: ../security-review/architecture-page-guidance.rst:75 msgid "" "Nova compute service depends on an external authentication and authorization " "service. In a typical deployment this dependency will be fulfilled by the " "keystone service." msgstr "" #: ../security-review/architecture-page-guidance.rst:78 msgid "" "Barbican depends on the use of Hardware Security Module (HSM) appliance." msgstr "" #: ../security-review/architecture-page-guidance.rst:84 msgid "" "A list of the components of the deployed project excluding external " "entities. Each component should be named and have a brief description of its " "purpose, and be labeled with the primary technology used (e.g. Python, " "MySQL, RabbitMQ)." msgstr "" #: ../security-review/architecture-page-guidance.rst:90 msgid "" "keystone listener process (Python): Python process that consumes keystone " "events published by the keystone service." msgstr "" #: ../security-review/architecture-page-guidance.rst:92 msgid "" "Database (MySQL): MySQL database to store barbican state data related to its " "managed entities and their metadata." msgstr "" #: ../security-review/architecture-page-guidance.rst:97 msgid "Service architecture diagram" msgstr "" #: ../security-review/architecture-page-guidance.rst:99 msgid "" "The architecture diagram shows the logical layout of the system so the " "security reviewers can step through the architecture with the project team. " "It is a logical diagram which shows how the components interact, how they " "connect to external entities, and where communications cross trust " "boundaries. Further information on architecture diagram, including a key of " "symbols, will be given in the upcoming architecture diagram guidance. " "Diagrams can be drawn in any tool that can produce a diagram which uses the " "symbols in the key, however `draw.io <https://draw.io>`__ is strongly " "recommended." msgstr "" #: ../security-review/architecture-page-guidance.rst:108 msgid "This example shows the barbican architecture diagram:" msgstr "" #: ../security-review/architecture-page-guidance.rst:116 msgid "" "Data assets are user data, high-value data, configuration items, " "authorization tokens or other items that an attacker may target. The set of " "data items will vary between projects, but in general it should be " "considered as classes of data which are vital to the intended operation of " "the project. The level of detail required is somewhat dependent on the " "context. Data can usually be grouped, such as 'user data', 'secret data', or " "'configuration files', but may be singular, like 'admin identity token' or " "'user identity token', or 'database configuration file'." msgstr "" #: ../security-review/architecture-page-guidance.rst:125 msgid "" "Data assets should include a statement of where that asset is persisted." msgstr "" #: ../security-review/architecture-page-guidance.rst:129 msgid "" "*Secret data* - Passphrases, Encryption Keys, RSA Keys - persisted in " "Database [PKCS#11] or HSM [KMIP] or [KMIP, Dogtag]" msgstr "" #: ../security-review/architecture-page-guidance.rst:131 msgid "*RBAC rulesets* - persisted in policy.json" msgstr "" #: ../security-review/architecture-page-guidance.rst:132 msgid "*RabbitMQ Credentials* - persisted in barbican.conf" msgstr "" #: ../security-review/architecture-page-guidance.rst:133 msgid "*keystone Event Queue Credentials* - persisted in barbican.conf" msgstr "" #: ../security-review/architecture-page-guidance.rst:134 msgid "*Middleware configuration* - persisted in paste.ini" msgstr "" #: ../security-review/architecture-page-guidance.rst:140 msgid "" "The data asset impact analysis breaks down the impact of the loss of " "confidentiality, integrity or availability for each data asset. Project " "architects should attempt to complete this, as they understand their project " "in the most detail, but the OpenStack Security Project (OSSP) will work " "through this with the project during the security review and are likely to " "add or update the impact details." msgstr "" #: ../security-review/architecture-page-guidance.rst:149 msgid "*RabbitMQ credentials*:" msgstr "" #: ../security-review/architecture-page-guidance.rst:151 msgid "" "Integrity Failure Impact: barbican and Workers can no longer access the " "queue. Denial of service." msgstr "" #: ../security-review/architecture-page-guidance.rst:153 msgid "" "Confidentiality Failure Impact: An attacker could add new tasks to the queue " "which would be executed by workers. User quotas could be exhausted by an " "attacker. DoS. User would be unable to create genuine secrets." msgstr "" #: ../security-review/architecture-page-guidance.rst:156 msgid "" "Availability Failure Impact: barbican could no longer create new secrets " "without access to the queue." msgstr "" #: ../security-review/architecture-page-guidance.rst:159 msgid "*keystone credentials*:" msgstr "" #: ../security-review/architecture-page-guidance.rst:161 msgid "" "Integrity Failure Impact: barbican will not be able to validate user " "credentials and fail. DoS." msgstr "" #: ../security-review/architecture-page-guidance.rst:163 msgid "" "Confidentially Failure Impact: A malicious user might be able to abuse other " "OpenStack services (depending on keystone role configurations) but barbican " "is unaffected. If the service account for token validation also has barbican " "admin privileges, then a malicious user could manipulate barbican admin " "functions." msgstr "" #: ../security-review/architecture-page-guidance.rst:168 msgid "" "Availability Failure Impact: barbican will not be able to validate user " "credentials and fail. DoS." msgstr "" #: ../security-review/architecture-page-guidance.rst:175 msgid "" "The interfaces listing captures interfaces within the scope of the review. " "This includes connections between blocks on the architecture diagram which " "cross a trust boundary or do not use an industry standard encryption " "protocol such as TLS or SSH. For each interface the following information is " "captured:" msgstr "" #: ../security-review/architecture-page-guidance.rst:180 msgid "The protocol used" msgstr "" #: ../security-review/architecture-page-guidance.rst:181 msgid "Any data assets in transit across that interface" msgstr "" #: ../security-review/architecture-page-guidance.rst:182 msgid "Information on authentication used to connect to that interface" msgstr "" #: ../security-review/architecture-page-guidance.rst:183 msgid "A brief description of the purpose of the interface." msgstr "" #: ../security-review/architecture-page-guidance.rst:185 msgid "This is recorded in the following format:" msgstr "" #: ../security-review/architecture-page-guidance.rst:187 msgid "From->To *[Transport]*:" msgstr "" #: ../security-review/architecture-page-guidance.rst:189 msgid "Assets in flight" msgstr "" #: ../security-review/architecture-page-guidance.rst:190 msgid "Authentication?" msgstr "" #: ../security-review/architecture-page-guidance.rst:195 msgid "Client->API Process *[TLS]*:" msgstr "" #: ../security-review/architecture-page-guidance.rst:197 msgid "" "Assets in flight: User keystone credentials, plaintext secrets, HTTP verb, " "secret ID, path" msgstr "" #: ../security-review/architecture-page-guidance.rst:199 msgid "" "Access to keystone credentials or plaintext secrets is considered a total " "security failure of the system - this interface must have robust " "confidentiality and integrity controls." msgstr "" #: ../security-review/architecture-page-guidance.rst:205 msgid "Resources" msgstr "" #: ../security-review/architecture-page-guidance.rst:207 msgid "" "List resources relevant to the project, such as wiki pages describing its " "deployment and usage, and links to code repositories and relevant " "presentations." msgstr "" #: ../shared-file-systems.rst:5 msgid "" "The Shared File Systems service (manila) provides a set of services for " "management of shared file systems in a multi-tenant cloud environment. It is " "similar to how OpenStack provides block-based storage management through the " "OpenStack Block Storage service (cinder) project. With the Shared File " "Systems service, you can create a shared file system and manage its " "properties, such as visibility, accessibility and usage quotas." msgstr "" #: ../shared-file-systems.rst:12 msgid "" "The Shared File Systems service works with various storage providers that " "use the following shared file system protocols: :term:`NFS <Network File " "System (NFS)>`, :term:`CIFS <Common Internet File System (CIFS)>`, :term:" "`GlusterFS`, and :term:`HDFS <Hadoop Distributed File System (HDFS)>`." msgstr "" #: ../shared-file-systems.rst:18 msgid "" "The Shared File Systems service serves the same purpose as Amazon Elastic " "File System (EFS)." msgstr "" #: ../shared-file-systems/checklist.rst:10 msgid "" "Check-Shared-01: Is user/group ownership of config files set to root/manila?" msgstr "" #: ../shared-file-systems/checklist.rst:12 msgid "" "Configuration files contain critical parameters and information required for " "smooth functioning of the component. If an unprivileged user, either " "intentionally or accidentally, modifies or deletes any of the parameters or " "the file itself then it would cause severe availability issues resulting in " "a denial of service to the other end users. Thus user ownership of such " "critical configuration files must be set to root and group ownership must be " "set to manila. Additionally, the containing directory should have the same " "ownership to ensure that new files are owned correctly." msgstr "" #: ../shared-file-systems/checklist.rst:31 msgid "" "**Pass:** If user and group ownership of all these config files is set to " "root and manila respectively. The above commands show output of root manila." msgstr "" #: ../shared-file-systems/checklist.rst:34 msgid "" "**Fail:** If the above commands does not return any output as the user and " "group ownership might have set to any user other than root or any group " "other than manila." msgstr "" #: ../shared-file-systems/checklist.rst:41 msgid "Check-Shared-02: Are strict permissions set for configuration files?" msgstr "" #: ../shared-file-systems/checklist.rst:60 msgid "" "**Pass:** If permissions are set to 640 or stricter, or the containing " "directory is set to 750. The permissions of 640 translates into owner r/w, " "group r, and no rights to others i.e. \"u=rw,g=r,o=\". Note that with :ref:" "`check_shared_fs_01` and permissions set to 640, root has read/write access " "and manila has read access to these configuration files. The access rights " "can also be validated using the following command. This command will only be " "available on your system if it supports ACLs." msgstr "" #: ../shared-file-systems/checklist.rst:83 msgid "Check-Shared-03: Is OpenStack Identity used for authentication?" msgstr "" #: ../shared-file-systems/checklist.rst:90 msgid "" "OpenStack supports various authentication strategies like noauth and " "keystone. If the '``noauth``' strategy is used then the users could interact " "with OpenStack services without any authentication. This could be a " "potential risk since an attacker might gain unauthorized access to the " "OpenStack components. Thus it is strongly recommended that all services must " "be authenticated with keystone using their service accounts." msgstr "" #: ../shared-file-systems/checklist.rst:97 msgid "" "**Pass:** If value of parameter ``auth_strategy`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``keystone``." msgstr "" #: ../shared-file-systems/checklist.rst:106 msgid "Check-Shared-04: Is TLS enabled for authentication?" msgstr "" #: ../shared-file-systems/checklist.rst:114 msgid "" "**Pass:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/manila/manila.conf`` is set to " "Identity API endpoint starting with ``https://`` and value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/manila/manila.conf`` is set to ``False``." msgstr "" #: ../shared-file-systems/checklist.rst:120 msgid "" "**Fail:** If value of parameter ``www_authenticate_uri`` under " "``[keystone_authtoken]`` section in ``/etc/manila/manila.conf`` is not set " "to Identity API endpoint starting with ``https://`` or value of parameter " "``insecure`` under the same ``[keystone_authtoken]`` section in the same ``/" "etc/manila/manila.conf`` is set to ``True``." msgstr "" #: ../shared-file-systems/checklist.rst:129 msgid "" "Check-Shared-05: Does Shared File Systems contact with Compute over TLS?" msgstr "" #: ../shared-file-systems/checklist.rst:131 #: ../shared-file-systems/checklist.rst:151 #: ../shared-file-systems/checklist.rst:169 msgid "" "This item only applies to OpenStack releases Train and before as " "``auth_strategy`` was deprecated in Ussuri." msgstr "" #: ../shared-file-systems/checklist.rst:134 msgid "" "OpenStack components communicate with each other using various protocols and " "the communication might involve sensitive or confidential data. An attacker " "may try to eavesdrop on the channel in order to get access to sensitive " "information. Thus all the components must communicate with each other using " "a secured communication protocol." msgstr "" #: ../shared-file-systems/checklist.rst:140 msgid "" "**Pass:** If value of parameter ``nova_api_insecure`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``False``." msgstr "" #: ../shared-file-systems/checklist.rst:143 msgid "" "**Fail:** If value of parameter ``nova_api_insecure`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``True``." msgstr "" #: ../shared-file-systems/checklist.rst:149 msgid "" "Check-Shared-06: Does Shared File Systems contact with Networking over TLS?" msgstr "" #: ../shared-file-systems/checklist.rst:154 #: ../shared-file-systems/checklist.rst:172 msgid "" "Similar to previous check (:ref:`check_shared_fs_05`), it is recommended all " "the components must communicate with each other using a secured " "communication protocol." msgstr "" #: ../shared-file-systems/checklist.rst:158 msgid "" "**Pass:** If value of parameter ``neutron_api_insecure`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``False``." msgstr "" #: ../shared-file-systems/checklist.rst:161 msgid "" "**Fail:** If value of parameter ``neutron_api_insecure`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``True``." msgstr "" #: ../shared-file-systems/checklist.rst:167 msgid "" "Check-Shared-07: Does Shared File Systems contact with Block Storage over " "TLS?" msgstr "" #: ../shared-file-systems/checklist.rst:176 msgid "" "**Pass:** If value of parameter ``cinder_api_insecure`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``False``." msgstr "" #: ../shared-file-systems/checklist.rst:179 msgid "" "**Fail:** If value of parameter ``cinder_api_insecure`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``True``." msgstr "" #: ../shared-file-systems/checklist.rst:185 msgid "" "Check-Shared-08: Is max size for the request body set to default (114688)?" msgstr "" #: ../shared-file-systems/checklist.rst:187 msgid "" "If the maximum body size per request is not defined, the attacker can craft " "an arbitrary OSAPI request of large size causing the service to crash and " "finally resulting in Denial Of Service attack. Assigning the maximum value " "ensures that any malicious oversized request gets blocked ensuring continued " "availability of the service." msgstr "" #: ../shared-file-systems/checklist.rst:193 msgid "" "**Pass:** If value of parameter ``max_request_body_size`` under " "``[oslo_middleware]`` section in ``manila.conf`` is set to ``114688``, or if " "value of parameter ``osapi_max_request_body_size`` under ``[DEFAULT]`` " "section in ``manila.conf`` is set to ``114688``. The parameter " "``osapi_max_request_body_size`` under ``[DEFAULT]`` is deprecated and it is " "better to use [oslo_middleware]/``max_request_body_size``." msgstr "" #: ../shared-file-systems/checklist.rst:200 msgid "" "**Fail:** If value of parameter ``max_request_body_size`` under " "``[oslo_middleware]`` section in ``manila.conf`` is not set to ``114688``, " "or if value of parameter ``osapi_max_request_body_size`` under ``[DEFAULT]`` " "section in ``manila.conf`` is not set to ``114688``." msgstr "" #: ../shared-file-systems/intro.rst:5 msgid "" "The Shared File Systems service (manila) is intended to be ran on a single-" "node or across multiple nodes. The Shared File Systems service consists of " "four main services, which are similar to those of the Block Storage service:" msgstr "" #: ../shared-file-systems/intro.rst:9 ../shared-file-systems/intro.rst:18 msgid "``manila-api``" msgstr "" #: ../shared-file-systems/intro.rst:10 ../shared-file-systems/intro.rst:25 msgid "``manila-scheduler``" msgstr "" #: ../shared-file-systems/intro.rst:11 ../shared-file-systems/intro.rst:21 msgid "``manila-share``" msgstr "" #: ../shared-file-systems/intro.rst:12 ../shared-file-systems/intro.rst:29 msgid "``manila-data``" msgstr "" #: ../shared-file-systems/intro.rst:15 msgid "" "The service that provides a stable RESTful API. The service authenticates " "and routes requests throughout the Shared Filesystem service. There is " "python-manilaclient to interact with the API. For more details on the Shared " "File Systems API, see the `OpenStack Shared File Systems API <https://docs." "openstack.org/api-ref/shared-file-system/>`_." msgstr "" #: ../shared-file-systems/intro.rst:21 msgid "" "Responsible for managing Shared File Service devices, specifically the back-" "end devices." msgstr "" #: ../shared-file-systems/intro.rst:24 msgid "" "Responsible for scheduling and routing requests to the appropriate ``manila-" "share`` service. It does that by picking one back-end while filtering all " "except one back-end." msgstr "" #: ../shared-file-systems/intro.rst:28 msgid "" "This service is responsible for managing data operations which may take a " "long time to complete and block other services if not handled separately." msgstr "" #: ../shared-file-systems/intro.rst:31 msgid "" "The Shared File Systems service uses an SQL-based central database that is " "shared by all Shared File Systems services in the system. It can use any SQL " "dialect supported by ORM SQLALchemy, but is tested only with MySQL and " "PostgreSQL data bases." msgstr "" #: ../shared-file-systems/intro.rst:36 msgid "" "Using SQL, the Shared File Systems service is similar to other OpenStack " "services and can be used with any OpenStack deployment. For more details on " "the API, see the `OpenStack Shared File Systems API <https://docs.openstack." "org/api-ref/shared-file-system/>`_ description. For more details on the CLI " "usage and configuration, see `Shared File Systems Cloud Administrative Guide " "<https://docs.openstack.org/admin-guide/shared_file_systems.html>`_." msgstr "" #: ../shared-file-systems/intro.rst:44 msgid "" "On the image below you can see how different parts of the Shared File System " "service interact with each other." msgstr "" #: ../shared-file-systems/intro.rst:49 msgid "" "Besides already described services you can see two other entities on the " "image: ``python-manilaclient`` and ``storage controller``." msgstr "" #: ../shared-file-systems/intro.rst:53 msgid "" "Command line interface to interact with the Shared File Systems service via " "``manila-api`` and also a Python module to interact programmatically with " "the Shared File Systems service." msgstr "" #: ../shared-file-systems/intro.rst:54 msgid "``python-manilaclient``" msgstr "" #: ../shared-file-systems/intro.rst:57 msgid "" "Typically a metal box with spinning disks, ethernet ports, and some kind of " "software that allows network clients to read and write files on the disks. " "There are also software-only storage controllers that run on arbitrary " "hardware, clustered controllers which may run allow a multiple physical " "devices to appear as a single storage controller, or purely virtual storage " "controllers." msgstr "" #: ../shared-file-systems/intro.rst:62 msgid "``Storage controller``" msgstr "" #: ../shared-file-systems/intro.rst:64 msgid "" "A share is a remote, mountable file system. You can mount a share to and " "access a share from several hosts by several users at a time." msgstr "" #: ../shared-file-systems/intro.rst:67 msgid "" "The Shared File Systems service can work with different network types: flat, " "VLAN, VXLAN, or GRE, and supports segmented networking. There are also " "different :ref:`network plug-ins <shared_fs_network_plugins>` that provide a " "variety of integration approaches with the network services that are " "available with OpenStack." msgstr "" #: ../shared-file-systems/intro.rst:73 msgid "" "There are a large number of share drivers created by different vendors which " "support different hardware storage solutions, for example, NetApp Clustered " "Data ONTAP (cDOT) Driver, Huawei NAS Driver or GlusterFS Driver. Each share " "driver is a Python class that can be set for a back end and run in the back " "end to manage share operations, some of which can be vendor-specific. The " "back end is an instance of the manila-share service." msgstr "" #: ../shared-file-systems/intro.rst:80 msgid "" "Clients' configuration data for authentication and authorization can be " "stored by :ref:`security services <shared_fs_security_services>`. Such " "protocols as LDAP, Kerberos, or Microsoft Active Directory authentication " "service can be configured and used." msgstr "" #: ../shared-file-systems/intro.rst:85 msgid "" "Unless it is not explicitly changed in the ``policy.json``, either an " "administrator or the tenant that owns a share are able to manage :ref:" "`access to the shares <shared_fs_share_acl>`. Access management is done by " "creating access rules with authentication through IP address, user, group, " "or TLS certificates. Available authentication methods depend on which share " "driver and security service you configure and use." msgstr "" #: ../shared-file-systems/intro.rst:94 msgid "" "Different drivers support different access options depending on which shared " "file system protocol is used. Supported shared file system protocols are " "NFS, CIFS, GlusterFS, and HDFS. For example, the Generic (Block Storage as a " "back end) driver does not support user and certificate authentication " "methods. It also does not support any of the security services, such as " "LDAP, Kerberos, or Active Directory. For details of features supported by " "different drivers, see `Manila share features support mapping <https://docs." "openstack.org/manila/latest/contributor/" "share_back_ends_feature_support_mapping.html>`_." msgstr "" #: ../shared-file-systems/intro.rst:103 msgid "" "As an administrator, you can create share types that enable the scheduler to " "filter back ends before you create a share. Share types have extra " "specifications that you can set for the scheduler to filter and weigh back " "ends so that an appropriate one is selected for a user that requests share " "creation. Shares and share types can be created as public or private. This " "level of visibility defines whether other tenants are able to see these " "objects and operate with them, or not. An administrator can add :ref:`access " "to the private share types <shared_fs_share_types_acl>` for specific users " "or tenants in the Identity service. Thus users which you have granted access " "can see available share types and create shares using them." msgstr "" #: ../shared-file-systems/intro.rst:114 msgid "" "Permissions for API calls for different users and their roles are determined " "by :ref:`policies <shared_fs_policies>` like in other OpenStack services." msgstr "" #: ../shared-file-systems/intro.rst:117 msgid "" "The Identity service can be used for authentication in the Shared File " "Systems service. See details of the Identity service security in :doc:`../" "identity` section." msgstr "" #: ../shared-file-systems/intro.rst:122 msgid "General security information" msgstr "" #: ../shared-file-systems/intro.rst:124 msgid "" "Similar to other OpenStack projects, the Shared File Systems service is " "registered with the Identity service, so you can find API endpoints of the " "share service v1 and v2 using **manila endpoints** command:" msgstr "" #: ../shared-file-systems/intro.rst:151 msgid "" "By default, the Shared File Systems API service listens only on the port " "``8786`` with ``tcp6`` type that supports both IPv4 and IPv6." msgstr "" #: ../shared-file-systems/intro.rst:156 msgid "" "The port ``8786`` is the default port for the Shared File Systems service. " "It may be changed to any other port, but this change should also be made in " "the configuration file to option ``osapi_share_listen_port`` which defaults " "to ``8786``." msgstr "" #: ../shared-file-systems/intro.rst:161 msgid "" "In the ``/etc/manila/`` directory you can find several configuration files:" msgstr "" #: ../shared-file-systems/intro.rst:174 msgid "" "It is recommended that you configure the Shared File Systems service to run " "under a non-root service account, and change file permissions so that only " "the system administrator can modify them. The Shared File Systems service " "expects that only administrators can write to configuration files and " "services can only read them through their group membership in ``manila`` " "group. Others must not be able to read these files because the files contain " "admin passwords for different services." msgstr "" #: ../shared-file-systems/intro.rst:182 msgid "" "Apply checks :ref:`check_shared_fs_01` and :ref:`check_shared_fs_02` from " "the checklist to verify that permissions are set properly." msgstr "" #: ../shared-file-systems/intro.rst:187 msgid "" "The configuration for manila-rootwrap in file ``rootwrap.conf`` and the " "manila-rootwrap command filters for share nodes in file ``rootwrap.d/share." "filters`` should be owned by, and only-writeable by, the root user." msgstr "" #: ../shared-file-systems/intro.rst:194 msgid "" "The manila configuration file ``manila.conf`` may be placed anywhere. The " "path ``/etc/manila/manila.conf`` is expected by default." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:5 msgid "Network and security models" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:6 msgid "" "A share driver in the Shared File Systems service is a Python class that can " "be set for the back end and run in it to manage share operations, some of " "which are vendor-specific. The back end is an instance of manila-share " "service. There are a big number of share drivers created by different " "vendors in the Shared File Systems service. Each share driver supports one " "or more back end modes: *share servers* and *no share servers*. An " "administrator chooses which mode is used by specifying it in ``manila.conf`` " "configuration file. An option ``driver_handles_share_servers`` is used for " "it." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:15 msgid "" "The *share servers* mode can be configured with flat network, or with " "segmented network. This depends on the network provider." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:18 msgid "" "It is possible to have separate drivers for different modes use the same " "hardware, if you want to have different configurations. Depending on which " "mode is chosen, an administrator may need to provide more configuration " "details through the configuration file." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:26 msgid "Share back ends modes" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:28 msgid "Each share driver supports at least one of the possible driver modes:" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:30 msgid "**share servers mode**" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:31 msgid "**no share servers mode**" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:33 msgid "" "The configuration option in ``manila.conf`` that sets *share servers* mode " "or *no share servers* mode is the ``driver_handles_share_servers`` option. " "It indicates whether a driver handles share servers by itself or it expects " "the Shared File Systems service to do it." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:42 msgid "Mode" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:43 msgid "Config option" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:46 msgid "share servers" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:47 msgid "driver_handles_share_servers = True" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:48 msgid "" "The share driver creates the share server and manages, or handles, the share " "server life cycle." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:51 msgid "no share servers" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:52 msgid "driver_handles_share_servers = False" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:53 msgid "" "An administrator rather than a share driver manages the bare metal storage " "with some net interface insteadof the presence of the share servers." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:58 msgid "" "In this mode, drivers have basically no network requirements whatsoever. " "It's assumed that storage controller being managed by the driver has all of " "the network interfaces it's going to need. The Shared File Systems service " "will expect the driver to provision shares directly without creating any " "share server beforehand. This mode corresponds to what some existing drivers " "are already doing, but it makes the choice explicit for the administrator. " "In this mode, the share networks are not needed at share creation time and " "must not be provided." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:65 msgid "No share servers mode" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:69 msgid "" "In *no share servers mode* the Shared File Systems service will assume that " "the network interfaces through which any shares are exported are already " "reachable by all tenants." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:73 msgid "" "In the *no share servers* mode a share driver does not handle storage life " "cycle. An administrator is expected to handle the storage, network " "interfaces, and other host configurations. In this mode an administrator can " "set storage as a host which exports shares. The main characteristic of this " "mode is that the storage is not handled by the Shared File Systems service. " "Users in a tenant share common network, host, processor, and network pipe. " "They can hinder each other if there is no correct balancing adjustment on " "the storage configured by admin or proxy before it. In public clouds it is " "possible that all network capacity is used by one client, so an " "administrator should care for this not to happen. Balancing adjustment can " "be done by any means, not necessarily with OpenStack tools." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:86 msgid "" "In this mode, a driver is able to create share servers and plug them to " "existing networks. When providing a new share server, drivers expect an IP " "address and subnet from the Shared File Systems service." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:88 msgid "Share servers mode" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:90 msgid "" "Unlike *no share servers* mode, in *share servers* mode users have a share " "network and a share server that is created for each share network. Thus all " "users have separate CPU, amount of CPU time, network, capacity and " "throughput." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:95 msgid "" "You also can configure :ref:`security services " "<shared_fs_security_services>` in both *share servers* and *no share " "servers* back-end modes. But with *no share servers* back-end mode, an " "administrator should set desired authentication services manually on the " "host. And in *share servers* mode the Shared File Systems service can be " "configured automatically with any existing security services supported by " "the share driver." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:104 msgid "Flat vs segmented networking" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:105 msgid "" "The Shared File Systems service allows to work with different types of a " "network:" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:108 msgid "``flat``" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:109 msgid "``GRE``" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:110 msgid "``VLAN``" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:111 msgid "``VXLAN``" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:115 msgid "" "The Shared File Systems service is merely keeping the information about " "networks in the database, and real networks are provided by the network " "provider. In OpenStack it can be Legacy networking (nova-network) or " "Networking (neutron) services, but the Shared File Systems service can work " "even out of OpenStack. That is allowed by ``StandaloneNetworkPlugin`` that " "can be used with any network platform and does not require some specific " "network services in OpenStack like Networking or Legacy networking services. " "You can set the network parameters in its configuration file." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:125 msgid "" "In :ref:`share servers <share-servers-vs-no-share-servers>` back-end mode a " "share driver creates and manages a share server for each share network. This " "mode can be divided in two variations:" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:129 msgid "Flat network in *share servers* back-end mode" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:130 msgid "Segmented network in *share servers* back-end mode" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:132 msgid "" "Initially, when creating a share network, you can set up either a network " "and subnet of the OpenStack Networking (neutron) or a network of Legacy " "networking (nova-network) services. The third approach is to configure the " "networking without Legacy networking and Networking services. " "``StandaloneNetworkPlugin`` can be used with any network platform. You can " "set network parameters in its configuration file." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:141 msgid "" "All share drivers that use the OpenStack Compute service do not use network " "plug-ins. In Mitaka release it is Windows and Generic drivers. These share " "drives have other options and use different approach." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:145 msgid "" "After a share network is created, the Shared File Systems service retrieves " "network information determined by a network provider: network type, " "segmentation identifier if the network uses segmentation and IP block in " "CIDR notation from which to allocate the network." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:150 msgid "**Flat network in share servers back-end mode**" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:152 msgid "" "In this mode, some storage controllers can create share servers but due to " "various limitations of physical or logical network all of share servers have " "to be on a flat network. In this mode, a share driver needs something to " "provision IP addresses for share servers, but IPs will all come out of the " "same subnet and that subnet itself is assumed to be reachable by all tenants." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:158 msgid "" "The :ref:`security service part <shared_fs_security_services>` of share " "networks specify security requirements such as AD or LDAP domains or a " "Kerberos realm. The Shared File Systems service assumes that any hosts " "referred to in security service are reachable from a subnet where a share " "server is created, which limits the number of cases where this mode could be " "used." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:165 msgid "**Segmented network in share servers back-end mode**" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:167 msgid "" "In this mode, a share driver is able to create share servers and plug them " "to an existing segmented network. Share drivers expect the Shared File " "Systems service to provide a subnet definition for every new share server. " "This definition should include segmentation type, segmentation ID, and any " "other info relevant to the segmentation type." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:175 msgid "" "Some share drivers may not support all types of segmentation, for details " "see specification for the driver in use." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:181 msgid "Network plug-ins" msgstr "" #: ../shared-file-systems/network-and-security-models.rst:183 msgid "" "The Shared File Systems service architecture defines an abstraction layer " "for network resource provisioning. It allows administrators to choose from " "different options for how network resources are assigned to their tenants’ " "networked storage. There are several network plug-ins that provide a variety " "of integration approaches with the network services that are available with " "OpenStack." msgstr "" #: ../shared-file-systems/network-and-security-models.rst:190 msgid "" "Network plug-ins allow to use any functions, configurations of the OpenStack " "Networking and Legacy networking services. One can use any network " "segmentation that the Networking service supports, you can use flat networks " "or VLAN-segmented networks of the Legacy networking (nova-network) service, " "or you can use plug-ins for specifying networks independently from OpenStack " "networking services. For more information of how to use different network " "plug-ins, see `Shared File Systems service Network plug-ins <https://docs." "openstack.org/admin-guide/shared_file_systems_network_plugins.html#network-" "plug-ins>`_." msgstr "" #: ../shared-file-systems/policies.rst:6 msgid "" "Shared File Systems service has its own role-based access policies. They " "determine which user can access which objects in which way, and are defined " "in the service's ``policy.json`` file." msgstr "" #: ../shared-file-systems/policies.rst:12 msgid "" "The configuration file ``policy.json`` may be placed anywhere. The path ``/" "etc/manila/policy.json`` is expected by default." msgstr "" #: ../shared-file-systems/policies.rst:15 msgid "" "Whenever an API call to the Shared File Systems service is made, the policy " "engine uses the appropriate policy definitions to determine if the call can " "be accepted." msgstr "" #: ../shared-file-systems/policies.rst:19 msgid "" "A policy rule determines under which circumstances the API call is " "permitted. The ``/etc/manila/policy.json`` file has rules where action is " "always permitted, when the rule is an empty string: ``\"\"``; the rules " "based on the user role or rules; rules with boolean expressions. Below is a " "snippet of the ``policy.json`` file for the Shared File Systems service. " "From one OpenStack release to another it can be changed." msgstr "" #: ../shared-file-systems/policies.rst:38 msgid "" "Users must be assigned to groups and roles that you refer to in your " "policies. This is done automatically by the service when user management " "commands are used." msgstr "" #: ../shared-file-systems/policies.rst:44 msgid "" "Any changes to ``/etc/manila/policy.json`` are effective immediately, which " "allows new policies to be implemented while the Shared File Systems service " "is running. Manual modification of the policy can have unexpected side " "effects and is not encouraged. For details, see `The policy.json file " "<https://docs.openstack.org/ocata/config-reference/policy-json-file.html>`_." msgstr "" #: ../shared-file-systems/security-services.rst:5 msgid "Security services" msgstr "" #: ../shared-file-systems/security-services.rst:7 msgid "" "For authentication and authorization of clients, the Shared File Systems " "Storage service can optionally be configured with different network " "authentication protocols. Supported authentication protocols are LDAP, " "Kerberos, and Microsoft Active directory authentication service." msgstr "" #: ../shared-file-systems/security-services.rst:13 msgid "Introduction to security services" msgstr "" #: ../shared-file-systems/security-services.rst:14 msgid "" "After creating a share and getting its export location, users have no " "permissions to mount it and operate with files. The Shared File System " "service requires to explicitly grant access to the new share." msgstr "" #: ../shared-file-systems/security-services.rst:18 msgid "" "The client configuration data for authentication and authorization (AuthN/" "AuthZ) can be stored by ``security services``. LDAP, Kerberos, or Microsoft " "Active directory can be used by the Shared File Systems service if they are " "supported by used drivers and back ends. Authentication services can also be " "configured without the Shared File Systems service." msgstr "" #: ../shared-file-systems/security-services.rst:26 msgid "" "In some cases, it is required to explicitly specify one of the security " "services, for example, NetApp, EMC and Windows drivers require Active " "Directory for the creation of shares with the CIFS protocol." msgstr "" #: ../shared-file-systems/security-services.rst:31 msgid "Security services management" msgstr "" #: ../shared-file-systems/security-services.rst:32 msgid "" "A *security service* is the Shared File Systems service (manila) entity that " "abstracts a set of options that defines a security domain for a particular " "shared file system protocol, such as an Active Directory domain or a " "Kerberos domain. The security service contains all of the information " "necessary for the Shared File Systems to create a server that joins a given " "domain." msgstr "" #: ../shared-file-systems/security-services.rst:38 msgid "" "Using the API, users can create, update, view and delete a security service. " "Security Services are designed basing on the following assumptions:" msgstr "" #: ../shared-file-systems/security-services.rst:41 msgid "Tenants provide details for the security service." msgstr "" #: ../shared-file-systems/security-services.rst:42 msgid "" "Administrators care about security services: they configure the server side " "of such security services." msgstr "" #: ../shared-file-systems/security-services.rst:44 msgid "" "Inside The Shared File Systems API, a ``security_service`` is associated " "with the ``share_networks``." msgstr "" #: ../shared-file-systems/security-services.rst:46 msgid "" "Share drivers use data in the security service to configure newly created " "share servers." msgstr "" #: ../shared-file-systems/security-services.rst:49 msgid "" "While creating a security service, you can select one of these " "authentication services:" msgstr "" #: ../shared-file-systems/security-services.rst:56 msgid "Authentication service" msgstr "" #: ../shared-file-systems/security-services.rst:59 msgid "LDAP" msgstr "" #: ../shared-file-systems/security-services.rst:60 msgid "" "The Lightweight Directory Access Protocol. An application protocol for " "accessing and maintaining distributed directory information services over an " "IP network." msgstr "" #: ../shared-file-systems/security-services.rst:65 msgid "" "The network authentication protocol which works on the basis of tickets to " "allow nodes communicating over a non-secure network to prove their identity " "to one another in a secure manner." msgstr "" #: ../shared-file-systems/security-services.rst:69 msgid "Active Directory" msgstr "" #: ../shared-file-systems/security-services.rst:70 msgid "" "A directory service that Microsoft developed for Windows domain networks. " "Uses LDAP, Microsoft's version of Kerberos, and DNS." msgstr "" #: ../shared-file-systems/security-services.rst:73 msgid "" "The Shared File Systems service allows you to configure a security service " "with these options:" msgstr "" #: ../shared-file-systems/security-services.rst:76 msgid "A DNS IP address that is used inside the tenant network." msgstr "" #: ../shared-file-systems/security-services.rst:77 msgid "An IP address or host name of a security service." msgstr "" #: ../shared-file-systems/security-services.rst:78 msgid "A domain of a security service." msgstr "" #: ../shared-file-systems/security-services.rst:79 msgid "A user or group name that is used by a tenant." msgstr "" #: ../shared-file-systems/security-services.rst:80 msgid "A password for a user, if you specify a user name." msgstr "" #: ../shared-file-systems/security-services.rst:82 msgid "" "An existing security service entity can be associated with share network " "entities that inform the Shared File Systems service about security and " "network configuration for a group of shares. You can also see the list of " "all security services for a specified share network and disassociate them " "from a share network." msgstr "" #: ../shared-file-systems/security-services.rst:88 msgid "" "For details of managing security services via API, see the `Security " "services API <https://docs.openstack.org/api-ref/shared-file-system/index." "html#security-services>`_. You also can manage security services via python-" "manilaclient, see `Security services CLI managing <https://docs.openstack." "org/admin-guide/shared_file_systems_security_services.html>`_." msgstr "" #: ../shared-file-systems/security-services.rst:93 msgid "" "An administrator and users as share owners can manage the :ref:`access to " "the shares <shared_fs_share_acl>` by creating access rules with " "authentication though an IP address, user, group, or TLS certificates. " "Authentication methods depend on which share driver and security service you " "configure and use." msgstr "" #: ../shared-file-systems/security-services.rst:99 msgid "" "Thus, as an administrator, you can configure a back end to use specific " "authentication service via network and it will store users. The " "authentication service can operate with clients without the Shared File " "System and the Identity service." msgstr "" #: ../shared-file-systems/security-services.rst:106 msgid "" "Different authentication services are supported by different share drivers. " "For details of supporting of features by different drivers, see `Manila " "share features support mapping <https://docs.openstack.org/manila/latest/" "contributor/share_back_ends_feature_support_mapping.html>`_. Support for a " "specific authentication service by a driver does not mean that it can be " "configured with any shared file system protocol. Supported shared file " "systems protocols are NFS, CIFS, GlusterFS, and HDFS. See the driver " "vendor's documentation for information on a specific driver and its " "configuration for security services." msgstr "" #: ../shared-file-systems/security-services.rst:115 msgid "" "Some drivers support security services and other drivers do not support any " "of the security services mentioned above. For example, Generic Driver with " "the NFS or the CIFS shared file system protocol supports only authentication " "method through the IP address." msgstr "" #: ../shared-file-systems/security-services.rst:122 msgid "" "Those drivers that support the CIFS shared file system protocol in most " "cases can be configured to use Active Directory and manage access through " "the user authentication." msgstr "" #: ../shared-file-systems/security-services.rst:125 msgid "" "Drivers that support the GlusterFS protocol can be used with authentication " "via TLS certificates." msgstr "" #: ../shared-file-systems/security-services.rst:127 msgid "" "With drivers that support NFS protocol authentication via IP address is the " "only supported option." msgstr "" #: ../shared-file-systems/security-services.rst:129 msgid "" "Since the HDFS shared file system protocol uses NFS access it also can be " "configured to authenticate via IP address." msgstr "" #: ../shared-file-systems/security-services.rst:132 msgid "" "Note, however, that authentication via IP is the least secure type of " "authentication." msgstr "" #: ../shared-file-systems/security-services.rst:135 msgid "" "The recommended configuration for the Shared File Systems service real usage " "is to create a share with the CIFS share protocol and add to it the " "Microsoft Active Directory directory service. In this configuration you will " "get the centralized data base and the service that unites Kerberos and LDAP " "approaches. This is a real use case that is convenient for production shared " "file systems." msgstr "" #: ../shared-file-systems/share-acl.rst:5 msgid "Share access control" msgstr "" #: ../shared-file-systems/share-acl.rst:6 msgid "" "The Shared File Systems service allows to grant or deny access to different " "entities of the service for other clients." msgstr "" #: ../shared-file-systems/share-acl.rst:9 msgid "" "Having a share as remote mountable instance of a file system, you can manage " "access to a specified share, and list permissions for a specified share." msgstr "" #: ../shared-file-systems/share-acl.rst:12 msgid "" "A share can be *public* or *private*. This is a level of visibility for the " "share that defines whether other tenants can or cannot see the share. By " "default, all shares are created as private. While creating a share, use key " "``--public`` to make your share public for other tenants to see it in a list " "of shares and see its detailed information." msgstr "" #: ../shared-file-systems/share-acl.rst:18 msgid "" "According to a :ref:`policy.json <shared_fs_policies>` file, an " "administrator and the users as share owners can manage access to shares by " "means of creating access rules. Using :command:`manila access-allow`, :" "command:`manila access-deny` and :command:`manila access-list` commands, you " "can grant, deny and list access to a specified share correspondingly." msgstr "" #: ../shared-file-systems/share-acl.rst:26 msgid "" "By default, when a share is created and has its export location, the Shared " "File Systems service expects that nobody can access the share by mounting " "it. Please note that the share driver you use can change this configuration, " "or it can be directly changed on the share storage. To ensure access to the " "share, check the mounting config for the export protocol." msgstr "" #: ../shared-file-systems/share-acl.rst:33 msgid "" "When a share is just created there are no default access rules associated " "with it and permission to mount it. This could be seen in mounting config " "for export protocol in use. For example, there is an NFS command " "``exportfs`` or ``/etc/exports`` file on the storage which controls each " "remote share and defines hosts that can access it. It is empty if nobody can " "mount a share. For a remote CIFS server there is ``net conf list`` command " "which shows the configuration. ``hosts deny`` parameter should be set by the " "share driver to ``0.0.0.0/0`` which means that any host is denied to mount " "the share." msgstr "" #: ../shared-file-systems/share-acl.rst:43 msgid "" "Using the Shared File Systems service, you can grant or deny access to a " "share by specifying one of these supported share access levels:" msgstr "" #: ../shared-file-systems/share-acl.rst:46 msgid "**rw**. Read and write (RW) access. This is the default value." msgstr "" #: ../shared-file-systems/share-acl.rst:48 msgid "**ro**. Read-only (RO) access." msgstr "" #: ../shared-file-systems/share-acl.rst:52 msgid "" "The RO access level can be helpful in public shares when the administrator " "gives read and write (RW) access for some certain editors or contributors " "and gives read-only (RO) access for the rest of users (viewers)." msgstr "" #: ../shared-file-systems/share-acl.rst:57 msgid "You must also specify one of these supported authentication methods:" msgstr "" #: ../shared-file-systems/share-acl.rst:59 msgid "" "**ip**. Authenticates an instance by its IP address. A valid format is XX.XX." "XX.XX or XX.XX.XX.XX/XX. For example 0.0.0.0/0." msgstr "" #: ../shared-file-systems/share-acl.rst:62 msgid "" "**cert**. Authenticates an instance by a TLS certificate. Specify the TLS " "identity as the IDENTKEY. A valid value is any string up to 64 characters " "long in the common name (CN) of the certificate." msgstr "" #: ../shared-file-systems/share-acl.rst:66 msgid "" "**user**. Authenticates by a specified user or group name. A valid value is " "an alphanumeric string that can contain some special characters and is from " "4 to 32 characters long." msgstr "" #: ../shared-file-systems/share-acl.rst:72 msgid "" "Supported authentication methods depend on which share driver, security " "service and shared file system protocol you configure and use. Supported " "shared file system protocols are NFS, CIFS, GlusterFS, and HDFS. Supported " "security services are LDAP, Kerberos protocols, or Microsoft Active " "Directory service. For details of supporting of features by different " "drivers, see `Manila share features support mapping <http://docs.openstack. " "org/developer/manila/devref/share_back_ends_feature_support_ mapping.html>`_." msgstr "" #: ../shared-file-systems/share-acl.rst:81 msgid "" "To verify that access rules (ACL) were configured correctly for a share, you " "can list its permissions." msgstr "" #: ../shared-file-systems/share-acl.rst:86 msgid "" "You also can choose and add the :ref:`security service " "<shared_fs_security_services>` that is supported by the share driver to " "create access rules with authentication methods for clients that are " "appropriate for your share. Supported security services are LDAP, Kerberos " "and Microsoft Active Directory." msgstr "" #: ../shared-file-systems/share-acl.rst:92 msgid "" "Below is an example of an NFS share with the Generic driver. After the share " "was created it has export location ``10.254.0.3:/shares/share-b2874f8d-" "d428-4a5c-b056-e6af80a995de``. If you try to mount it on the host with " "``10.254.0.4`` IP address, you'll get a *\"Permission denied\"* message." msgstr "" #: ../shared-file-systems/share-acl.rst:106 msgid "" "As an administrator, you can connect through SSH to a host with " "``10.254.0.3`` IP address, check the ``/etc/exports`` file on it and see " "that it is empty:" msgstr "" #: ../shared-file-systems/share-acl.rst:114 msgid "" "The Generic driver we use in example does not support any of the security " "services, thus with NFS shared file system protocol we can grant access only " "through the IP address:" msgstr "" #: ../shared-file-systems/share-acl.rst:132 msgid "" "After the rule has status ``active`` we can connect to the ``10.254.0.3`` " "host again and check the ``/etc/exports`` file and see that the line with " "rule was added:" msgstr "" #: ../shared-file-systems/share-acl.rst:142 msgid "" "Now we can mount a share on the host with IP address ``10.254.0.4`` and have " "``rw`` permissions to the share:" msgstr "" #: ../shared-file-systems/share-type-acl.rst:5 msgid "Share type access control" msgstr "" #: ../shared-file-systems/share-type-acl.rst:6 msgid "" "A share type is an administrator-defined \"type of service\", comprised of a " "tenant visible description, and a list of non-tenant-visible key-value pairs " "- extra specifications. The manila-scheduler uses extra specifications to " "make scheduling decisions, and drivers control the share creation." msgstr "" #: ../shared-file-systems/share-type-acl.rst:11 msgid "" "An administrator can create and delete share types, and also manage extra " "specifications that give them meaning inside the Shared File Systems " "service. Tenants can list the share types and can use them to create new " "shares. For details of managing the share types, see `Shared File Systems " "API <https://docs.openstack.org/api-ref/shared-file-system/index.html#share-" "types>`_ and `Share types managing <https://docs.openstack.org/admin-guide/" "shared_file_systems_share_types.html>`_ documentation." msgstr "" #: ../shared-file-systems/share-type-acl.rst:20 msgid "" "Share types can be created as *public* and *private*. This is the level of " "visibility for the share type that defines whether other tenants can or " "cannot see it in a share types list and use it to create a new share." msgstr "" #: ../shared-file-systems/share-type-acl.rst:24 msgid "" "By default, share types are created as public. While creating a share type, " "use ``--is_public`` parameter set to ``False`` to make your share type " "private which will prevent other tenants from seeing it in a list of share " "types and creating new shares with it. On the other hand, *public* share " "types are available to every tenant in a cloud." msgstr "" #: ../shared-file-systems/share-type-acl.rst:30 msgid "" "The Shared File Systems service allows an administrator to grant or deny " "access to the *private* share types for tenants. It is also possible to get " "information about access for a specified private share type." msgstr "" #: ../shared-file-systems/share-type-acl.rst:36 msgid "" "Since share types due to their extra specifications help to filter or choose " "back ends before users create a share, using access to the share types you " "can limit clients in choice of specific back ends." msgstr "" #: ../shared-file-systems/share-type-acl.rst:40 msgid "" "As an example, being an administrator user in admin tenant, you can create a " "private share type named ``my_type`` and see it in the list. In the console " "examples the logging in and out is omitted, and environment variables are " "provided to show the current logged in user." msgstr "" #: ../shared-file-systems/share-type-acl.rst:60 msgid "" "``demo`` user in ``demo`` tenant can list the types and the private share " "type named ``my_type`` is not visible for him." msgstr "" #: ../shared-file-systems/share-type-acl.rst:77 msgid "" "The administrator can grant access to the private share type for the demo " "tenant with the tenant ID equal to df29a37db5ae48d19b349fe947fada46:" msgstr "" #: ../shared-file-systems/share-type-acl.rst:96 msgid "" "Thus now users in demo tenant can see the private share type and use it in " "the share creation:" msgstr "" #: ../shared-file-systems/share-type-acl.rst:114 msgid "" "To deny access for a specified project, use :command:`manila type-access-" "remove <share_type> <project_id>` command." msgstr "" #: ../shared-file-systems/share-type-acl.rst:119 msgid "" "A **real production use case** that shows the purpose of a share types and " "access to them is a situation when you have two back ends: cheap LVM as a " "public storage and expensive Ceph as a private storage. In this case you can " "grant access to certain tenants and make the access with ``user/group`` " "authentication method." msgstr "" #: ../tenant-data.rst:3 msgid "Tenant data privacy" msgstr "" #: ../tenant-data.rst:5 msgid "" "OpenStack is designed to support multitenancy and those tenants will most " "probably have different data requirements. As a cloud builder or operator, " "you must ensure your OpenStack environment addresses data privacy concerns " "and regulations. In this chapter we will address data residency and disposal " "as it pertains to OpenStack implementations." msgstr "" #: ../tenant-data/data-encryption.rst:3 msgid "Data encryption" msgstr "" #: ../tenant-data/data-encryption.rst:6 msgid "" "The option exists for implementers to encrypt tenant data wherever it is " "stored on disk or transported over a network, such as the OpenStack volume " "encryption feature described below. This is above and beyond the general " "recommendation that users encrypt their own data before sending it to their " "provider." msgstr "" #: ../tenant-data/data-encryption.rst:11 msgid "" "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." msgstr "" #: ../tenant-data/data-encryption.rst:18 msgid "" "Per-instance or per-object encryption is preferable over, in descending " "order, 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." msgstr "" #: ../tenant-data/data-encryption.rst:25 msgid "" "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." msgstr "" #: ../tenant-data/data-encryption.rst:30 msgid "Opportunities to encrypt data for users are present:" msgstr "" #: ../tenant-data/data-encryption.rst:32 ../tenant-data/data-encryption.rst:114 #: ../tenant-data/data-privacy-concerns.rst:18 msgid "Object Storage objects" msgstr "" #: ../tenant-data/data-encryption.rst:33 ../tenant-data/data-encryption.rst:171 msgid "Network data" msgstr "" #: ../tenant-data/data-encryption.rst:38 msgid "" "A volume encryption feature in OpenStack supports privacy on a per-tenant " "basis. As of the Kilo release, the following features are supported:" msgstr "" #: ../tenant-data/data-encryption.rst:41 msgid "" "Creation and usage of encrypted volume types, initiated through the " "dashboard or a command line interface" msgstr "" #: ../tenant-data/data-encryption.rst:44 msgid "" "Enable encryption and select parameters such as encryption algorithm and key " "size" msgstr "" #: ../tenant-data/data-encryption.rst:47 msgid "Volume data contained within iSCSI packets is encrypted" msgstr "" #: ../tenant-data/data-encryption.rst:48 msgid "Supports encrypted backups if the original volume is encrypted" msgstr "" #: ../tenant-data/data-encryption.rst:49 msgid "" "Dashboard indication of volume encryption status. Includes indication that a " "volume is encrypted, and includes the encryption parameters such as " "algorithm and key size" msgstr "" #: ../tenant-data/data-encryption.rst:52 ../tenant-data/data-encryption.rst:98 msgid "Interface with the Key management service through a secure wrapper" msgstr "" #: ../tenant-data/data-encryption.rst:54 msgid "" "Volume encryption is supported by back-end key storage for enhanced security " "(for example, a Hardware Security Module (HSM) or a KMIP server can be used " "as a barbican back-end secret store)" msgstr "" #: ../tenant-data/data-encryption.rst:61 msgid "" "An ephemeral disk encryption feature addresses data privacy. The ephemeral " "disk is a temporary work space used by the virtual host operating system. " "Without encryption, sensitive user information could be accessed on this " "disk, and vestigial information could remain after the disk is unmounted. As " "of the Kilo release, the following ephemeral disk encryption features are " "supported:" msgstr "" #: ../tenant-data/data-encryption.rst:67 msgid "" "Creation and usage of encrypted LVM ephemeral disks (note: At this time " "OpenStack Compute service only supports encrypting ephemeral disks in the " "LVM format)" msgstr "" #: ../tenant-data/data-encryption.rst:71 msgid "" "The compute configuration, ``nova.conf``, has the following default " "parameters within the \"[ephemeral_storage_encryption]\" section" msgstr "" #: ../tenant-data/data-encryption.rst:74 msgid "**option**: 'cipher = aes-xts-plain64'" msgstr "" #: ../tenant-data/data-encryption.rst:76 msgid "" "This field sets the cipher and mode used to encrypt ephemeral storage. AES-" "XTS is recommended by NIST_ specifically for disk storage, and the name is " "shorthand for AES encryption using the XTS encryption mode. Available " "ciphers depend on kernel support. At the command line, type 'cryptsetup " "benchmark' to determine the available options (and see benchmark results), " "or go to */proc/crypto*" msgstr "" #: ../tenant-data/data-encryption.rst:84 msgid "**option**: 'enabled = false'" msgstr "" #: ../tenant-data/data-encryption.rst:86 msgid "To use ephemeral disk encryption, set **option**: 'enabled = true'" msgstr "" #: ../tenant-data/data-encryption.rst:88 msgid "**option**: 'key_size = 512'" msgstr "" #: ../tenant-data/data-encryption.rst:90 msgid "" "Note that there may be a key size limitation from the backend key manager " "that could require the use of 'key_size = 256', which would only provide an " "AES key size of 128-bits. XTS requires it's own \"tweak key\" in addition to " "the encryption key AES requires. This is typically expressed as a single " "large key. In this case, using the 512-bit setting, 256 bits will be used by " "AES and 256 bits by XTS. (see NIST_)" msgstr "" #: ../tenant-data/data-encryption.rst:100 msgid "" "Key management service will support data isolation by providing ephemeral " "disk encryption keys on a per-tenant basis" msgstr "" #: ../tenant-data/data-encryption.rst:103 msgid "" "Ephemeral disk encryption is supported by back-end key storage for enhanced " "security (for example, an HSM or a KMIP server can be used as a barbican " "back-end secret store)" msgstr "" #: ../tenant-data/data-encryption.rst:107 msgid "" "With the Key management service, when an ephemeral disk is no longer needed, " "simply deleting the key may take the place of overwriting the ephemeral disk " "storage area" msgstr "" #: ../tenant-data/data-encryption.rst:116 msgid "" "Object Storage (swift) supports the optional encryption of object data at " "rest on storage nodes. The encryption of object data is intended to mitigate " "the risk of users’ data being read if an unauthorized party were to gain " "physical access to a disk." msgstr "" #: ../tenant-data/data-encryption.rst:121 msgid "" "Encryption of data at rest is implemented by middleware that may be included " "in the proxy server WSGI pipeline. The feature is internal to a swift " "cluster and not exposed through the API. Clients are unaware that data is " "encrypted by this feature internally to the swift service; internally " "encrypted data should never be returned to clients through the swift API." msgstr "" #: ../tenant-data/data-encryption.rst:127 msgid "The following data are encrypted while at rest in swift:" msgstr "" #: ../tenant-data/data-encryption.rst:129 msgid "" "Object content. For example, the content of an object PUT request’s body" msgstr "" #: ../tenant-data/data-encryption.rst:130 msgid "The entity tag (ETag) of objects that have non-zero content" msgstr "" #: ../tenant-data/data-encryption.rst:131 msgid "" "All custom user object metadata values. For example, metadata sent using ``X-" "Object-Meta-`` prefixed headers with PUT or POST requests" msgstr "" #: ../tenant-data/data-encryption.rst:134 msgid "" "Any data or metadata not included in the list above are not encrypted, " "including:" msgstr "" #: ../tenant-data/data-encryption.rst:137 msgid "Account, container, and object names" msgstr "" #: ../tenant-data/data-encryption.rst:138 msgid "Account and container custom user metadata values" msgstr "" #: ../tenant-data/data-encryption.rst:139 msgid "All custom user metadata names" msgstr "" #: ../tenant-data/data-encryption.rst:140 msgid "Object Content-Type values" msgstr "" #: ../tenant-data/data-encryption.rst:141 msgid "Object size" msgstr "" #: ../tenant-data/data-encryption.rst:142 msgid "System metadata" msgstr "" #: ../tenant-data/data-encryption.rst:144 msgid "" "For more information on the deployment, operation, or implementation of " "Object Storage encryption, see the swift Developer Documentation on `Object " "Encryption <https://docs.openstack.org/swift/latest/overview_encryption." "html>`_." msgstr "" #: ../tenant-data/data-encryption.rst:149 msgid "Block Storage performance and backends" msgstr "" #: ../tenant-data/data-encryption.rst:151 msgid "" "When enabling the operating system, OpenStack Volume Encryption performance " "can be enhanced by using the hardware acceleration features currently " "available in both Intel and AMD processors. Both the OpenStack Volume " "Encryption feature and the OpenStack Ephemeral Disk Encryption feature use " "``dm-crypt`` to secure volume data. ``dm-crypt`` is a transparent disk " "encryption capability in Linux kernel versions 2.6 and later. When the " "Volume Encryption is enabled, encrypted data is sent over iSCSI to Block " "Storage, securing data in transit and data at rest simultaneously. When " "using hardware acceleration, the performance impact of both of the " "encryption features is minimized." msgstr "" #: ../tenant-data/data-encryption.rst:162 msgid "" "Although we recommend using the OpenStack Volume Encryption feature, Block " "Storage supports a large variety of alternative back-ends for supplying " "mountable volumes, and some of these may also provide volume encryption. " "Since there are so many `back-ends <https://docs.openstack.org/cinder/latest/" "drivers.html>`_, and since information from each vendor must be obtained, it " "is outside the scope of this guide to specify recommendations for " "implementing encryption in any of them." msgstr "" #: ../tenant-data/data-encryption.rst:173 msgid "" "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." msgstr "" #: ../tenant-data/data-encryption.rst:177 msgid "" "Likewise, encrypted data will remain encrypted as it is transferred over the " "network." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:3 msgid "Data privacy concerns" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:6 msgid "Data residency" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:8 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:13 msgid "" "Numerous OpenStack services maintain data and metadata belonging to tenants " "or reference tenant information." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:16 msgid "" "Tenant data stored in an OpenStack cloud may include the following items:" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:19 msgid "Compute instance ephemeral filesystem storage" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:20 msgid "Compute instance memory" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:21 #: ../tenant-data/data-privacy-concerns.rst:69 msgid "Block Storage volume data" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:22 msgid "Public keys for Compute access" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:23 msgid "Virtual machine images in the Image service" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:24 msgid "Machine snapshots" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:25 msgid "Data passed to OpenStack Compute's configuration-drive extension" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:27 msgid "" "Metadata stored by an OpenStack cloud includes the following non-exhaustive " "items:" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:30 msgid "Organization name" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:31 msgid "User's \"Real Name\"" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:32 msgid "" "Number or size of running instances, buckets, objects, volumes, and other " "quota-related items" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:34 msgid "Number of hours running instances or storing data" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:35 msgid "IP addresses of users" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:36 msgid "Internally generated private keys for compute image bundling" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:39 msgid "Data disposal" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:41 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:48 msgid "" "\"The sanitization process removes information from the media such that the " "information cannot be retrieved or reconstructed. Sanitization techniques, " "including clearing, purging, cryptographic erase, and destruction, prevent " "the disclosure of information to unauthorized individuals when such media is " "reused or released for disposal.\" `NIST Special Publication 800-53 Revision " "4 <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4." "pdf>`__" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:55 msgid "" "General data disposal and sanitization guidelines as adopted from NIST " "recommended security controls. Cloud operators should:" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:58 msgid "Track, document and verify media sanitization and disposal actions." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:59 msgid "Test sanitation equipment and procedures to verify proper performance." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:61 msgid "" "Sanitize portable, removable storage devices prior to connecting such " "devices to the cloud infrastructure." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:63 msgid "Destroy cloud system media that cannot be sanitized." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:65 msgid "In an OpenStack deployment you will need to address the following:" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:67 msgid "Secure data erasure" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:68 #: ../tenant-data/data-privacy-concerns.rst:83 msgid "Instance memory scrubbing" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:70 #: ../tenant-data/data-privacy-concerns.rst:152 msgid "Compute instance ephemeral storage" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:71 #: ../tenant-data/data-privacy-concerns.rst:181 msgid "Bare metal server sanitization" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:74 msgid "Data not securely erased" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:76 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:85 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:90 msgid "" "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 `KVM documentation <http://www.linux-kvm.org/page/" "Memory>`__." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:96 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:100 msgid "" "For these and other hypervisors, we recommend referring to hypervisor-" "specific documentation." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:104 msgid "Cinder volume data" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:106 msgid "" "Use of the OpenStack volume encryption feature is highly encouraged. This is " "discussed below in the Data Encryption section under Volume Encryption. When " "this feature is used, destruction of data is accomplished by securely " "deleting the encryption key. The end user can select this feature while " "creating a volume, but note that an admin must perform a one-time set up of " "the volume encryption feature first. Instructions for this setup are in the " "block storage section of the `Configuration Reference <https://docs." "openstack.org/ocata/config-reference/block-storage/volume-encryption." "html>`__ , under volume encryption." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:116 msgid "" "If the OpenStack volume encryption feature is not used, then other " "approaches generally would be more difficult to enable. If a back-end plug-" "in is being used, there may be independent ways of doing encryption or non-" "standard overwrite solutions. Plug-ins 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 plug-in to " "another, from one vendor's solution to another, and from one filesystem to " "another." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:125 msgid "" "Some back-ends such as ZFS will support copy-on-write to prevent data " "exposure. In these cases, reads from unwritten blocks will always return " "zero. Other back ends 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 back-end provides and to see what mediations " "may be available for those assurances not provided." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:134 msgid "Image service delay delete feature" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:136 msgid "" "OpenStack Image service has a delayed delete feature, which will pend the " "deletion of an image for a defined time period. It is recommended to disable " "this feature if it is a security concern, by editing the ``etc/glance/glance-" "api.conf`` file and setting the ``delayed_delete`` option as False." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:143 msgid "Compute soft delete feature" msgstr "" #: ../tenant-data/data-privacy-concerns.rst:145 msgid "" "OpenStack Compute has a soft-delete feature, which enables an instance that " "is deleted to be in a soft-delete state for a defined time period. The " "instance can be restored during this time period. To disable the soft-delete " "feature, edit the ``etc/nova/nova.conf`` file and leave the " "``reclaim_instance_interval`` option empty." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:154 msgid "" "Note that the OpenStack `Ephemeral disk encryption <https://docs.openstack." "org/security-guide/tenant-data/data-encryption.html>`__ feature provides a " "means of improving ephemeral storage privacy and isolation, during both " "active use as well as when the data is to be destroyed. As in the case of " "encrypted block storage, one can simply delete the encryption key to " "effectively destroy the data." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:161 msgid "" "Alternate measures to provide data privacy, in the creation and destruction " "of ephemeral storage, will be somewhat dependent on the chosen hypervisor " "and the OpenStack Compute plug-in." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:165 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:170 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:175 msgid "" "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." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:183 msgid "" "A bare metal server driver for Compute was under development and has since " "moved into a separate project called `ironic <https://wiki.openstack.org/" "wiki/Ironic>`__. At the time of this writing, ironic does not appear to " "address sanitization of tenant data resident the physical hardware." msgstr "" #: ../tenant-data/data-privacy-concerns.rst:189 msgid "" "Additionally, it is possible for tenants of a bare metal system to modify " "system firmware. TPM technology, described in :ref:`management-secure-" "bootstrapping`, provides a solution for detecting unauthorized firmware " "changes." msgstr "" #: ../tenant-data/key-management.rst:3 msgid "Key management" msgstr "" #: ../tenant-data/key-management.rst:6 msgid "" "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. In some instances, client-side encryption is utilized to " "encrypt data held by the virtualization technologies which requires client " "interaction, such as presenting keys, to decrypt data for future use. To " "seamlessly secure the data and 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 and addresses customer concerns about privacy or misuse of data, " "while also limiting cloud provider liability. This can help reduce a " "provider's liability when handling tenant data during an incident " "investigation in multi-tenant public clouds." msgstr "" #: ../tenant-data/key-management.rst:22 msgid "" "The volume encryption and ephemeral disk encryption features rely on a key " "management service (for example, barbican) for the creation and secure " "storage of keys. The key manager is pluggable to facilitate deployments that " "need a third-party Hardware Security Module (HSM) or the use of the Key " "Management Interchange Protocol (KMIP), which is supported by an open-source " "project called PyKMIP." msgstr "" #: ../tenant-data/key-management.rst:30 msgid "Bibliography:" msgstr "" #: ../tenant-data/key-management.rst:32 msgid "" "OpenStack.org, Welcome to barbican's Developer Documentation!. 2014. " "`Barbican developer documentation <https://docs.openstack.org/barbican/" "latest/>`__" msgstr "" #: ../tenant-data/key-management.rst:36 msgid "" "oasis-open.org, OASIS Key Management Interoperability Protocol (KMIP). 2014. " "`KMIP <https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip>`__" msgstr "" #: ../tenant-data/key-management.rst:40 msgid "`PyKMIP library <https://github.com/OpenKMIP/PyKMIP>`__" msgstr "" #: ../tenant-data/key-management.rst:42 msgid "Secrets Management :ref:`secrets-management`" msgstr ""