├── .gitignore ├── .gitreview ├── .zuul.yaml ├── README.rst ├── bindep.txt ├── case-studies ├── api-case-studies.rst ├── compliance-case-studies.rst ├── compute-case-studies.rst ├── dashboard-case-studies.rst ├── data-processing-case-studies.rst ├── databases-case-studies.rst ├── documentation-case-studies.rst ├── identity-case-studies.rst ├── instance-management-case-studies.rst ├── introduction-to-case-studies.rst ├── management-case-studies.rst ├── messaging-case-studies.rst ├── monitoring-logging-case-studies.rst ├── networking-case-studies.rst ├── secure-communication-case-studies.rst └── tenant-data-case-studies.rst ├── common ├── README.txt ├── app-support.rst ├── conventions.rst ├── glossary.rst └── source │ └── locale │ ├── de │ └── LC_MESSAGES │ │ └── common.po │ ├── id │ └── LC_MESSAGES │ │ └── common.po │ ├── ja │ └── LC_MESSAGES │ │ └── common.po │ └── tr_TR │ └── LC_MESSAGES │ └── common.po ├── doc-tools-check-languages.conf ├── security-guide ├── README.rst └── source │ ├── api-endpoints.rst │ ├── api-endpoints │ └── api-endpoint-configuration-recommendations.rst │ ├── appendix.rst │ ├── block-storage.rst │ ├── block-storage │ ├── checklist.rst │ └── volume_wiping.rst │ ├── checklist.rst │ ├── common │ ├── compliance.rst │ ├── compliance │ ├── certification-and-compliance-statements.rst │ ├── compliance-activities.rst │ ├── overview.rst │ ├── privacy.rst │ └── understanding-the-audit-process.rst │ ├── compute.rst │ ├── compute │ ├── checklist.rst │ ├── hardening-deployments.rst │ ├── hardening-the-virtualization-layers.rst │ ├── how-to-select-virtual-consoles.rst │ ├── hypervisor-selection.rst │ └── vulnerability-awareness.rst │ ├── conf.py │ ├── dashboard.rst │ ├── dashboard │ ├── checklist.rst │ ├── cookies.rst │ ├── cross-origin-resource-sharing-cors.rst │ ├── debug.rst │ ├── domains-dashboard-upgrades-basic-web-server-configuration.rst │ ├── front-end-caching-session-back-end.rst │ ├── https-hsts-xss-ssrf.rst │ ├── passwords.rst │ ├── secret-key.rst │ └── static-media.rst │ ├── data-processing.rst │ ├── data-processing │ ├── configuration-and-hardening.rst │ ├── deployment.rst │ └── introduction-to-data-processing.rst │ ├── databases.rst │ ├── databases │ ├── database-access-control.rst │ ├── database-backend-considerations.rst │ └── database-transport-security.rst │ ├── documentation.rst │ ├── documentation │ └── system-documentation-requirements.rst │ ├── figures │ ├── 1aa-logical-neutron-flow.png │ ├── 1aa-network-domains-diagram.png │ ├── book-sprint-all-logos.png │ ├── bridging_domains_clouduser.png │ ├── bridging_domains_clouduser.svg │ ├── bridging_security_domains_1.png │ ├── bridging_security_domains_1.svg │ ├── data_processing_architecture.png │ ├── databaseusername.png │ ├── databaseusername.svg │ ├── databaseusernamessl.png │ ├── databaseusernamessl.svg │ ├── filteringWorkflow1.png │ ├── group.png │ ├── high-capability.png │ ├── high-capability.svg │ ├── manila-intro.png │ ├── marketecture-diagram.png │ ├── node-provisioning-pxe.graffle │ ├── node-provisioning-pxe.png │ ├── novaconductor.png │ ├── novaconductor.svg │ ├── sVirt_Diagram_1.png │ ├── sdn-connections.png │ ├── sdn-connections.svg │ ├── secure-arch-ref-1.png │ ├── secure-arch-ref-1.svg │ ├── secure-arch-ref-2.png │ ├── secure-arch-ref-2.svg │ ├── secure-arch-ref-3.png │ ├── secure-arch-ref-3.svg │ ├── secure-arch-ref-4.png │ ├── secure-arch-ref-4.svg │ ├── security_review_barbican_architecture.png │ ├── swift_network_diagram-1.png │ ├── swift_network_diagram-2.png │ ├── threat_actors.png │ ├── threat_actors.svg │ └── untrusted_trusted.png │ ├── identity.rst │ ├── identity │ ├── authentication-methods.rst │ ├── authentication.rst │ ├── authorization.rst │ ├── checklist.rst │ ├── domains.rst │ ├── federated-keystone.rst │ ├── policies.rst │ └── tokens.rst │ ├── image-storage.rst │ ├── image-storage │ └── checklist.rst │ ├── index.rst │ ├── instance-management.rst │ ├── instance-management │ └── security-services-for-instances.rst │ ├── introduction.rst │ ├── introduction │ ├── acknowledgements.rst │ ├── introduction-to-openstack.rst │ ├── security-boundaries-and-threats.rst │ ├── selecting-supporting-software.rst │ └── why-and-how-we-wrote-this-book.rst │ ├── locale │ ├── de │ │ └── LC_MESSAGES │ │ │ └── security-guide.po │ ├── id │ │ └── LC_MESSAGES │ │ │ └── security-guide.po │ ├── ja │ │ └── LC_MESSAGES │ │ │ └── security-guide.po │ └── tr_TR │ │ └── LC_MESSAGES │ │ └── security-guide.po │ ├── management.rst │ ├── management │ ├── continuous-systems-management.rst │ ├── integrity-life-cycle.rst │ └── management-interfaces.rst │ ├── messaging.rst │ ├── messaging │ └── security.rst │ ├── monitoring-logging.rst │ ├── monitoring-logging │ └── forensics-and-incident-response.rst │ ├── networking.rst │ ├── networking │ ├── architecture.rst │ ├── checklist.rst │ ├── securing-services.rst │ ├── services-security-best-practices.rst │ └── services.rst │ ├── object-storage.rst │ ├── secrets-management.rst │ ├── secrets-management │ ├── barbican.rst │ ├── castellan.rst │ ├── checklist.rst │ ├── faq.rst │ ├── related-projects.rst │ ├── secrets-management-use-cases.rst │ └── summary-of-technologies.rst │ ├── secure-communication.rst │ ├── secure-communication │ ├── introduction-to-ssl-and-tls.rst │ ├── secure-reference-architectures.rst │ └── tls-proxies-and-http-services.rst │ ├── security-review.rst │ ├── security-review │ └── architecture-page-guidance.rst │ ├── shared-file-systems.rst │ ├── shared-file-systems │ ├── checklist.rst │ ├── intro.rst │ ├── network-and-security-models.rst │ ├── policies.rst │ ├── security-services.rst │ ├── share-acl.rst │ └── share-type-acl.rst │ ├── tenant-data.rst │ └── tenant-data │ ├── data-encryption.rst │ ├── data-privacy-concerns.rst │ └── key-management.rst ├── security-notes ├── OSSN-0001 ├── OSSN-0002 ├── OSSN-0003 ├── OSSN-0004 ├── OSSN-0005 ├── OSSN-0006 ├── OSSN-0007 ├── OSSN-0008 ├── OSSN-0009 ├── OSSN-0010 ├── OSSN-0011 ├── OSSN-0012 ├── OSSN-0013 ├── OSSN-0014 ├── OSSN-0015 ├── OSSN-0016 ├── OSSN-0017 ├── OSSN-0018 ├── OSSN-0019 ├── OSSN-0020 ├── OSSN-0021 ├── OSSN-0022 ├── OSSN-0023 ├── OSSN-0024 ├── OSSN-0025 ├── OSSN-0026 ├── OSSN-0027 ├── OSSN-0028 ├── OSSN-0029 ├── OSSN-0030 ├── OSSN-0031 ├── OSSN-0032 ├── OSSN-0033 ├── OSSN-0034 ├── OSSN-0035 ├── OSSN-0036 ├── OSSN-0037 ├── OSSN-0038 ├── OSSN-0039 ├── OSSN-0042 ├── OSSN-0043 ├── OSSN-0044 ├── OSSN-0045 ├── OSSN-0046 ├── OSSN-0047 ├── OSSN-0048 ├── OSSN-0049 ├── OSSN-0052 ├── OSSN-0053 ├── OSSN-0054 ├── OSSN-0055 ├── OSSN-0056 ├── OSSN-0057 ├── OSSN-0058 ├── OSSN-0059 ├── OSSN-0060 ├── OSSN-0061 ├── OSSN-0062 ├── OSSN-0063 ├── OSSN-0064 ├── OSSN-0065 ├── OSSN-0066 ├── OSSN-0068 ├── OSSN-0069 ├── OSSN-0070 ├── OSSN-0073 ├── OSSN-0077 ├── OSSN-0078 ├── OSSN-0079 ├── OSSN-0081 ├── OSSN-0082 ├── OSSN-0083 ├── OSSN-0084 ├── OSSN-0085 ├── OSSN-0086 ├── OSSN-0087 ├── OSSN-0089 ├── OSSN-0090 ├── OSSN-0091 ├── OSSN-0092 ├── OSSN-0093 ├── README.md └── template.txt ├── security-threat-analysis └── source │ ├── architecture-diagram-guidance.rst │ ├── conf.py │ ├── figures │ ├── Example_Generated-sequence-diagram.png │ ├── Template_Architecture-diagram.png │ ├── Template_DFD.png │ ├── Template_Sequence-diagram.png │ ├── arch_diagram.diag │ ├── arch_diagram.xml │ └── library_example.png │ ├── index.rst │ ├── templates │ ├── architecture-page.rst │ ├── review-findings.rst │ └── review-notes.rst │ ├── threat-analysis-process.rst │ └── todo.rst ├── test-requirements.txt ├── tools ├── build-all-rst.sh └── generatepot-rst.sh └── tox.ini /.gitignore: -------------------------------------------------------------------------------- 1 | # Packages 2 | .venv 3 | *.egg 4 | *.egg-info 5 | 6 | # Testenvironment 7 | .tox 8 | 9 | # Build directories 10 | publish-docs/ 11 | security-guide/build 12 | security-guide/source/locale/.doctrees 13 | security-threat-analysis/build 14 | 15 | # Transifex Client Setting 16 | .tx 17 | -------------------------------------------------------------------------------- /.gitreview: -------------------------------------------------------------------------------- 1 | [gerrit] 2 | host=review.opendev.org 3 | port=29418 4 | project=openstack/security-doc.git 5 | -------------------------------------------------------------------------------- /.zuul.yaml: -------------------------------------------------------------------------------- 1 | - project: 2 | templates: 3 | - openstack-manuals-build-translation 4 | - openstack-manuals-jobs 5 | check: 6 | jobs: 7 | - openstack-tox-linters 8 | gate: 9 | jobs: 10 | - openstack-tox-linters 11 | -------------------------------------------------------------------------------- /bindep.txt: -------------------------------------------------------------------------------- 1 | # This is a cross-platform list tracking distribution packages needed by tests; 2 | # see http://docs.openstack.org/infra/bindep/ for additional information. 3 | 4 | gettext 5 | rsync 6 | zlib-devel [platform:rpm] 7 | zlib1g-dev [platform:dpkg] 8 | -------------------------------------------------------------------------------- /case-studies/data-processing-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Case studies 3 | ============ 4 | 5 | Continuing with the studies described in 6 | :doc:`../introduction/introduction-to-case-studies` present Alice and 7 | Bob's approaches to deploying the Data processing service for their 8 | users. 9 | 10 | Alice's private cloud 11 | ~~~~~~~~~~~~~~~~~~~~~ 12 | 13 | Alice is deploying the Data processing service for a group of users 14 | that are trusted members of a collaboration. They are all placed in a 15 | single project and share the clusters, jobs, and data within. She 16 | deploys the controller with TLS enabled, using a certificate signed 17 | by the organization's root certificate. She configures the controller 18 | to provide floating IP addresses to the cluster instances allowing for 19 | users to gain access to the instances in the event of errors. She 20 | enables the use of proxy domains to prevent the users from needing to 21 | enter their credentials into the Data processing service. 22 | 23 | Bob's public cloud 24 | ~~~~~~~~~~~~~~~~~~ 25 | 26 | Bob's public cloud contains users that will not necessarily 27 | know or trust each other. He puts all users into separate projects. 28 | Each user has their own clusters, jobs, and data which cannot be 29 | accessed by other users. He deploys the controller with TLS enabled, 30 | using a certificate signed by a well known public certificate 31 | authority. He configures a custom topology to ensure that access to 32 | the provisioned cluster instances will flow through a controlled 33 | gateway. He creates a security group that opens only the ports needed 34 | for the controller to access the frameworks deployed. He enables the 35 | use of proxy domains to prevent the users from needing to enter their 36 | credentials into the Data processing service. He configures the 37 | rootwrap command to allow the data processing controller user to 38 | run the proxy commands. 39 | -------------------------------------------------------------------------------- /case-studies/databases-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Case studies 3 | ============ 4 | 5 | Earlier in :doc:`../introduction/introduction-to-case-studies` we 6 | introduced the Alice and Bob case studies where Alice is deploying a 7 | private government cloud and Bob is deploying a public cloud each with 8 | different security requirements. Here we discuss how Alice and Bob 9 | would address database selection and configuration for their respective 10 | private and public clouds. 11 | 12 | Alice's private cloud 13 | ~~~~~~~~~~~~~~~~~~~~~ 14 | 15 | Alice's organization has high availability concerns and so she has 16 | selected MySQL as the underlying database for the cloud services. She 17 | places the database on the Management network, utilizing SSL/TLS with 18 | mutual authentication among the services to ensure secure access. Based 19 | on the assumption that external access of the database will not be 20 | facilitated, she installs a certificate signed with the organization's 21 | root certificate on the database and its access endpoints. Alice creates 22 | separate user accounts for each database user then configures the 23 | database to use both passwords and X.509 certificates for 24 | authentication. She elects not to use the nova-conductor sub-service due 25 | to the desire for fine-grained access control policies and audit 26 | support. 27 | 28 | Bob's public cloud 29 | ~~~~~~~~~~~~~~~~~~ 30 | 31 | Bob is concerned about strong separation of his tenants' data, so he has 32 | elected to use the PostgreSQL database, known for its stronger security 33 | features. The database resides on the Management network and uses 34 | SSL/TLS with mutual authentication with the services. Since the database 35 | is on the Management network, the database uses certificates signed with 36 | the company's self-signed root certificate. Bob creates separate user 37 | accounts for each database user, and configures the database to use both 38 | passwords and X.509 certificates for authentication. He elects not to 39 | use the nova-conductor sub-service due to a desire for fine-grained 40 | access control. 41 | -------------------------------------------------------------------------------- /case-studies/identity-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Case studies 3 | ============ 4 | 5 | Earlier in :doc:`../introduction/introduction-to-case-studies` we 6 | introduced the Alice and Bob case studies where Alice is deploying a 7 | private government cloud and Bob is deploying a public cloud each with 8 | different security requirements. Here we discuss how Alice and Bob 9 | would address configuration of the OpenStack Identity service. Alice 10 | will be concerned with integration into the existing government 11 | directory services, while Bob will need to provide access to the 12 | public. 13 | 14 | Alice's private cloud 15 | ~~~~~~~~~~~~~~~~~~~~~ 16 | 17 | Alice's enterprise has a well-established directory service with 18 | two-factor authentication for all users. She configures the Identity 19 | service to support an external authentication service supporting 20 | authentication with government-issued access cards. She also uses an 21 | external LDAP server to provide role information for the roles that are 22 | integrated with the access control policy. Due to FedRAMP compliance 23 | requirements, Alice implements two-factor authentication on the 24 | management network for all administrator access. 25 | 26 | Alice also deploys the dashboard to manage many aspects of the cloud. 27 | She deploys the dashboard with HSTS to ensure that only HTTPS is used. 28 | The dashboard resides within an internal subdomain of the private 29 | network domain name system. 30 | 31 | Alice decides to use SPICE instead of VNC for the virtual console. She 32 | wants to take advantage of the emerging capabilities in SPICE. 33 | 34 | Bob's public cloud 35 | ~~~~~~~~~~~~~~~~~~ 36 | 37 | Because Bob must support authentication for the general public, he 38 | decides to use authentication based on a user name and password. He has 39 | concerns about brute force attacks attempting to crack user passwords, 40 | so he also uses an external authentication extension that throttles the 41 | number of failed login attempts. Bob's management network is separate 42 | from the other networks within his cloud, but can be reached from his 43 | corporate network through ssh. As recommended earlier, Bob requires 44 | administrators to use two-factor authentication on the Management 45 | network to reduce the risk of compromised administrator passwords. 46 | 47 | Bob also deploys the dashboard to manage many aspects of the cloud. He 48 | deploys the dashboard with HSTS to ensure that only HTTPS is used. He 49 | has ensured that the dashboard is deployed on a second-level domain due 50 | to the limitations of the same-origin policy. He also disables 51 | ``HORIZON_IMAGES_ALLOW_UPLOAD`` to prevent resource exhaustion. 52 | 53 | Bob decides to use VNC for his virtual console for its maturity and 54 | security features. 55 | -------------------------------------------------------------------------------- /case-studies/introduction-to-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============================ 2 | Introduction to case studies 3 | ============================ 4 | 5 | This guide refers to two running case studies, which are introduced here 6 | and referred to at the end of each chapter. 7 | 8 | Case study: Alice, the private cloud builder 9 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 10 | 11 | Alice is a technical manager overseeing a new OpenStack deployment for 12 | the US government in support of Healthcare.gov. The load on the cloud is 13 | expected to be variable, with moderate usage increasing to heavy usage 14 | during annual enrollment periods. She is aware that her private cloud 15 | will need to be certified against FISMA through the FedRAMP 16 | accreditation process required for all federal agencies, departments, 17 | and contractors as well as being under HIPAA purview. These compliance 18 | frameworks will place the burden of effort around logging, reporting, 19 | and policy. While technical controls will require Alice to use Public 20 | Key Infrastructure to encrypt wire-level communication, and SELinux for 21 | Mandatory Access Controls, Alice will invest in tool development to 22 | automate the reporting. Additionally, comprehensive documentation is 23 | expected covering application and network architecture, controls, and 24 | other details. The FedRAMP classification of Alice's system is High per 25 | FIPS-199. Alice will leverage existing authentication/authorization 26 | infrastructure in the form of Microsoft Active Directory, and an 27 | existing enterprise SEIM deployment that she will use to build new views 28 | and correlation rules to better monitor the state of her cloud. 29 | 30 | Case study: Bob, the public cloud provider 31 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 32 | 33 | Bob is the lead architect for a company deploying a new public cloud, 34 | focused on Infrastructure as a Service (IaaS). While this cloud will be 35 | open for any consumer with a valid credit card to have access to utility 36 | computing and storage, the primary focus will be enterprise customers. 37 | This means Bob's primary certification concern is PCI compliance, and 38 | his tooling will be developed around the auditing and reporting there, 39 | as well as the specific domains included in the PCI audit. As Bob's team 40 | is technically skilled in the Linux domain, he will be utilizing LDAP 41 | for federation. With plans to scale the cloud rapidly, Bob selects an 42 | open source log management deployment built for large-volumes of events 43 | with a highly customizable view. Data privacy and security concerns are 44 | the top barrier to adoption of the cloud, so Bob will also implement 45 | strict internal processes and two-factor authentication around 46 | sensitive assets, as well as allowing customers to leverage this for 47 | logins as well. 48 | -------------------------------------------------------------------------------- /case-studies/messaging-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Case studies 3 | ============ 4 | 5 | Earlier in :doc:`../introduction/introduction-to-case-studies` we 6 | introduced the Alice and Bob case studies where Alice is 7 | deploying a private government cloud and Bob is deploying a public cloud 8 | each with different security requirements. Here we discuss how Alice and 9 | Bob would address security concerns around the messaging service. 10 | 11 | The message queue is a critical piece of infrastructure that supports a 12 | number of OpenStack services but is most strongly associated with the 13 | Compute service. Due to the nature of the message queue service, Alice 14 | and Bob have similar security concerns. One of the larger concerns that 15 | remains is that many systems have access to this queue and there is no 16 | way for a consumer of the queue messages to verify which host or service 17 | placed the messages on the queue. An attacker who is able to 18 | successfully place messages on the queue is able to create and delete VM 19 | instances, attach the block storage of any tenant and a myriad of other 20 | malicious actions. There are a number of solutions anticipated in the 21 | near future, with several proposals for message signing and encryption 22 | making their way through the OpenStack development process. 23 | 24 | Alice's private cloud 25 | ~~~~~~~~~~~~~~~~~~~~~ 26 | 27 | In this case, Alice's controls are the same as Bob's controls, which are 28 | described below. 29 | 30 | Bob's public cloud 31 | ~~~~~~~~~~~~~~~~~~ 32 | 33 | Bob assumes the infrastructure or networks underpinning the Compute 34 | service could become compromised, therefore he recognizes the importance 35 | of hardening the system by restricting access to the message queue. In 36 | order to accomplish this task Bob deploys his RabbitMQ servers with TLS 37 | and X.509 client auth for access control. Hardening activities assists 38 | in limiting the capabilities of a malicious user that has compromised 39 | the system by disallowing queue access, provided that this user does not 40 | have valid credentials to override the controls. 41 | 42 | Additionally, Bob adds strong network ACL rulesets to enforce which 43 | endpoints can communicate with the message servers. This second control 44 | provides some additional assurance should the other protections fail. 45 | -------------------------------------------------------------------------------- /case-studies/networking-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Case studies 3 | ============ 4 | 5 | Earlier in :doc:`../introduction/introduction-to-case-studies` we introduced 6 | the Alice and Bob case studies where Alice is deploying a private government 7 | cloud and Bob is deploying a public cloud each with different security 8 | requirements. Here we discuss how Alice and Bob would address providing 9 | networking services to the user. 10 | 11 | Alice's private cloud 12 | ~~~~~~~~~~~~~~~~~~~~~ 13 | 14 | Alice picks nova-network due to its stability. She understands a migration from 15 | nova-network to OpenStack Networking (neutron) will not be easy, and keeps a 16 | blueprint for the migration that is refreshed every OpenStack release. This 17 | will ensure that Alice and her team are up-to-date with OpenStack Networking 18 | features even though they are focusing on nova-network, and will allow the 19 | migration plan to mature with Alice's experience with OpenStack to help enable 20 | a smooth transition. 21 | 22 | Alice configures nova-network with the VLAN network manager so that each tenant 23 | will have its own virtual network, keeping in mind the VLAN trunking will 24 | stress the environment and the scaling limit of 4096 tenants. She is aware that 25 | all traffic will pass through the virtual networking appliance, however she is 26 | comfortable with this given the hardware positioned to support the VLAN 27 | trunking across the entire environment. Additionally, as the nova-network 28 | hypervisor enforces the security group rules with iptables, invalid traffic 29 | will not be an issue. To ensure this, she designates a quarterly review of the 30 | security group rules for each VLAN. She understands there is no overlapping IP 31 | space and has ensured the deployment systems have separate IP ranges with room 32 | for growth until the migration to OpenStack Networking occurs. 33 | 34 | Bob's public cloud 35 | ~~~~~~~~~~~~~~~~~~ 36 | 37 | A major business driver for Bob is to provide an advanced networking services 38 | to his customers. Bob's customers would like to deploy multi-tiered 39 | application stacks. This multi-tiered application are either existing 40 | enterprise application or newly deployed applications. Since Bob's public cloud 41 | is a multi-tenancy enterprise service, the choice to use for L2 isolation in 42 | this environment is to use overlay networking. Another aspect of Bob's cloud is 43 | the self-service aspect where the customer can provision available networking 44 | services as needed. These networking services encompass L2 networks, L3 45 | Routing, Network :term:`ACL ` and NAT. It is 46 | important that per-tenant quota's be implemented in this environment. 47 | 48 | An added benefit with utilizing OpenStack Networking is when new advanced 49 | networking services become available, these new features can be easily provided 50 | to the end customers. 51 | -------------------------------------------------------------------------------- /case-studies/secure-communication-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Case studies 3 | ============ 4 | 5 | Earlier in :doc:`../introduction/introduction-to-case-studies` we 6 | introduced the Alice and Bob case study where Alice is deploying a 7 | government cloud and Bob is deploying a public cloud each with 8 | different security requirements. Here we discuss how Alice and Bob 9 | would address deployment of PKI certification authorities (CA) and 10 | certificate management. 11 | 12 | Alice's private cloud 13 | ~~~~~~~~~~~~~~~~~~~~~ 14 | 15 | After looking through the secure communication controls of 16 | both FedRAMP/FISMA and HIPAA, Alice decides to have all the 17 | systems use TLS 1.1 or greater, with export ciphers, the RC4 18 | encryption algorithm, and all versions of SSL disabled. She 19 | registers the website through a certificate signing company and 20 | validates her identity and workplace to get a public 21 | certificate. This is then added to the web application so that 22 | incoming clients will be able to use TLS. Internally, she 23 | configures a PKI infrastructure to failover across availability 24 | zones, and bundles the trust certificate into each golden 25 | image's certificate store so that new images will be able to use 26 | the certificate upon creation. She also notes in the golden 27 | image update policy that the certificate will need to be rotated 28 | in the image and on running instances before the expiration 29 | date. She also validates that HSTS is enabled on all web servers 30 | and other protections outlined in the Dashboard chapter. 31 | 32 | Bob's public cloud 33 | ~~~~~~~~~~~~~~~~~~ 34 | 35 | Bob is architecting a public cloud and needs to ensure that the 36 | publicly facing OpenStack services are using certificates issued by a 37 | major public CA. Bob acquires certificates for his public OpenStack 38 | services and configures the services to use PKI and TLS and includes 39 | the public CAs in his trust bundle for the services. Additionally, Bob 40 | also wants to further isolate the internal communications amongst the 41 | services within the management security domain. Bob contacts the team 42 | within his organization that is responsible for managing his 43 | organization's PKI and issuance of certificates using their own 44 | internal CA. Bob obtains certificates issued by this internal CA and 45 | configures the services that communicate within the management security 46 | domain to use these certificates and configures the services to only 47 | accept client certificates issued by his internal CA. 48 | -------------------------------------------------------------------------------- /case-studies/tenant-data-case-studies.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Case studies 3 | ============ 4 | 5 | 6 | Earlier in :doc:`../introduction/introduction-to-case-studies` we introduced 7 | the Alice and Bob case studies where Alice is deploying a private government 8 | cloud and Bob is deploying a public cloud each with different security 9 | requirements. Here we dive into their particular tenant data privacy 10 | requirements. Specifically, we will look into how Alice and Bob both handle 11 | tenant data, data destruction, and data encryption. 12 | 13 | Alice's private cloud 14 | ~~~~~~~~~~~~~~~~~~~~~ 15 | 16 | As stated during the introduction to Alice's case study, data protection is of 17 | an extremely high priority. She needs to ensure that a compromise of one 18 | tenant's data does not cause loss of other tenant data. She also has strong 19 | regulator requirements that require documentation of data destruction 20 | activities. Alice does this using the following: 21 | 22 | - Establishing procedures to sanitize tenant data when a program or 23 | project ends. 24 | - Track the destruction of both the tenant data and metadata through 25 | ticketing in a CMDB. 26 | - For Volume storage: 27 | 28 | - Physical server issues 29 | - To provide secure ephemeral instance storage, Alice implements 30 | qcow2 files on an encrypted filesystem. 31 | 32 | Bob's public cloud 33 | ~~~~~~~~~~~~~~~~~~ 34 | 35 | As stated during the introduction to Bob's case study, tenant privacy is 36 | of an extremely high priority. In addition to the requirements and 37 | actions Bob will take to isolate tenants from one another at the 38 | infrastructure layer, Bob also needs to provide assurances for tenant 39 | data privacy. He develops an OpenStack plug-in that tracks customer data 40 | and instances by monitoring log messages and pulling both hypervisor IDs 41 | and storage image locations. The plugin can also use built-in Linux 42 | tools to 'scrub' the data from disk. 43 | 44 | Bob ensures that the systems in each geographically distributed 45 | datacenter are physically secure. Where he is using a co-located 46 | facility, Bob ensures that the systems are physically separated and only 47 | accessible through logged and monitored keycard access. Additionally, 48 | each system has hardware encryption configured prior to shipping to the 49 | co-located factility. In a stand-alone datacenter, Bob maintains proper 50 | security throughout the facility by ensuring that systems have disk 51 | encryption enabled and that staff are trained in social engineering 52 | attacks. 53 | -------------------------------------------------------------------------------- /common/README.txt: -------------------------------------------------------------------------------- 1 | Important note about this directory 2 | =================================== 3 | 4 | Because this directory is synced from openstack-manuals, make any changes in 5 | openstack-manuals/doc/common. After changes to the synced files merge to 6 | openstack-manuals/doc/common, a patch is automatically proposed for this 7 | directory. 8 | -------------------------------------------------------------------------------- /common/conventions.rst: -------------------------------------------------------------------------------- 1 | .. ## WARNING ########################################################## 2 | .. This file is synced from openstack/openstack-manuals repository to 3 | .. other related repositories. If you need to make changes to this file, 4 | .. make the changes in openstack-manuals. After any change merged to, 5 | .. openstack-manuals, automatically a patch for others will be proposed. 6 | .. ##################################################################### 7 | 8 | =========== 9 | Conventions 10 | =========== 11 | 12 | The OpenStack documentation uses several typesetting conventions. 13 | 14 | Notices 15 | ~~~~~~~ 16 | 17 | Notices take these forms: 18 | 19 | .. note:: A comment with additional information that explains a part of the 20 | text. 21 | 22 | .. important:: Something you must be aware of before proceeding. 23 | 24 | .. tip:: An extra but helpful piece of practical advice. 25 | 26 | .. caution:: Helpful information that prevents the user from making mistakes. 27 | 28 | .. warning:: Critical information about the risk of data loss or security 29 | issues. 30 | 31 | Command prompts 32 | ~~~~~~~~~~~~~~~ 33 | 34 | .. code-block:: console 35 | 36 | $ command 37 | 38 | Any user, including the ``root`` user, can run commands that are 39 | prefixed with the ``$`` prompt. 40 | 41 | .. code-block:: console 42 | 43 | # command 44 | 45 | The ``root`` user must run commands that are prefixed with the ``#`` 46 | prompt. You can also prefix these commands with the :command:`sudo` 47 | command, if available, to run them. 48 | -------------------------------------------------------------------------------- /doc-tools-check-languages.conf: -------------------------------------------------------------------------------- 1 | # Example configuration for the languages 'ja' and 'fr'. 2 | 3 | # Directories to set up 4 | declare -A DIRECTORIES=( 5 | ) 6 | 7 | # Books to build 8 | declare -A BOOKS=( 9 | ["de"]="security-guide" 10 | ["id"]="security-guide" 11 | ["ja"]="security-guide" 12 | ["tr_TR"]="security-guide" 13 | ) 14 | 15 | # Location of doc dir 16 | DOC_DIR="./" 17 | 18 | # Books with special handling 19 | # Values need to match content in project-config/jenkins/scripts/common_translation_update.sh 20 | declare -A SPECIAL_BOOKS 21 | SPECIAL_BOOKS=( 22 | # Directory is using RST 23 | ["security-guide"]="RST" 24 | # These are translated in openstack-manuals 25 | ["common"]="skip" 26 | # Not translated 27 | ["security-threat-analysis"]="skip" 28 | ["security-notes"]="skip" 29 | ["case-studies"]="skip" 30 | ) 31 | -------------------------------------------------------------------------------- /security-guide/README.rst: -------------------------------------------------------------------------------- 1 | OpenStack Security Guide documentation 2 | ====================================== 3 | 4 | This document provides specific advice from the security documentation 5 | team about contributing to the 6 | `reStructuredText `_ 7 | version of the ``OpenStack Security Guide``. It contains the team's 8 | preferences for new patches and bug reports. 9 | 10 | For information about the structure of this repository, building the 11 | documentation, bug reporting locations, or general contribution notes, 12 | please see the 13 | `security-doc repository documentation `_. 14 | 15 | Reporting bugs 16 | -------------- 17 | 18 | When reporting bugs to the ``OpenStack Security Guide``, the team has a 19 | preference for scoping the bugs to the chapters in which they occur, 20 | even for bugs which may require a similar change across disparate 21 | sections of the guide. This breakdown gives the team members a clearer 22 | view of the specific bug cases and makes the review process quicker as 23 | the individual reviews tend to be more manageable. 24 | 25 | Creating reviews 26 | ---------------- 27 | 28 | In a similar style as bug reporting, the security documentation team 29 | prefers reviews which are scoped at the chapter level. For example, if 30 | proposing a change which will refactor the syntax of a specific 31 | element, the change should be submitted on a per-chapter basis. 32 | 33 | Reviews should also be scoped to cover a single issue. When possible, 34 | please split your reviews based on the bug topics that are being 35 | addressed. 36 | 37 | General note on consistency 38 | --------------------------- 39 | 40 | These guidelines may seem overly specific in the terms that they 41 | define, but they have evolved over several cycles of working on the 42 | ``OpenStack Security Guide``. In general, the team prefers these stylistic 43 | choices as they make the review and improvement process much smoother. 44 | That being said, for very small changes, or in cases where it would 45 | create an excessive amount of noise, the boundaries defined by these 46 | guidelines can be stretched. As always, please use your best judgment 47 | or ask the security documentation team for advice. 48 | -------------------------------------------------------------------------------- /security-guide/source/api-endpoints.rst: -------------------------------------------------------------------------------- 1 | ============= 2 | API endpoints 3 | ============= 4 | 5 | The process of engaging an OpenStack cloud is started through the querying of 6 | an API endpoint. While there are different challenges for public and private 7 | endpoints, these are high value assets that can pose a significant risk if 8 | compromised. 9 | 10 | This chapter recommends security enhancements for both public and 11 | private-facing API endpoints. 12 | 13 | .. toctree:: 14 | :maxdepth: 2 15 | 16 | api-endpoints/api-endpoint-configuration-recommendations.rst 17 | -------------------------------------------------------------------------------- /security-guide/source/appendix.rst: -------------------------------------------------------------------------------- 1 | Appendix 2 | ~~~~~~~~ 3 | 4 | .. toctree:: 5 | :maxdepth: 1 6 | 7 | common/app-support.rst 8 | common/glossary.rst 9 | 10 | -------------------------------------------------------------------------------- /security-guide/source/block-storage.rst: -------------------------------------------------------------------------------- 1 | ============= 2 | Block Storage 3 | ============= 4 | 5 | OpenStack Block Storage (cinder) is a service that provides software 6 | (services and libraries) to self-service manage persistent block-level 7 | storage devices. This creates on-demand access to Block Storage 8 | resources for use with OpenStack Compute (nova) instances. This 9 | creates software-defined storage via abstraction by virtualizing pools 10 | of block storage to a variety of back-end storage devices which can be 11 | either software implementations or traditional hardware storage 12 | products. The primary functions of this is to manage the creation, 13 | attaching and detaching of the block devices. The consumer requires no 14 | knowledge of the type of back-end storage equipment or where it is 15 | located. 16 | 17 | Compute instances store and retrieve block storage via 18 | industry-standard storage protocols such as iSCSI, ATA over Ethernet, 19 | or Fibre-Channel. These resources are managed and configured via 20 | OpenStack native standard HTTP RESTful API. For more details on the 21 | API see the `OpenStack Block Storage documentation 22 | `__. 23 | 24 | .. toctree:: 25 | :maxdepth: 2 26 | 27 | block-storage/volume_wiping.rst 28 | block-storage/checklist.rst 29 | 30 | .. note:: 31 | 32 | Whilst this chapter is currently sparse on specific 33 | guidance, it is expected that standard hardening practices 34 | will be followed. This section will be expanded with relevant 35 | information. 36 | -------------------------------------------------------------------------------- /security-guide/source/block-storage/volume_wiping.rst: -------------------------------------------------------------------------------- 1 | ============= 2 | Volume Wiping 3 | ============= 4 | 5 | There are several ways to wipe a block storage device. The traditional way is 6 | to set the ``lvm_type`` to ``thin``, and then use the ``volume_clear`` 7 | parameter if using the LVM backend. Alternatively, if the volume encryption 8 | feature is used, then volume wiping is not necessary if the volume encryption 9 | key is deleted. See the OpenStack Configuration Reference doc in the 10 | `Volume Encryption 11 | `__ 12 | section for set up details and also the `Castellan usage 13 | `__ document 14 | for key deletion. 15 | 16 | .. note:: 17 | 18 | In older OpenStack releases, ``lvm_type=default`` was used to signify a 19 | wipe. While this method still works, ``lvm_type=default`` is not 20 | recommended for setting secure delete. 21 | 22 | The ``volume_clear`` parameter can be set to ``zero``. The ``zero`` argument 23 | will write a single pass of zeroes to the device. 24 | 25 | For more information about the ``lvm_type`` parameter, see sections 26 | `LVM 27 | `__ 28 | and `Oversubscription in thin provisioning 29 | `__ 30 | of the *cinder* project documentation. 31 | 32 | For more information about the ``volume_clear`` parameter, see section 33 | `Cinder Configuration Options 34 | `__ 35 | of the *cinder* project documentation. 36 | -------------------------------------------------------------------------------- /security-guide/source/checklist.rst: -------------------------------------------------------------------------------- 1 | ================== 2 | Security Checklist 3 | ================== 4 | 5 | * :doc:`Identity service checklist ` 6 | * :doc:`Dashboard checklist ` 7 | * :doc:`Compute service checklist ` 8 | * :doc:`Block Storage service checklist ` 9 | * :doc:`Shared File Systems service checklist ` 10 | * :doc:`Networking service checklist ` 11 | -------------------------------------------------------------------------------- /security-guide/source/common: -------------------------------------------------------------------------------- 1 | ../../common -------------------------------------------------------------------------------- /security-guide/source/compliance.rst: -------------------------------------------------------------------------------- 1 | ========== 2 | Compliance 3 | ========== 4 | 5 | An OpenStack deployment may require compliance activities for many 6 | purposes, such as regulatory and legal requirements, customer need, 7 | privacy considerations, and security best practices. The Compliance 8 | function is important for the business and its customers. Compliance 9 | means adhering to regulations, specifications, standards and laws. It is 10 | also used when describing an organizations status regarding assessments, 11 | audits, and certifications. Compliance, when done correctly, unifies and 12 | strengthens the other security topics discussed in this guide. 13 | 14 | This chapter has several objectives: 15 | 16 | - Review common security principles. 17 | 18 | - Discuss common control frameworks and certification resources to 19 | achieve industry certifications or regulator attestations. 20 | 21 | - Act as a reference for auditors when evaluating OpenStack 22 | deployments. 23 | 24 | - Introduce privacy considerations specific to OpenStack and cloud 25 | environments. 26 | 27 | .. toctree:: 28 | :maxdepth: 2 29 | 30 | compliance/overview.rst 31 | compliance/understanding-the-audit-process.rst 32 | compliance/compliance-activities.rst 33 | compliance/certification-and-compliance-statements.rst 34 | compliance/privacy.rst 35 | .. case-studies/compliance-case-studies.rst 36 | -------------------------------------------------------------------------------- /security-guide/source/compliance/privacy.rst: -------------------------------------------------------------------------------- 1 | ======= 2 | Privacy 3 | ======= 4 | 5 | Privacy is an increasingly important element of a compliance program. 6 | Businesses are being held to a higher standard by their customers, who 7 | have increased interest in understanding how their data is treated from 8 | a privacy perspective. 9 | 10 | An OpenStack deployment will likely need to demonstrate compliance with 11 | an organization's Privacy Policy, with the U.S.-E.U. Safe Harbor 12 | framework, the ISO/IEC 29100:2011 privacy framework or with other 13 | privacy-specific guidelines. In the U.S. the AICPA has `defined 10 14 | privacy areas of 15 | focus `_, 16 | OpenStack deployments within a commercial environment may desire to 17 | attest to some or all of these principles. 18 | 19 | To aid OpenStack architects in the protection of personal data, we 20 | recommend OpenStack architects review the NIST publication 21 | 800-122, titled "*Guide to Protecting the Confidentiality of Personally 22 | Identifiable Information (PII)*." This guide steps through the process 23 | of protecting: 24 | 25 | "... any information about an individual maintained by an agency, 26 | including (1) any information that can be used to distinguish or 27 | trace an individual's identity, such as name, social security 28 | number, date and place of birth, mother's maiden name, or biometric 29 | records; and (2) any other information that is linked or linkable to 30 | an individual, such as medical, educational, financial, and 31 | employment information..." 32 | 33 | Comprehensive privacy management requires significant preparation, 34 | thought and investment. Additional complications are introduced when 35 | building global OpenStack clouds, for example navigating the differences 36 | between U.S. and more restrictive E.U. privacy laws. In addition, extra 37 | care needs to be taken when dealing with sensitive PII that may include 38 | information such as credit card numbers or medical records. This 39 | sensitive data is not only subject to privacy laws but also regulatory 40 | and governmental regulations. By deferring to established best 41 | practices, including those published by governments, a holistic privacy 42 | management policy may be created and practiced for OpenStack 43 | deployments. 44 | -------------------------------------------------------------------------------- /security-guide/source/compute.rst: -------------------------------------------------------------------------------- 1 | ======= 2 | Compute 3 | ======= 4 | 5 | The OpenStack Compute service (nova) runs in many locations throughout 6 | the cloud and interacts with a variety of internal services. 7 | The OpenStack Compute service offers a variety of configuration options 8 | which may be deployment specific. 9 | 10 | In this chapter we will call out general best practice around Compute 11 | security as well as specific known configurations that can lead to 12 | security issues. The ``nova.conf`` file and the ``/var/lib/nova`` locations 13 | should be secured. Controls like centralized logging, the ``policy.json`` 14 | file, and a mandatory access control framework should be implemented. 15 | 16 | .. toctree:: 17 | :maxdepth: 2 18 | 19 | compute/hypervisor-selection.rst 20 | compute/hardening-the-virtualization-layers.rst 21 | compute/hardening-deployments.rst 22 | compute/vulnerability-awareness.rst 23 | compute/how-to-select-virtual-consoles.rst 24 | compute/checklist.rst 25 | -------------------------------------------------------------------------------- /security-guide/source/dashboard.rst: -------------------------------------------------------------------------------- 1 | ========= 2 | Dashboard 3 | ========= 4 | 5 | The Dashboard (horizon) is the OpenStack dashboard that provides users a 6 | self-service portal to provision their own resources within the limits set 7 | by administrators. These include provisioning users, defining instance flavors, 8 | uploading virtual machine (VM) images, managing networks, setting up security 9 | groups, starting instances, and accessing the instances through a console. 10 | 11 | The Dashboard is based on the Django web framework, ensuring secure deployment 12 | practices for Django apply directly to horizon. This guide provides a 13 | set of Django security recommendations. Further information can be found by 14 | reading the `Django documentation `_. 15 | 16 | The Dashboard ships with default security settings, and has 17 | `deployment and configuration documentation 18 | `_. 19 | 20 | .. toctree:: 21 | :maxdepth: 2 22 | 23 | dashboard/domains-dashboard-upgrades-basic-web-server-configuration.rst 24 | dashboard/https-hsts-xss-ssrf.rst 25 | dashboard/front-end-caching-session-back-end.rst 26 | dashboard/static-media.rst 27 | dashboard/passwords.rst 28 | dashboard/secret-key.rst 29 | dashboard/cookies.rst 30 | dashboard/cross-origin-resource-sharing-cors.rst 31 | dashboard/debug.rst 32 | dashboard/checklist.rst 33 | .. case-studies/dashboard-case-studies.rst 34 | -------------------------------------------------------------------------------- /security-guide/source/dashboard/cookies.rst: -------------------------------------------------------------------------------- 1 | ======= 2 | Cookies 3 | ======= 4 | 5 | Session cookies should be set to HTTPONLY: 6 | 7 | .. code:: python 8 | 9 | SESSION_COOKIE_HTTPONLY = True 10 | 11 | Never configure CSRF or session cookies to have a wild card 12 | domain with a leading dot. Horizon's session and CSRF cookie 13 | should be secured when deployed with HTTPS: 14 | 15 | .. code:: python 16 | 17 | CSRF_COOKIE_SECURE = True 18 | SESSION_COOKIE_SECURE = True 19 | -------------------------------------------------------------------------------- /security-guide/source/dashboard/cross-origin-resource-sharing-cors.rst: -------------------------------------------------------------------------------- 1 | ==================================== 2 | Cross Origin Resource Sharing (CORS) 3 | ==================================== 4 | 5 | Configure your web server to send a restrictive CORS header 6 | with each response, allowing only the dashboard domain and 7 | protocol: 8 | 9 | .. code:: 10 | 11 | Access-Control-Allow-Origin: https://example.com/ 12 | 13 | Never allow the wild card origin. 14 | -------------------------------------------------------------------------------- /security-guide/source/dashboard/debug.rst: -------------------------------------------------------------------------------- 1 | ===== 2 | Debug 3 | ===== 4 | 5 | We recommend that the ``DEBUG`` setting 6 | is set to ``False`` in production environments. 7 | If ``DEBUG`` is set to True, 8 | Django will display stack traces and sensitive web server 9 | state information when exceptions are thrown. 10 | -------------------------------------------------------------------------------- /security-guide/source/dashboard/front-end-caching-session-back-end.rst: -------------------------------------------------------------------------------- 1 | ====================================== 2 | Front-end caching and session back end 3 | ====================================== 4 | 5 | Front-end caching 6 | ~~~~~~~~~~~~~~~~~ 7 | 8 | We do not recommend using front-end caching tools with the 9 | dashboard. The dashboard is rendering dynamic content resulting 10 | directly from OpenStack API requests and front-end caching layers 11 | such as varnish can prevent the correct content from being 12 | displayed. In Django, static media is directly served from Apache 13 | or :term:`Nginx` and already benefits from web host caching. 14 | 15 | Session back end 16 | ~~~~~~~~~~~~~~~~ 17 | 18 | The default session back end for horizon 19 | ``django.contrib.sessions.backends.signed_cookies`` 20 | saves user data in signed, but unencrypted cookies stored in the 21 | browser. Due to the fact that each dashboard instance is 22 | stateless, the previously mentioned methodology provides the 23 | ability to implement the most simple session back-end scaling. 24 | 25 | It should be noted that with this type of implementation 26 | sensitive access tokens will be stored in the browser and will be 27 | transmitted with each request made. The back end ensures the 28 | integrity of session data, even though the transmitted data 29 | is only encrypted by HTTPS. 30 | 31 | If your architecture allows for shared storage and and if you 32 | have configured your cache correctly, we recommend setting your 33 | ``SESSION_ENGINE`` to ``django.contrib.sessions.backends.cache`` 34 | and using it as cache-based session backend with memcached as 35 | the cache. Memcached is an efficient in-memory key-value store 36 | for chunks of data that can be used in a high availability and 37 | distributed environment and is easy to configure. However, you 38 | need to ensure that there is no data leakage. Memcached makes use 39 | of spare RAM to store frequently accessed data blocks, acting 40 | like memory cache for repeatedly accessed information. Since 41 | memcached utilizes local memory, there is no overhead of 42 | database and file system usage leading to direct access of data 43 | from RAM rather than from disk. 44 | 45 | We recommend the use of memcached instead of local-memory cache 46 | because it is fast, retains data for a longer duration, is 47 | multi-process safe and has the ability to share cache over 48 | multiple servers, but still treats it as a single cache. 49 | 50 | To enable memcached, execute the following: 51 | 52 | .. code-block:: ini 53 | 54 | SESSION_ENGINE = 'django.contrib.sessions.backends.cache' 55 | CACHES = { 56 | 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache' 57 | } 58 | 59 | For further details, see the 60 | `Django documentation `_. 61 | -------------------------------------------------------------------------------- /security-guide/source/dashboard/passwords.rst: -------------------------------------------------------------------------------- 1 | ========= 2 | Passwords 3 | ========= 4 | 5 | Password management should be an integral part of your cloud administration 6 | plan. A definitive tutorial about passwords is beyond the scope of this book; 7 | however, cloud administrators should refer to the best practices recommended 8 | in Chapter 4 of NIST Special Publication 9 | `Guide to Enterprise Password Management `_. 10 | 11 | Browser-based access to the OpenStack cloud, whether through the dashboard or 12 | other applications, introduces additional considerations. Modern browsers all 13 | support some form of password storage and autofilling of credentials for 14 | remembered sites. This can be useful when using strong passwords that cannot 15 | be easily remembered or typed, but may cause the browser to become the weak 16 | link if the physical security of the client is compromised. If the 17 | browser's password store itself is not protected by a strong password, or if 18 | the password store is allowed to remain unlocked for the duration of the 19 | session, unauthorized access to your system can be easily obtained. 20 | 21 | Password management applications such as `KeePassX `_ 22 | and `Password Safe `_ can be useful as most support the 23 | generation of strong passwords and periodic reminders to generate new 24 | passwords. Most importantly, the password store remains unlocked only 25 | briefly, which reduces the risk of password exposure and unauthorized resource 26 | access through browser or system compromise. 27 | 28 | -------------------------------------------------------------------------------- /security-guide/source/dashboard/secret-key.rst: -------------------------------------------------------------------------------- 1 | ========== 2 | Secret key 3 | ========== 4 | 5 | The dashboard depends on a shared ``SECRET_KEY`` 6 | setting for some security functions. The secret key should be a 7 | randomly generated string at least 64 characters long, which must 8 | be shared across all active dashboard instances. Compromise of this 9 | key may allow a remote attacker to execute arbitrary code. Rotating 10 | this key invalidates existing user sessions and caching. Do not 11 | commit this key to public repositories. 12 | -------------------------------------------------------------------------------- /security-guide/source/dashboard/static-media.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Static media 3 | ============ 4 | 5 | The dashboard's static media should be deployed to a subdomain 6 | of the dashboard domain and served by the web server. The use of 7 | an external content delivery network (CDN) is also acceptable. 8 | This subdomain should not set cookies or serve user-provided 9 | content. The media should also be served with HTTPS. 10 | 11 | Django media settings are documented in the 12 | `Django documentation `_. 13 | 14 | Dashboard's default configuration uses 15 | `django_compressor `_ 16 | to compress and minify CSS and 17 | JavaScript content before serving it. This process should be 18 | statically done before deploying the dashboard, rather than using 19 | the default in-request dynamic compression and copying the 20 | resulting files along with deployed code or to the CDN server. 21 | Compression should be done in a non-production build 22 | environment. If this is not practical, we recommend disabling 23 | resource compression entirely. Online compression dependencies 24 | (less, Node.js) should not be installed on production 25 | machines. 26 | -------------------------------------------------------------------------------- /security-guide/source/data-processing.rst: -------------------------------------------------------------------------------- 1 | =============== 2 | Data processing 3 | =============== 4 | 5 | The Data Processing service (sahara) provides a platform 6 | for the provisioning and management of instance clusters using processing 7 | frameworks such as Hadoop and Spark. Through the OpenStack Dashboard, 8 | or REST API, users are able to upload and execute framework 9 | applications which may access data in object storage or external 10 | providers. The data processing controller uses the Orchestration 11 | service (heat) to create clusters of instances which may exist as 12 | long-running groups that can grow and shrink as requested, or as 13 | transient groups created for a single workload. 14 | 15 | .. toctree:: 16 | :maxdepth: 2 17 | 18 | data-processing/introduction-to-data-processing.rst 19 | data-processing/deployment.rst 20 | data-processing/configuration-and-hardening.rst 21 | .. case-studies/data-processing-case-studies.rst 22 | -------------------------------------------------------------------------------- /security-guide/source/databases.rst: -------------------------------------------------------------------------------- 1 | ========= 2 | Databases 3 | ========= 4 | 5 | The choice of database server is an important consideration in the 6 | security of an OpenStack deployment. Multiple factors should be 7 | considered when deciding on a database server, however for the scope of 8 | this book only security considerations will be discussed. OpenStack 9 | supports a variety of database types. See the `OpenStack Administrator 10 | Guide `_ for more 11 | information. 12 | 13 | The Security Guide currently focuses on PostgreSQL and MySQL. 14 | 15 | .. toctree:: 16 | :maxdepth: 2 17 | 18 | databases/database-backend-considerations.rst 19 | databases/database-access-control.rst 20 | databases/database-transport-security.rst 21 | .. case-studies/database-case-studies.rst 22 | -------------------------------------------------------------------------------- /security-guide/source/databases/database-backend-considerations.rst: -------------------------------------------------------------------------------- 1 | ================================ 2 | Database back end considerations 3 | ================================ 4 | 5 | PostgreSQL has a number of desirable security features such as Kerberos 6 | authentication, object-level security, and encryption support. The 7 | PostgreSQL community has done well to provide solid guidance, 8 | documentation, and tooling to promote positive security practices. 9 | 10 | MySQL has a large community, widespread adoption, and provides high 11 | availability options. MySQL also has the ability to provide enhanced 12 | client authentication by way of plug-in authentication mechanisms. 13 | Forked distributions in the MySQL community provide many options for 14 | consideration. It is important to choose a specific implementation of 15 | MySQL based on a thorough evaluation of the security posture and the 16 | level of support provided for the given distribution. 17 | 18 | Security references for database back ends 19 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20 | 21 | Those deploying MySQL or PostgreSQL are advised to refer to existing 22 | security guidance. Some references are listed below: 23 | 24 | MySQL: 25 | 26 | - `OWASP MySQL 27 | Hardening `__ 28 | 29 | - `MySQL Pluggable 30 | Authentication `__ 31 | 32 | - `Security in 33 | MySQL `__ 34 | 35 | PostgreSQL: 36 | 37 | - `OWASP PostgreSQL 38 | Hardening `__ 39 | 40 | - `Total security in a PostgreSQL 41 | database `__ 42 | -------------------------------------------------------------------------------- /security-guide/source/documentation.rst: -------------------------------------------------------------------------------- 1 | ==================== 2 | System documentation 3 | ==================== 4 | 5 | The system documentation for an OpenStack cloud deployment should follow the 6 | templates and best practices for the Enterprise Information Technology System 7 | in your organization. Organizations often have compliance requirements which 8 | may require an overall System Security Plan to inventory and document the 9 | architecture of a given system. There are common challenges across the industry 10 | related to documenting the dynamic cloud infrastructure and keeping the 11 | information up-to-date. 12 | 13 | .. toctree:: 14 | :maxdepth: 2 15 | 16 | documentation/system-documentation-requirements.rst 17 | .. case-studies/documentation-case-studies.rst 18 | -------------------------------------------------------------------------------- /security-guide/source/figures/1aa-logical-neutron-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/1aa-logical-neutron-flow.png -------------------------------------------------------------------------------- /security-guide/source/figures/1aa-network-domains-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/1aa-network-domains-diagram.png -------------------------------------------------------------------------------- /security-guide/source/figures/book-sprint-all-logos.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/book-sprint-all-logos.png -------------------------------------------------------------------------------- /security-guide/source/figures/bridging_domains_clouduser.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/bridging_domains_clouduser.png -------------------------------------------------------------------------------- /security-guide/source/figures/bridging_security_domains_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/bridging_security_domains_1.png -------------------------------------------------------------------------------- /security-guide/source/figures/data_processing_architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/data_processing_architecture.png -------------------------------------------------------------------------------- /security-guide/source/figures/databaseusername.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/databaseusername.png -------------------------------------------------------------------------------- /security-guide/source/figures/databaseusernamessl.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/databaseusernamessl.png -------------------------------------------------------------------------------- /security-guide/source/figures/filteringWorkflow1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/filteringWorkflow1.png -------------------------------------------------------------------------------- /security-guide/source/figures/group.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/group.png -------------------------------------------------------------------------------- /security-guide/source/figures/high-capability.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/high-capability.png -------------------------------------------------------------------------------- /security-guide/source/figures/manila-intro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/manila-intro.png -------------------------------------------------------------------------------- /security-guide/source/figures/marketecture-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/marketecture-diagram.png -------------------------------------------------------------------------------- /security-guide/source/figures/node-provisioning-pxe.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/node-provisioning-pxe.png -------------------------------------------------------------------------------- /security-guide/source/figures/novaconductor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/novaconductor.png -------------------------------------------------------------------------------- /security-guide/source/figures/sVirt_Diagram_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/sVirt_Diagram_1.png -------------------------------------------------------------------------------- /security-guide/source/figures/sdn-connections.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/sdn-connections.png -------------------------------------------------------------------------------- /security-guide/source/figures/secure-arch-ref-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/secure-arch-ref-1.png -------------------------------------------------------------------------------- /security-guide/source/figures/secure-arch-ref-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/secure-arch-ref-2.png -------------------------------------------------------------------------------- /security-guide/source/figures/secure-arch-ref-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/secure-arch-ref-3.png -------------------------------------------------------------------------------- /security-guide/source/figures/secure-arch-ref-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/secure-arch-ref-4.png -------------------------------------------------------------------------------- /security-guide/source/figures/security_review_barbican_architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/security_review_barbican_architecture.png -------------------------------------------------------------------------------- /security-guide/source/figures/swift_network_diagram-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/swift_network_diagram-1.png -------------------------------------------------------------------------------- /security-guide/source/figures/swift_network_diagram-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/swift_network_diagram-2.png -------------------------------------------------------------------------------- /security-guide/source/figures/threat_actors.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/threat_actors.png -------------------------------------------------------------------------------- /security-guide/source/figures/untrusted_trusted.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-guide/source/figures/untrusted_trusted.png -------------------------------------------------------------------------------- /security-guide/source/identity.rst: -------------------------------------------------------------------------------- 1 | ======== 2 | Identity 3 | ======== 4 | 5 | Identity service (keystone) provides identity, token, catalog, and 6 | policy services for use specifically by services in the OpenStack 7 | family. Identity service is organized as a group of internal services 8 | exposed on one or many endpoints. Many of these services are used in a 9 | combined fashion by the front end. For example, an authentication call 10 | validates user and project credentials with the identity service. 11 | If successful, it will create and return a token with the token service. 12 | More information can be found by reading the `keystone Developer 13 | Documentation `_. 14 | 15 | .. toctree:: 16 | :maxdepth: 2 17 | 18 | identity/authentication.rst 19 | identity/authentication-methods.rst 20 | identity/authorization.rst 21 | identity/policies.rst 22 | identity/tokens.rst 23 | identity/domains.rst 24 | identity/federated-keystone.rst 25 | identity/checklist.rst 26 | .. case-studies/identity-case-studies.rst 27 | -------------------------------------------------------------------------------- /security-guide/source/identity/domains.rst: -------------------------------------------------------------------------------- 1 | ======= 2 | Domains 3 | ======= 4 | 5 | Domains are high-level containers for projects, users and groups. As 6 | such, they can be used to centrally manage all keystone-based identity 7 | components. With the introduction of account domains, server, storage 8 | and other resources can now be logically grouped into multiple projects 9 | (previously called tenants) which can themselves be grouped under a 10 | master account-like container. In addition, multiple users can be 11 | managed within an account domain and assigned roles that vary for each 12 | project. 13 | 14 | The Identity V3 API supports multiple domains. Users of different 15 | domains may be represented in different authentication back ends and 16 | even have different attributes that must be mapped to a single set of 17 | roles and privileges, that are used in the policy definitions to access 18 | the various service resources. 19 | 20 | Where a rule may specify access to only admin users and users belonging 21 | to the tenant, the mapping may be trivial. In other scenarios the cloud 22 | administrator may need to approve the mapping routines per tenant. 23 | 24 | Domain-specific authentication drivers allow the Identity service 25 | to be configured for multiple domains using domain-specific configuration 26 | files. Enabling the drivers and setting the domain-specific configuration file 27 | location occur in the ``[identity]`` section of the ``keystone.conf`` file: 28 | 29 | .. code:: ini 30 | 31 | [identity] 32 | domain_specific_drivers_enabled = True 33 | domain_config_dir = /etc/keystone/domains 34 | 35 | Any domains without a domain-specific configuration file 36 | will use options in the primary ``keystone.conf`` file. 37 | -------------------------------------------------------------------------------- /security-guide/source/identity/federated-keystone.rst: -------------------------------------------------------------------------------- 1 | ================== 2 | Federated keystone 3 | ================== 4 | 5 | Some important definitions: 6 | 7 | Service Provider (SP) 8 | A system entity that provides services to principals or other system 9 | entities, in this case, OpenStack Identity is the Service Provider. 10 | 11 | Identity Provider (IdP) 12 | A directory service, such as LDAP, RADIUS and Active Directory, 13 | which allows users to login with a user name and password, is a 14 | typical source of authentication tokens (e.g. passwords) at an 15 | :term:`identity provider`. 16 | 17 | :term:`Federated Identity` is a mechanism to 18 | establish trusts between IdPs and SPs, in this case, between Identity 19 | Providers and the services provided by an OpenStack Cloud. It provides a 20 | secure way to use existing credentials to access cloud resources such as 21 | servers, volumes, and databases, across multiple endpoints. The credential 22 | is maintained by the user's IdP. 23 | 24 | Why use Federated Identity? 25 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 26 | 27 | Two underlying reasons: 28 | 29 | 1) Reduced complexity makes your deployment easier to secure. 30 | 2) It saves time for you and your users. 31 | 32 | - Centralize account management to prevent duplication of effort inside 33 | OpenStack infrastructure. 34 | 35 | - Reduce burden on users. Single sign on lets a single authentication method 36 | be used to access many different services & environments. 37 | 38 | - Move responsibility of password recovery process to IdP. 39 | 40 | Futher justification and details can be found in Keystone's `documentation 41 | on federation `_. 42 | -------------------------------------------------------------------------------- /security-guide/source/identity/policies.rst: -------------------------------------------------------------------------------- 1 | .. _policy-section: 2 | 3 | ======== 4 | Policies 5 | ======== 6 | 7 | Each OpenStack service defines the access policies for its resources in an 8 | associated policy file. A resource, for example, could be API access, the 9 | ability to attach to a volume, or to fire up instances. The policy rules are 10 | specified in JSON format and the file is called ``policy.json``. The 11 | syntax and format of this file is discussed in the `Configuration Reference 12 | `__. 13 | 14 | These policies can be modified or updated by the cloud administrator to 15 | control the access to the various resources. Ensure that any changes to the 16 | access control policies do not unintentionally weaken the security of any 17 | resource. Also note that changes to the ``policy.json`` file become effective 18 | immediately and do not require the service to be restarted. 19 | 20 | The following example shows how the service can restrict access to create, 21 | update and delete resources to only those users which have the role of 22 | ``cloud_admin``, which has been defined as being the conjunction of 23 | ``role = admin`` and ``domain_id = admin_domain_id``, while the get and list 24 | resources are made available to users which have the role of ``cloud_admin`` 25 | or ``admin``. 26 | 27 | .. code:: json 28 | 29 | { 30 | "admin_required": "role:admin", 31 | "cloud_admin": "rule:admin_required and domain_id:admin_domain_id", 32 | "service_role": "role:service", 33 | "service_or_admin": "rule:admin_required or rule:service_role", 34 | "owner" : "user_id:%(user_id)s or user_id:%(target.token.user_id)s", 35 | "admin_or_owner": "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or rule:owner", 36 | "admin_or_cloud_admin": "rule:admin_required or rule:cloud_admin", 37 | "admin_and_matching_domain_id": "rule:admin_required and domain_id:%(domain_id)s", 38 | "service_admin_or_owner": "rule:service_or_admin or rule:owner", 39 | 40 | "default": "rule:admin_required", 41 | 42 | "identity:get_service": "rule:admin_or_cloud_admin", 43 | "identity:list_services": "rule:admin_or_cloud_admin", 44 | "identity:create_service": "rule:cloud_admin", 45 | "identity:update_service": "rule:cloud_admin", 46 | "identity:delete_service": "rule:cloud_admin", 47 | 48 | "identity:get_endpoint": "rule:admin_or_cloud_admin", 49 | "identity:list_endpoints": "rule:admin_or_cloud_admin", 50 | "identity:create_endpoint": "rule:cloud_admin", 51 | "identity:update_endpoint": "rule:cloud_admin", 52 | "identity:delete_endpoint": "rule:cloud_admin", 53 | 54 | } 55 | 56 | -------------------------------------------------------------------------------- /security-guide/source/identity/tokens.rst: -------------------------------------------------------------------------------- 1 | ====== 2 | Tokens 3 | ====== 4 | 5 | Once a user is authenticated, a token is generated for authorization and 6 | access to an OpenStack environment. A token can have a variable life 7 | span; however the default value for expiry is one hour. The recommended 8 | expiry value should be set to a lower value that allows enough time for 9 | internal services to complete tasks. In the event that the token expires 10 | before tasks complete, the cloud may become unresponsive or stop providing 11 | services. An example of expended time during use would be the time 12 | needed by the Compute service to transfer a disk image onto the 13 | hypervisor for local caching. Fetching expired tokens when using 14 | a valid service token is allowed. 15 | 16 | The token is often passed within the structure of a larger context of an 17 | Identity service response. These responses also provide a catalog of the 18 | various OpenStack services. Each service is listed with its name, access 19 | endpoints for internal, admin, and public access. 20 | 21 | Tokens can be revoked using the identity API. 22 | 23 | In the Stein release, there are two supported token types: 24 | fernet and JWT. 25 | 26 | Neither fernet or JWT tokens require persistence. The keystone token database 27 | no longer suffers bloat as a side effect of authentication. Pruning of expired 28 | tokens happens automatically. Replication across multiple nodes is also no 29 | longer needed. As long as each keystone node shares the same repository, tokens 30 | can be created and validated instantly across all nodes. 31 | 32 | Fernet tokens 33 | ~~~~~~~~~~~~~ 34 | Fernet tokens are the supported token provider for Stein (default). Fernet 35 | is a secure messaging format explicitly designed for use in API tokens. They 36 | are lightweight (fall in range of 180 to 240 bytes) and reduce the operational 37 | overhead required to run a cloud. Authentication and authorization metadata is 38 | neatly bundled into a message packed payload, which is then encrypted and 39 | signed in as a fernet token. 40 | 41 | JWT tokens 42 | ~~~~~~~~~~~~~ 43 | JSON Web Signature (JWS) tokens were introduced in the Stein release. Compared 44 | to fernet, JWS offer a potential benefit to operators by limiting the number of 45 | hosts that need to share a symmetric encryption key. This helps prevent 46 | malicious actors who might already have a foothold in your deployment from 47 | spreading into additional nodes. 48 | 49 | Further details on the differences between these token providers can be found 50 | here https://docs.openstack.org/keystone/stein/admin/tokens-overview.html#token-providers 51 | -------------------------------------------------------------------------------- /security-guide/source/image-storage.rst: -------------------------------------------------------------------------------- 1 | ============= 2 | Image Storage 3 | ============= 4 | 5 | OpenStack Image Storage (glance) is a service where users can upload and 6 | discover data assets that are meant to be used with other services. This 7 | currently includes images and metadata definitions. 8 | 9 | Image services include discovering, registering, and retrieving virtual 10 | machine images. Glance has a RESTful API that allows querying of VM image 11 | metadata as well as retrieval of the actual image. 12 | 13 | For more details on the service see the `OpenStack Glance documentation 14 | `__. 15 | 16 | .. toctree:: 17 | :maxdepth: 2 18 | 19 | image-storage/checklist.rst 20 | 21 | .. note:: 22 | 23 | Whilst this chapter is currently sparse on specific 24 | guidance, it is expected that standard hardening practices 25 | will be followed. This section will be expanded with relevant 26 | information. 27 | -------------------------------------------------------------------------------- /security-guide/source/index.rst: -------------------------------------------------------------------------------- 1 | ======================== 2 | OpenStack Security Guide 3 | ======================== 4 | 5 | Abstract 6 | ~~~~~~~~ 7 | 8 | This book provides best practices and conceptual information about 9 | securing an OpenStack cloud. 10 | 11 | .. important:: 12 | 13 | This guide was last updated during the Train release, documenting 14 | the OpenStack Train, Stein, and Rocky releases. It may 15 | not apply to EOL releases (for example Newton). 16 | 17 | We advise that you read this at your own discretion when planning 18 | on implementing security measures for your OpenStack cloud. 19 | 20 | This guide is intended as advice only. 21 | 22 | The OpenStack Security team is based on voluntary contributions 23 | from the OpenStack community. You can contact the security community 24 | directly in the #openstack-security channel on OFTC IRC, or by 25 | sending mail to the openstack-discuss mailing list with the 26 | [security] prefix in the subject header. 27 | 28 | Contents 29 | ~~~~~~~~ 30 | 31 | .. toctree:: 32 | :maxdepth: 2 33 | 34 | common/conventions.rst 35 | introduction.rst 36 | documentation.rst 37 | management.rst 38 | secure-communication.rst 39 | api-endpoints.rst 40 | identity.rst 41 | dashboard.rst 42 | compute.rst 43 | block-storage.rst 44 | image-storage.rst 45 | shared-file-systems.rst 46 | networking.rst 47 | object-storage.rst 48 | secrets-management.rst 49 | messaging.rst 50 | data-processing.rst 51 | databases.rst 52 | tenant-data.rst 53 | instance-management.rst 54 | monitoring-logging.rst 55 | compliance.rst 56 | security-review.rst 57 | checklist.rst 58 | appendix.rst 59 | -------------------------------------------------------------------------------- /security-guide/source/instance-management.rst: -------------------------------------------------------------------------------- 1 | ============================ 2 | Instance security management 3 | ============================ 4 | 5 | One of the virtues of running instances in a virtualized environment 6 | is that it opens up new opportunities for security controls that are 7 | not typically available when deploying onto bare metal. There are 8 | several technologies that can be applied to the virtualization stack 9 | that bring improved information assurance for cloud tenants. 10 | 11 | Deployers or users of OpenStack with strong security requirements 12 | may want to consider deploying these technologies. Not all are 13 | applicable in every situation. In some cases, technologies may 14 | be ruled out for use in a cloud because of prescriptive business 15 | requirements. Similarly some technologies inspect instance data such 16 | as run state which may be undesirable to the users of the system. 17 | 18 | In this chapter we explore these technologies and describe the 19 | situations where they can be used to enhance security for instances 20 | or underlying instances. We also seek to highlight where privacy 21 | concerns may exist. These include data pass through, introspection, 22 | or providing a source of entropy. In this section we highlight the 23 | following additional security services: 24 | 25 | * Entropy to instances 26 | * Scheduling instances to nodes 27 | * Trusted images 28 | * Instance migrations 29 | * Monitoring, alerting, and reporting 30 | * Updates and patches 31 | * Firewalls and other host-based security controls 32 | 33 | .. toctree:: 34 | :maxdepth: 2 35 | 36 | instance-management/security-services-for-instances.rst 37 | .. case-studies/instance-management-case-studies.rst 38 | -------------------------------------------------------------------------------- /security-guide/source/introduction.rst: -------------------------------------------------------------------------------- 1 | ============ 2 | Introduction 3 | ============ 4 | 5 | The OpenStack Security Guide is the result of a five day sprint of 6 | collaborative work of many individuals. The purpose of this document is 7 | to provide the best practice guidelines for deploying a secure OpenStack 8 | cloud. It is designed to reflect the current state of 9 | security within the OpenStack community and provide frameworks for 10 | decision making where listing specific security controls are not 11 | feasible due to complexity or other environment specific details. 12 | 13 | .. toctree:: 14 | :maxdepth: 2 15 | 16 | introduction/acknowledgements.rst 17 | introduction/why-and-how-we-wrote-this-book.rst 18 | introduction/introduction-to-openstack.rst 19 | introduction/security-boundaries-and-threats.rst 20 | introduction/selecting-supporting-software.rst 21 | -------------------------------------------------------------------------------- /security-guide/source/introduction/acknowledgements.rst: -------------------------------------------------------------------------------- 1 | ================ 2 | Acknowledgements 3 | ================ 4 | 5 | The OpenStack Security Group would like to acknowledge contributions 6 | from the following organizations that were instrumental in making this 7 | book possible. The organizations are: 8 | 9 | .. image:: ../figures/book-sprint-all-logos.png 10 | -------------------------------------------------------------------------------- /security-guide/source/introduction/selecting-supporting-software.rst: -------------------------------------------------------------------------------- 1 | ============================= 2 | Selecting supporting software 3 | ============================= 4 | 5 | Your selection of supporting software, such as messaging and load balancing, 6 | can have serious security impacts on your cloud. 7 | It is important that you make the proper choices for your 8 | organization. This section provides some general guidelines for 9 | selecting supporting software. 10 | 11 | In order to select the best supporting software, consider these factors: 12 | 13 | * Team expertise 14 | * Product or project maturity 15 | * Common Criteria 16 | * Hardware concerns 17 | 18 | Team expertise 19 | ~~~~~~~~~~~~~~ 20 | 21 | The more familiar your team is with a given product, its configuration, and 22 | its eccentricities, the fewer configuration mistakes are made. Additionally, 23 | having staff expertise spread across an organization increases availability of 24 | your systems, allows segregation of duties, and mitigates problems in the event 25 | that a team member is unavailable. 26 | 27 | Product or project maturity 28 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29 | 30 | The maturity of a given product or project is critical to your security 31 | posture. Product maturity has a number of effects after you deploy your 32 | cloud: 33 | 34 | * Availability of expertise 35 | * Active developer and user communities 36 | * Timeliness and availability of updates 37 | * Incidence response 38 | 39 | Common Criteria 40 | ~~~~~~~~~~~~~~~ 41 | 42 | `Common Criteria `_ is an 43 | internationally standardized software evaluation process, used by governments 44 | and commercial companies to validate that software technologies perform as 45 | advertised. 46 | 47 | Hardware concerns 48 | ~~~~~~~~~~~~~~~~~ 49 | 50 | Consider the supportability of the hardware on which the software will run. 51 | Additionally, consider the additional features available in the hardware and 52 | how those features are supported by the software you choose. 53 | -------------------------------------------------------------------------------- /security-guide/source/management.rst: -------------------------------------------------------------------------------- 1 | ========== 2 | Management 3 | ========== 4 | 5 | A cloud deployment is a living system. Machines age and fail, software 6 | becomes outdated, vulnerabilities are discovered. When errors or 7 | omissions are made in configuration, or when software fixes must be 8 | applied, these changes must be made in a secure, but convenient, 9 | fashion. These changes are typically solved through configuration 10 | management. 11 | 12 | It is important to protect the cloud deployment from being 13 | configured or manipulated by malicious entities. With many systems in a 14 | cloud employing compute and networking virtualization, there are 15 | distinct challenges applicable to OpenStack which must be addressed 16 | through integrity lifecycle management. 17 | 18 | Administrators must perform command and control over the cloud 19 | for various operational functions. It is important these command and 20 | control facilities are understood and secured. 21 | 22 | .. toctree:: 23 | :maxdepth: 2 24 | 25 | management/continuous-systems-management.rst 26 | management/integrity-life-cycle.rst 27 | management/management-interfaces.rst 28 | .. case-studies/management-case-studies.rst 29 | -------------------------------------------------------------------------------- /security-guide/source/messaging.rst: -------------------------------------------------------------------------------- 1 | =============== 2 | Message queuing 3 | =============== 4 | 5 | Message queuing services facilitate inter-process communication in 6 | OpenStack. OpenStack supports these message queuing service back ends: 7 | 8 | - RabbitMQ 9 | 10 | - Qpid 11 | 12 | - ZeroMQ or 0MQ 13 | 14 | Both RabbitMQ and Qpid are Advanced Message Queuing Protocol (AMQP) 15 | frameworks, which provide message queues for peer-to-peer communication. 16 | Queue implementations are typically deployed as a centralized or 17 | decentralized pool of queue servers. ZeroMQ provides direct peer-to-peer 18 | communication through TCP sockets. 19 | 20 | Message queues effectively facilitate command and control functions 21 | across OpenStack deployments. Once access to the queue is permitted, no 22 | further authorization checks are performed. Services accessible through 23 | the queue do validate the contexts and tokens within the actual message 24 | payload. However, you must note the expiration date of the token because 25 | tokens are potentially re-playable and can authorize other services in 26 | the infrastructure. 27 | 28 | OpenStack does not support message-level confidence, such as message 29 | signing. Consequently, you must secure and authenticate the message 30 | transport itself. For high-availability (HA) configurations, you must 31 | perform queue-to-queue authentication and encryption. 32 | 33 | With ZeroMQ messaging, IPC sockets are used on individual machines. 34 | Because these sockets are vulnerable to attack, ensure that the cloud 35 | operator has secured them. 36 | 37 | .. toctree:: 38 | :maxdepth: 2 39 | 40 | messaging/security.rst 41 | .. case-studies/messaging-case-studies.rst 42 | -------------------------------------------------------------------------------- /security-guide/source/monitoring-logging.rst: -------------------------------------------------------------------------------- 1 | .. _monitoring-and-logging: 2 | 3 | ====================== 4 | Monitoring and logging 5 | ====================== 6 | 7 | Within a cloud environment there is a mixture of hardware, 8 | operating systems, virtual machine managers, OpenStack services, cloud-user 9 | activity (such as creating instances and attaching storage), networking, 10 | and end-users using the applications running on the various instances. 11 | 12 | The basics of logging: configuration, setting log level, location of the log 13 | files, and how to use and customize logs, as well as how to do centralized 14 | collections of logs is well covered in the `OpenStack Operations Guide 15 | `_. 16 | 17 | .. toctree:: 18 | :maxdepth: 2 19 | 20 | monitoring-logging/forensics-and-incident-response.rst 21 | .. case-studies/monitoring-logging-case-studies.rst 22 | -------------------------------------------------------------------------------- /security-guide/source/networking.rst: -------------------------------------------------------------------------------- 1 | ========== 2 | Networking 3 | ========== 4 | 5 | The OpenStack Networking service (neutron) enables the end-user or tenant to 6 | define, utilize, and consume networking resources. OpenStack Networking 7 | provides a tenant-facing API for defining network connectivity and IP 8 | addressing for instances in the cloud, in addition to orchestrating the 9 | network configuration. With the transition to an API-centric networking 10 | service, cloud architects and administrators should take into consideration 11 | best practices to secure physical and virtual network infrastructure and 12 | services. 13 | 14 | OpenStack Networking was designed with a plug-in architecture that provides 15 | extensibility of the API through open source community or third-party services. 16 | As you evaluate your architectural design requirements, it is important to 17 | determine what features are available in OpenStack Networking core services, 18 | any additional services that are provided by third-party products, and what 19 | supplemental services are required to be implemented in the physical 20 | infrastructure. 21 | 22 | This section is a high-level overview of what processes and best practices 23 | should be considered when implementing OpenStack Networking. 24 | 25 | .. toctree:: 26 | :maxdepth: 2 27 | 28 | networking/architecture.rst 29 | networking/services.rst 30 | networking/securing-services.rst 31 | networking/services-security-best-practices.rst 32 | networking/checklist.rst 33 | .. case-studies/networking-case-studies.rst 34 | -------------------------------------------------------------------------------- /security-guide/source/networking/securing-services.rst: -------------------------------------------------------------------------------- 1 | =========================================== 2 | Networking services security best practices 3 | =========================================== 4 | 5 | To secure OpenStack Networking, you must understand how the workflow 6 | process for tenant instance creation needs to be mapped to security 7 | domains. 8 | 9 | There are four main services that interact with OpenStack Networking. In 10 | a typical OpenStack deployment these services map to the following 11 | security domains: 12 | 13 | - OpenStack dashboard: Public and management 14 | 15 | - OpenStack Identity: Management 16 | 17 | - OpenStack compute node: Management and guest 18 | 19 | - OpenStack network node: Management, guest, and possibly public 20 | depending upon neutron-plugin in use. 21 | 22 | - SDN services node: Management, guest and possibly public depending 23 | upon product used. 24 | 25 | .. image:: ../figures/1aa-logical-neutron-flow.png 26 | :width: 100% 27 | 28 | To isolate sensitive data communication between the OpenStack Networking 29 | services and other OpenStack core services, configure these 30 | communication channels to only allow communication over an isolated 31 | management network. 32 | 33 | OpenStack Networking service configuration 34 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 35 | 36 | Restrict bind address of the API server: neutron-server 37 | ------------------------------------------------------- 38 | 39 | To restrict the interface or IP address on which the OpenStack 40 | Networking API service binds a network socket for incoming client 41 | connections, specify the bind\_host and bind\_port in the neutron.conf 42 | file as shown: 43 | 44 | .. code:: ini 45 | 46 | # Address to bind the API server 47 | bind_host = IP ADDRESS OF SERVER 48 | 49 | # Port the bind the API server to 50 | bind_port = 9696 51 | 52 | Restrict DB and RPC communication of the OpenStack Networking services 53 | ---------------------------------------------------------------------- 54 | 55 | Various components of the OpenStack Networking services use either the 56 | messaging queue or database connections to communicate with other 57 | components in OpenStack Networking. 58 | 59 | It is recommended that you follow the guidelines provided in 60 | :ref:`database-authentication-and-access-control` for all components 61 | which require direct DB connections. 62 | 63 | It is recommended that you follow the guidelines provided in 64 | :ref:`queue-authentication-and-access-control` for all components which 65 | require RPC communication. 66 | -------------------------------------------------------------------------------- /security-guide/source/secrets-management.rst: -------------------------------------------------------------------------------- 1 | .. _secrets-management: 2 | 3 | ================== 4 | Secrets Management 5 | ================== 6 | 7 | Operators protect sensitive information in cloud deployments by using various 8 | applications of cryptography. For example, encrypting data at rest or signing 9 | an image to prove that it has not been tampered with. In all cases, these 10 | cryptographic capabilities require some sort of *key material* in order to 11 | operate. 12 | 13 | Secrets Management describes a group of technologies that are designed to 14 | protect key materials within a software system. Traditionally, key management 15 | involves deployment of `Hardware Security Modules (HSM) `_. 16 | These devices have been physically hardened against tampering. 17 | 18 | As technology has advanced the number of secret things that need to be 19 | protected has increased beyond key materials to include certificate pairs, API 20 | keys, system passwords, signing keys and so on. This increase has created a 21 | need for a more scalable approach to key management, and resulted in the 22 | creation of a number of software services that provide scalable dynamic 23 | key management. This chapter describes the services that exist today 24 | and focus on those that are able to be integrated into OpenStack clouds. 25 | 26 | .. toctree:: 27 | :maxdepth: 2 28 | 29 | secrets-management/summary-of-technologies.rst 30 | secrets-management/related-projects.rst 31 | secrets-management/secrets-management-use-cases.rst 32 | secrets-management/barbican.rst 33 | secrets-management/castellan.rst 34 | secrets-management/faq.rst 35 | secrets-management/checklist.rst 36 | -------------------------------------------------------------------------------- /security-guide/source/secrets-management/castellan.rst: -------------------------------------------------------------------------------- 1 | ========= 2 | Castellan 3 | ========= 4 | 5 | Overview 6 | -------- 7 | 8 | Castellan is a generic Key Manager interface developed by the Barbican team. It 9 | enables projects to use a configurable key manager that can be deployment 10 | specific. 11 | -------------------------------------------------------------------------------- /security-guide/source/secrets-management/faq.rst: -------------------------------------------------------------------------------- 1 | ========================== 2 | Frequently Asked Questions 3 | ========================== 4 | 5 | 1. What is the recommended way to securely store secrets in OpenStack? 6 | 7 | The recommended way to securely store and manage secrets in OpenStack 8 | is to use Barbican. 9 | 10 | 2. Why should I use Barbican? 11 | 12 | Barbican is an OpenStack service that is multi-tenant aware and that 13 | uses Keystone tokens for authentication. This means that access to secrets is 14 | controlled via OpenStack policies for tenants and RBAC roles. 15 | 16 | Barbican has multiple pluggable back-ends which can communicate with 17 | software and hardware based security modules using PKCS#11 or KMIP. 18 | 19 | 3. What if I don't want to use Barbican? 20 | 21 | In an Openstack context, there are two types of secrets that need to 22 | be managed - those that require a keystone token for access, and those that do 23 | not. 24 | 25 | An example of those secrets that require keystone authentication are 26 | passwords and keys owned by specific projects. These include, for instance, 27 | encryption keys for a project's encrypted cinder volumes or signing keys for a 28 | project's glance images. 29 | 30 | Examples of secrets that does not require a keystone token to access 31 | are passwords for service users in service configuration files, or 32 | encryption keys that do not belong to any particular project. 33 | 34 | Secrets that require a keystone token should be stored using Barbican. 35 | 36 | Secrets that do not require keystone authentication can be stored in any secret 37 | store that implements the simple key storage API that is exposed through 38 | Castellan. This also includes Barbican. 39 | 40 | 4. How can I use Vault, Keywhiz, Custodia etc ...? 41 | 42 | The key manager of your choice can be used with Openstack if Castellan 43 | plugin has been written for that key manager. Once that plugin 44 | has been written, it is relatively trivial to use the plugin either directly or 45 | behind Barbican. 46 | 47 | Currently, Vault and Custodia plugins are being developed for the Queens cycle. 48 | -------------------------------------------------------------------------------- /security-guide/source/secrets-management/related-projects.rst: -------------------------------------------------------------------------------- 1 | ========================== 2 | Related Openstack Projects 3 | ========================== 4 | 5 | `Castellan `_ is a library that 6 | provides a simple common interface to store, generate and retrieve secrets. It 7 | is used by most Openstack services for secret management. As a library, 8 | Castellan does not provide a secret store in and of itself. Rather, a back-end 9 | implementation is required to be deployed. 10 | 11 | Note that Castellan does not provide any authentication. It simply passes 12 | through the authentication credentials (a Keystone token, for example) to the 13 | back-end. 14 | 15 | `Barbican `_ is an OpenStack service that provides a back-end for Castellan. 16 | Barbican expects and authenticates a keystone authentication token to identify 17 | the user and project accessing or storing a secret. It then applies policy to 18 | determine if access is permitted. It also provides a number of additional 19 | useful features to improve secret management including quotas, per-secret ACLs, 20 | tracking of secret consumers and grouping of secrets in secret containers. 21 | Octavia, for example, integrates directly with Barbican (instead of Castellan) 22 | to take advantage of some of these features. 23 | 24 | Barbican has a number of back-end plugins that can be used to securely store 25 | secrets in local databases or in HSMs. 26 | 27 | Currently, Barbican is the only available back-end for Castellan. There are, 28 | however, several back-ends that are being developed, including KMIP, Dogtag, 29 | Hashicorp Vault and Custodia. For those deployers who do not wish to deploy 30 | Barbican and have relatively simple key management needs, using one of these 31 | back-ends could be a viable alternative. What would be lacking though is 32 | multi-tenancy and tenant-policy enforcement when retrieving the secrets, as 33 | well as any of the extra features mentioned above. 34 | -------------------------------------------------------------------------------- /security-guide/source/secrets-management/summary-of-technologies.rst: -------------------------------------------------------------------------------- 1 | ================================ 2 | Summary of existing technologies 3 | ================================ 4 | 5 | Within OpenStack, there are two solutions recommended for secrets 6 | managment, those being `Barbican `_ and `Castellan `_. This chapter will 7 | outline different scenarios to help an operator make a choice on which 8 | key manager to use. 9 | 10 | A third non supported method is Fixed/Hardcoded keys. It is known that some 11 | OpenStack services have the option to specify keys in their configuration 12 | files. This is the least secure way to operate and we do not recommend 13 | this for any sort of production environment. 14 | 15 | Other solutions exist including KeyWhiz, Confidant, Conjur, EJSON, Knox 16 | and Red October, however it is outside the scope of this document to cover 17 | every Key Manager available. 18 | 19 | For storage of secrets, it's strongly recommended to a Hardware Security 20 | Modules (HSMs). HSMs can come in multiple forms. The traditional device is a 21 | rack mounted appliance such as the one `shown in the following blog post `_. 22 | -------------------------------------------------------------------------------- /security-guide/source/secure-communication.rst: -------------------------------------------------------------------------------- 1 | ==================== 2 | Secure communication 3 | ==================== 4 | 5 | Inter-device communication is a serious security concern. 6 | Between large project errors, such as Heartbleed, or more 7 | advanced attacks such as BEAST and CRIME, secure methods of 8 | communication over a network are becoming more important. It should 9 | be remembered, however that encryption should be applied as one part 10 | of a larger security strategy. The compromise of an endpoint means 11 | that an attacker no longer needs to break the encryption used, but 12 | is able to view and manipulate messages as they are processed by 13 | the system. 14 | 15 | This chapter will review several features around configuring TLS to 16 | secure both internal and external resources, and will call out 17 | specific categories of systems that should be given specific 18 | attention. 19 | 20 | .. toctree:: 21 | :maxdepth: 2 22 | 23 | secure-communication/introduction-to-ssl-and-tls.rst 24 | secure-communication/tls-proxies-and-http-services.rst 25 | secure-communication/secure-reference-architectures.rst 26 | .. case-studies/secure-communication-case-studies.rst 27 | -------------------------------------------------------------------------------- /security-guide/source/shared-file-systems.rst: -------------------------------------------------------------------------------- 1 | =================== 2 | Shared File Systems 3 | =================== 4 | 5 | The Shared File Systems service (manila) provides a set of services for 6 | management of shared file systems in a multi-tenant cloud environment. It is 7 | similar to how OpenStack provides block-based storage management through 8 | the OpenStack Block Storage service (cinder) project. With the Shared File 9 | Systems service, you can create a shared file system and manage its 10 | properties, such as visibility, accessibility and usage quotas. 11 | 12 | The Shared File Systems service works with various storage providers that use 13 | the following shared file system protocols: 14 | :term:`NFS `, 15 | :term:`CIFS `, :term:`GlusterFS`, and 16 | :term:`HDFS `. 17 | 18 | The Shared File Systems service serves the same purpose as Amazon Elastic File 19 | System (EFS). 20 | 21 | .. toctree:: 22 | :maxdepth: 2 23 | 24 | shared-file-systems/intro.rst 25 | shared-file-systems/network-and-security-models.rst 26 | shared-file-systems/security-services.rst 27 | shared-file-systems/share-acl.rst 28 | shared-file-systems/share-type-acl.rst 29 | shared-file-systems/policies.rst 30 | shared-file-systems/checklist.rst 31 | -------------------------------------------------------------------------------- /security-guide/source/shared-file-systems/policies.rst: -------------------------------------------------------------------------------- 1 | .. _shared_fs_policies: 2 | 3 | ======== 4 | Policies 5 | ======== 6 | Shared File Systems service has its own role-based access policies. They 7 | determine which user can access which objects in which way, and are defined in 8 | the service's ``policy.json`` file. 9 | 10 | .. tip:: 11 | 12 | The configuration file ``policy.json`` may be placed anywhere. 13 | The path ``/etc/manila/policy.json`` is expected by default. 14 | 15 | Whenever an API call to the Shared File Systems service is made, the policy 16 | engine uses the appropriate policy definitions to determine if the call can be 17 | accepted. 18 | 19 | A policy rule determines under which circumstances the API call is permitted. 20 | The ``/etc/manila/policy.json`` file has rules where action is always 21 | permitted, when the rule is an empty string: ``""``; the rules based on the 22 | user role or rules; rules with boolean expressions. Below is a snippet of the 23 | ``policy.json`` file for the Shared File Systems service. From one 24 | OpenStack release to another it can be changed. 25 | 26 | .. code-block:: javascript 27 | 28 | { 29 | "context_is_admin": "role:admin", 30 | "admin_or_owner": "is_admin:True or project_id:%(project_id)s", 31 | "default": "rule:admin_or_owner", 32 | "share_extension:quotas:show": "", 33 | "share_extension:quotas:update": "rule:admin_api", 34 | "share_extension:quotas:delete": "rule:admin_api", 35 | "share_extension:quota_classes": "", 36 | } 37 | 38 | Users must be assigned to groups and roles that you refer to in 39 | your policies. This is done automatically by the service when user 40 | management commands are used. 41 | 42 | .. note:: 43 | 44 | Any changes to ``/etc/manila/policy.json`` are effective immediately, 45 | which allows new policies to be implemented while the Shared File Systems 46 | service is running. Manual modification of the policy can have unexpected 47 | side effects and is not encouraged. For details, see 48 | `The policy.json file 49 | `_. 50 | -------------------------------------------------------------------------------- /security-guide/source/tenant-data.rst: -------------------------------------------------------------------------------- 1 | =================== 2 | Tenant data privacy 3 | =================== 4 | 5 | OpenStack is designed to support multitenancy and those tenants will 6 | most probably have different data requirements. As a cloud builder or operator, 7 | you must ensure your OpenStack environment addresses data privacy concerns 8 | and regulations. In this chapter we will 9 | address data residency and disposal as it pertains to OpenStack 10 | implementations. 11 | 12 | .. toctree:: 13 | :maxdepth: 2 14 | 15 | tenant-data/data-privacy-concerns.rst 16 | tenant-data/data-encryption.rst 17 | tenant-data/key-management.rst 18 | .. case-studies/tenant-data-case-studies.rst 19 | -------------------------------------------------------------------------------- /security-guide/source/tenant-data/key-management.rst: -------------------------------------------------------------------------------- 1 | ============== 2 | Key management 3 | ============== 4 | 5 | 6 | To address the often mentioned concern of tenant data privacy and limiting 7 | cloud provider liability, there is greater interest within the OpenStack 8 | community to make data encryption more ubiquitous. It is relatively easy for an 9 | end-user to encrypt their data prior to saving it to the cloud, and this is a 10 | viable path for tenant objects such as media files, database archives among 11 | others. In some instances, client-side encryption is utilized to encrypt data 12 | held by the virtualization technologies which requires client interaction, such 13 | as presenting keys, to decrypt data for future use. To seamlessly secure the 14 | data and have it accessible without burdening the client with having to manage 15 | their keys and interactively provide them calls for a key management service 16 | within OpenStack. Providing encryption and key management services as part of 17 | OpenStack eases data-at-rest security adoption and addresses customer concerns 18 | about privacy or misuse of data, while also limiting cloud provider liability. 19 | This can help reduce a provider's liability when handling tenant data during an 20 | incident investigation in multi-tenant public clouds. 21 | 22 | The volume encryption and ephemeral disk encryption features rely on a key 23 | management service (for example, barbican) for the creation and secure storage 24 | of keys. The key manager is pluggable to facilitate deployments that need a 25 | third-party Hardware Security Module (HSM) or the use of the Key Management 26 | Interchange Protocol (KMIP), which is supported by an open-source project 27 | called PyKMIP. 28 | 29 | Bibliography: 30 | ~~~~~~~~~~~~~ 31 | 32 | - OpenStack.org, Welcome to barbican's Developer Documentation!. 2014. 33 | `Barbican developer 34 | documentation `__ 35 | 36 | - oasis-open.org, OASIS Key Management Interoperability Protocol 37 | (KMIP). 2014. 38 | `KMIP `__ 39 | 40 | - `PyKMIP library `__ 41 | 42 | - Secrets Management :ref:`secrets-management` 43 | -------------------------------------------------------------------------------- /security-notes/OSSN-0001: -------------------------------------------------------------------------------- 1 | Selecting LXC as Nova Virtualization Driver can lead to data compromise 2 | --- 3 | 4 | ### Summary### 5 | LXC does not provide the same level of separation as hypervisors when chosen as 6 | the Nova 'virtualization driver'. Attempting to use LXC as a drop in 7 | replacement for a hypervisor can result in data exposure between tenants. 8 | 9 | ### Affected Services / Software ### 10 | Nova, LXC, Libvirt, 'Virtualization Driver' 11 | 12 | ### Discussion ### 13 | The Libvirt LXC functionality exposed by OpenStack is built on the kernel 14 | namespace & cgroup technologies. Until Linux 3.8, there has been no support for 15 | separate user namespaces in the kernel. As such, there has been no way to 16 | securely isolate containers from each other or the host environment using DAC 17 | (discretionary access control). For example, they can escape their resource 18 | constraints by modifying cgroups settings, or attack the host via various files 19 | in the proc and sysfs filesystems. The use of MAC (mandatory access control) 20 | technologies like SELinux or AppArmour can mitigate these problems, but it is 21 | not practical to write MAC policies that would allow running full OS installs 22 | in LXC under OpenStack. 23 | 24 | Although initial user namespace support was merged in Linux 3.8, it is not yet 25 | complete, or mature enough to be considered secure. Work is ongoing to finish 26 | the kernel namespace support and enhance libvirt LXC to take advantage of it. 27 | 28 | ### Recommended Actions ### 29 | The OSSG advises that anyone deploying Nova in environments that require any 30 | level of separation use a hypervisor such as Xen, KVM, VMware or Hyper-V. 31 | 32 | LXC security pivots on a system known as DAC (discretionary access control) 33 | which is not currently capable of providing strong isolation of guests. Work is 34 | underway to improve DAC but it’s not ready for production use at this time. 35 | 36 | The OSSG recommends against using LXC for enforcing secure separation of 37 | guests. Even with appropriate AppArmour policies applied. 38 | 39 | ### Contacts / References ### 40 | Author: Robert Clark, HP 41 | Nova : https://docs.openstack.org/nova/latest/ 42 | LXC : https://linuxcontainers.org/ 43 | Libvirt : https://libvirt.org/ 44 | KVM : https://www.linux-kvm.org/page/Main_Page 45 | Xen: https://www.xenproject.org/developers/teams/hypervisor.html 46 | LXC DAC : https://wiki.ubuntu.com/UserNamespace 47 | LXC LibVirt Discussion : https://www.berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/ 48 | -------------------------------------------------------------------------------- /security-notes/OSSN-0002: -------------------------------------------------------------------------------- 1 | HTTP POST limiting advised to avoid Essex/Folsom Keystone DoS 2 | --- 3 | 4 | ### Summary ### 5 | Concurrent Keystone POST requests with large body messages are held in memory 6 | without filtering or rate limiting, this can lead to resource exhaustion on the 7 | Keystone server. 8 | 9 | ### Affected Services / Software ### 10 | Keystone, Databases 11 | 12 | ### Discussion ### 13 | Keystone stores POST messages in memory before validation, concurrent 14 | submission of multiple large POST messages can cause the Keystone process to be 15 | killed due to memory exhaustion, resulting in a remote Denial of Service. 16 | 17 | In many cases Keystone will be deployed behind a load-balancer or proxy that 18 | can rate limit POST messages inbound to Keystone. Grizzly is protected 19 | against that through the sizelimit middleware. 20 | 21 | ### Recommended Actions ### 22 | If you are in a situation where Keystone is directly exposed to incoming POST 23 | messages and not protected by the sizelimit middleware there are a number of 24 | load-balancing/proxy options, we suggest you consider one of the following: 25 | 26 | Nginx: Open-source, high-performance HTTP server and reverse proxy. 27 | Nginx Config: http://wiki.nginx.org/HttpCoreModule#client_max_body_size 28 | 29 | Apache: HTTP Server Project 30 | Apache Config: http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody 31 | 32 | ### Contacts / References ### 33 | Author: Robert Clark, HP 34 | This OSSN Bug: https://bugs.launchpad.net/ossn/+bug/1155566 35 | Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1098177 36 | OpenStack Security ML : openstack-security@lists.openstack.org 37 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 38 | -------------------------------------------------------------------------------- /security-notes/OSSN-0003: -------------------------------------------------------------------------------- 1 | Keystone configuration should not be world readable 2 | --- 3 | 4 | ### Summary ### 5 | In some deployments keystone.conf which contains confidential information, is 6 | set to world readable. 7 | 8 | ### Affected Services / Software ### 9 | Keystone, DevStack, Deployment 10 | 11 | ### Discussion ### 12 | It is important that deployers of OpenStack ensure that keystone.conf is not 13 | world readable. In some deployments the keystone configuration file is readable 14 | by all users (and processes) on the installation system. This file should be 15 | set with the most restrictive permissions that allow the system to continue 16 | proper operations. 17 | 18 | In particular, the password configuration of the LDAP section and the 19 | admin_token contain secret information: 20 | 21 | ---- being example config snippet ---- 22 | [ldap] 23 | url = ldap://localhost 24 | user = dc=Manager,dc=example,dc=com 25 | password = None <- should be secret 26 | suffix = cn=example,cn=com 27 | use_dumb_member = False 28 | allow_subtree_delete = False 29 | dumb_member = cn=dumb,dc=example,dc=com 30 | 31 | [DEFAULT] 32 | admin_token = passw0rd <- should be secret 33 | ---- end example config snippet ---- 34 | 35 | ### Recommended Actions ### 36 | Ensure that in your deployment keystone.conf uses the most restrictive 37 | permissions that allow the system to continue proper operations. 38 | 39 | ### Contacts / References ### 40 | Author: Robert Clark, HP 41 | This OSSN : https://bugs.launchpad.net/ossn/+bug/1168252 42 | Original LaunchPad Bug : https://bugs.launchpad.net/devstack/+bug/1168252 43 | OpenStack Security ML : openstack-security@lists.openstack.org 44 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 45 | CVE: CVE-2013-1977 46 | -------------------------------------------------------------------------------- /security-notes/OSSN-0005: -------------------------------------------------------------------------------- 1 | Glance allows sharing of images between projects without consumer project 2 | approval 3 | --- 4 | 5 | ### Summary ### 6 | Glance allows images to be shared between projects. In certain API versions, 7 | images can be shared without the consumer project's approval. This allows 8 | potentially malicious images to show up in a project's image list. 9 | 10 | ### Affected Services / Software ### 11 | Glance, Image Service, Diablo, Essex, Folsom, Grizzly, Havana 12 | 13 | ### Discussion ### 14 | Since the OpenStack Diablo release, Glance allows images to be shared between 15 | projects. To share an image, the producer of the image adds the consumer 16 | project as a member of the image. When using the Image Service API v1, the 17 | image producer is able to share an image with a consumer project without their 18 | approval. This results in the shared image showing up in the image list for the 19 | consumer project. This can mislead users with roles in the consumer project 20 | into running a potentially malicious image. 21 | 22 | The Image Service API v2.0 does not allow image sharing between projects, so a 23 | project is not susceptible to running unauthorized images shared by other 24 | projects. The Image Service API v2.1 allows image sharing using a two-step 25 | process. An image producer must add a consumer as a member of the image, and 26 | the consumer must accept the shared image before it shows up in their image 27 | list. This additional approval process allows a consumer to control what images 28 | show up in their image list, thus preventing potentially malicious images being 29 | used without the consumers knowledge. 30 | 31 | ### Recommended Actions ### 32 | In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image 33 | sharing using the Image Service API v1. There is no way to require approval of 34 | a shared image by consumer projects. Users should be cautioned to be careful 35 | when using images from their image list, as they may be using an image that was 36 | shared with them without their knowledge. 37 | 38 | In the OpenStack Grizzly and Havana releases, Glance supports the Image Service 39 | API v2.1 or later. Support is still provided for Image Service API v1, which 40 | allows image sharing between projects without consumer project approval. It is 41 | recommended to disable v1 of the Image Service API if possible. This can be 42 | done by setting the following directive in the glance-api.conf configuration 43 | file: 44 | 45 | ---- begin example glance-api.conf snippet ---- 46 | enable_v1_api = False 47 | ---- end example glance-api.conf snippet ---- 48 | 49 | ### Contacts / References ### 50 | Author: Nathan Kinder, Red Hat 51 | This OSSN : https://bugs.launchpad.net/ossn/+bug/1226078 52 | Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1226078 53 | OpenStack Security ML : openstack-security@lists.openstack.org 54 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 55 | CVE: CVE-2013-4354 56 | -------------------------------------------------------------------------------- /security-notes/OSSN-0008: -------------------------------------------------------------------------------- 1 | DoS style attack on noVNC server can lead to service interruption or disruption 2 | --- 3 | 4 | ### Summary ### 5 | There is currently no limit to the number of noVNC or SPICE console 6 | sessions that can be established by a single user. The console host has 7 | limited resources and an attacker launching many sessions may be able to 8 | exhaust the available resources, resulting in a Denial of Service (DoS) 9 | condition. 10 | 11 | ### Affected Services / Software ### 12 | Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana 13 | 14 | ### Discussion ### 15 | Currently with a single user token, no restrictions are enforced on the 16 | number or frequency of noVNC or SPICE console sessions that may be 17 | established. While a user can only access their own virtual machine 18 | instances, resources can be exhausted on the console proxy host by 19 | creating an excessive number of simultaneous console sessions. This can 20 | result in timeouts for subsequent connection requests to instances using 21 | the same console proxy. Not only would this prevent the user from 22 | accessing their own instances, but other legitimate users would also be 23 | deprived of console access. Further, other services running on the 24 | noVNC proxy and Compute hosts may degrade in responsiveness. 25 | 26 | By taking advantage of this lack of restrictions around noVNC or SPICE 27 | console connections, a single user could cause the console proxy 28 | endpoint to become unresponsive, resulting in a Denial Of Service (DoS) 29 | style attack. It should be noted that there is no amplification effect. 30 | 31 | ### Recommended Actions ### 32 | For current stable OpenStack releases (Grizzly, Havana), users need to 33 | workaround this vulnerability by using rate-limiting proxies to cover 34 | access to the noVNC proxy service. Rate-limiting is a common mechanism 35 | to prevent DoS and Brute-Force attacks. 36 | 37 | For example, if you are using a proxy such as Repose, enable the rate 38 | limiting feature by following these steps: 39 | 40 | https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter 41 | 42 | Future OpenStack releases are looking to add the ability to restrict 43 | noVNC and SPICE console connections. 44 | 45 | ### Contacts / References ### 46 | Author: Nathan Kinder, Red Hat 47 | Author: Sriram Subramanian, CloudDon 48 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 49 | Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 50 | OpenStack Security ML : openstack-security@lists.openstack.org 51 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 52 | -------------------------------------------------------------------------------- /security-notes/OSSN-0009: -------------------------------------------------------------------------------- 1 | Potential token revocation abuse via group membership 2 | --- 3 | 4 | ### Summary ### 5 | Deletion of groups in Keystone causes token revocation for group 6 | members. If group capabilities are delegated to users, they can abuse 7 | those capabilities to maliciously revoke tokens for other users. 8 | 9 | ### Affected Services / Software ### 10 | Keystone, Grizzly, Havana, Icehouse 11 | 12 | ### Discussion ### 13 | If a group is deleted from Keystone, all tokens for all users that are 14 | members of that group are revoked. By adding users to a group without 15 | those users' knowledge and then deleting that group, a group admin can 16 | revoke all of the users' tokens. While the default policy file gives 17 | the group admin role to global admin, an alternative policy could 18 | delegate the "create_group", "add_user_to_group", and "delete_group" 19 | capabilities to a set of users. In such a system, those users will also 20 | get a token revocation capability. Only setups using a custom policy 21 | file in Keystone are affected. 22 | 23 | ### Recommended Actions ### 24 | Keystone's default policy.json file uses the "admin_required" rule for 25 | the "create_group", "delete_group", and "add_user_to_group" 26 | capabilities. It is recommended that you use this default configuration 27 | if possible. Here is an example snippet of a properly configured 28 | policy.json file: 29 | 30 | ---- begin example policy.json snippet ---- 31 | "identity:create_group": "rule:admin_required", 32 | "identity:delete_group": "rule:admin_required", 33 | "identity:add_user_to_group": "rule:admin_required", 34 | ---- end example policy.json snippet ---- 35 | 36 | If you need to delegate the above capabilities to non-admin users, you 37 | need to take into account that those users will be able to revoke 38 | tokens for other users by performing group deletion operations. You 39 | should take caution with who you delegate these capabilities to. 40 | 41 | ### Contacts / References ### 42 | Author: Nathan Kinder, Red Hat 43 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0009 44 | Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1268751 45 | OpenStack Security ML : openstack-security@lists.openstack.org 46 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 47 | -------------------------------------------------------------------------------- /security-notes/OSSN-0010: -------------------------------------------------------------------------------- 1 | Sample Keystone v3 policy exposes privilege escalation vulnerability 2 | --- 3 | 4 | ### Summary ### 5 | The policy.v3cloudsample.json sample Keystone policy file combined with 6 | the underlying mutability of the domain ID for user, group, and project 7 | entities exposed a privilege escalation vulnerability. When this 8 | sample policy is applied a domain administrator can elevate their 9 | privileges to become a cloud administrator. 10 | 11 | ### Affected Services / Software ### 12 | Keystone, Havana 13 | 14 | ### Discussion ### 15 | Changes to the Keystone v3 sample policy during the Havana release cycle 16 | set an excessively broad domain administrator scope that allowed 17 | creation of roles ("create_grant") on other domains (among other 18 | actions). There was no check that the domain administrator had 19 | authority to the domain they were attempting to grant a role on. 20 | 21 | Combining the mutable state of the domain ID for user, group, and 22 | project entities with the sample v3 policy resulted in a privilege 23 | escalation vulnerability. A domain administrator could execute a series 24 | of steps to escalate their access to that of a cloud administrator. 25 | 26 | ### Recommended Actions ### 27 | Review the following updated sample v3 policy file from the OpenStack 28 | Icehouse release: 29 | 30 | https://git.openstack.org/cgit/openstack/keystone/commit/?id=0496466821c1ff6e7d4209233b6c671f88aadc50 31 | 32 | You should ensure that your Keystone deployment appropriately reflects 33 | that update. Domain administrators should generally only be permitted 34 | to perform actions against the domain for which they are an 35 | administrator. 36 | 37 | Optionally, review the recent addition of support for immutable domain 38 | IDs and consider it for applicability to your Keystone deployment: 39 | 40 | https://git.openstack.org/cgit/openstack/keystone/commit/?id=a2fa6a6f01a4884edf369cafa39946636af5cf1a 41 | 42 | ### Contacts / References ### 43 | Author: Jamie Finnigan, HP 44 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0010 45 | Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1287219 46 | OpenStack Security ML : openstack-security@lists.openstack.org 47 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 48 | -------------------------------------------------------------------------------- /security-notes/OSSN-0015: -------------------------------------------------------------------------------- 1 | Glance allows non-admin users to create public images 2 | --- 3 | 4 | ### Summary ### 5 | The default policy settings in Glance allow any user to upload an image 6 | that is publicly available to all users. This can allow a malicious user 7 | to upload a vulnerable image that other users may use, unknowingly 8 | exposing themselves to attack. 9 | 10 | ### Affected Services / Software ### 11 | Glance, Folsom, Grizzly, Havana, Icehouse 12 | 13 | ### Discussion ### 14 | When uploading an image to Glance, the user performing the upload is 15 | able to mark the image as public. This allows all other users to see and 16 | use the image when they create new instances. The ability to share 17 | images with all users within an OpenStack deployment is very useful, but 18 | it can potentially be abused for malicious purposes. For example, an 19 | image can be uploaded that contains a backdoor that allows the attacker 20 | to have unauthorized access to instances that are created from that 21 | image. 22 | 23 | Glance does allow for the ability to publicize images to be controlled 24 | by policy. However, the default policy setting allows all users to 25 | publicize images. 26 | 27 | ### Recommended Actions ### 28 | It is recommended that the ability to publicize images in Glance be 29 | restricted to trusted users, such as users with the "admin" role. This 30 | can be done by modifying the "publicize_image" capability in Glance's 31 | policy.json file. Here is an example of restricting this capability to 32 | users with the "admin" role: 33 | 34 | ---- begin example policy.json snippet ---- 35 | "publicize_image": "role:admin", 36 | ---- end example policy.json snippet ---- 37 | 38 | The default policy setting in Glance is planned to be changed to 39 | restrict the ability to publicize images to users with the "admin" role 40 | in the Juno release of OpenStack. 41 | 42 | ### Contacts / References ### 43 | Author: Nathan Kinder, Red Hat 44 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0015 45 | Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1313746 46 | OpenStack Security ML : openstack-security@lists.openstack.org 47 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 48 | -------------------------------------------------------------------------------- /security-notes/OSSN-0016: -------------------------------------------------------------------------------- 1 | Cinder wipe fails in an insecure manner on Grizzly 2 | --- 3 | 4 | ### Summary ### 5 | A configuration error can prevent the secure erase of volumes in Cinder on 6 | Grizzly, potentially allowing a user to recover another user’s data. 7 | 8 | ### Affected Services / Software ### 9 | Cinder, Grizzly 10 | 11 | ### Discussion ### 12 | In Cinder on Grizzly, a configurable method to perform a secure erase of 13 | volumes was added. In the event of a misconfiguration no secure erase will 14 | be performed. 15 | 16 | The default code path in Cinder’s clear_volume() method, which is taken 17 | in the event of a configuration error, results in no wiping of the volume - 18 | even in the event that the user had flagged the volume for wiping. 19 | 20 | This is the same behaviour as if the volume_clear = ‘none’ option was 21 | selected. This could let an attacker recover data from a volume that was 22 | intended to be securely erased. Examples of possible incorrect 23 | configuration options include values that would appear to result in a 24 | secure erase, for example "volume_clear = true" or "volume_clear = 25 | yes". 26 | 27 | In the event of a misconfiguration resulting in this issue, the message 28 | "Error unrecognized volume_clear option" should be present in log 29 | files. 30 | 31 | ### Recommended Actions ### 32 | - Create and clear a volume (cinder create --display_name erasetest 10; 33 | cinder delete erasetest) 34 | - Review log files for the above error message (grep "Error unrecognized 35 | volume_clear option" ) 36 | - Review configuration files to ensure that the valid options ‘zero’ or 37 | ‘shred’ are specified. 38 | 39 | 40 | ### Contacts / References ### 41 | Author: Doug Chivers, HP 42 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0016 43 | Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1322766 44 | OpenStack Security ML : openstack-security@lists.openstack.org 45 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 46 | -------------------------------------------------------------------------------- /security-notes/OSSN-0020: -------------------------------------------------------------------------------- 1 | Disassociating floating IPs does not terminate NAT connections with 2 | Neutron L3 agent 3 | --- 4 | 5 | ### Summary ### 6 | Every virtual instance is automatically assigned a private IP address. 7 | You may optionally assign public IP addresses to instances. OpenStack 8 | uses the term "floating IP" to refer to an IP address (typically 9 | public) that can be dynamically added to a running virtual instance. 10 | The Neutron L3 agent uses Network Address Translation (NAT) to assign 11 | floating IPs to virtual instances. Floating IPs can be dynamically 12 | released from a running virtual instance but any active connections are 13 | not terminated with this release as expected when using the Neutron L3 14 | agent. 15 | 16 | ### Affected Services / Software ### 17 | Neutron, Icehouse, Havana, Grizzly, Folsom 18 | 19 | ### Discussion ### 20 | When creating a virtual instance, a floating IP address is not 21 | allocated by default. After a virtual instance is created, a user can 22 | explicitly associate a floating IP address to that instance. Users can 23 | create connections to the virtual instance using this floating IP 24 | address. Also, this floating IP address can be disassociated from any 25 | running instance without shutting that instance down. 26 | 27 | If a user initiates a connection using the floating IP address, this 28 | connection remains alive and accessible even after the floating IP 29 | address is released from that instance. This potentially violates 30 | restrictive policies which are only being applied to new connections. 31 | These policies are ignored for pre-existing connections and the virtual 32 | instance remains accessible from the public network. 33 | 34 | This issue is only known to affect Neutron when using the L3 agent. 35 | Nova networking is not affected. 36 | 37 | ### Recommended Actions ### 38 | There is unfortunately no easy way to detect which connections were 39 | made over a floating IP address from a virtual instance, as the NAT is 40 | performed at the Neutron router. The only safe way of terminating all 41 | connections made over a floating IP address is to terminate the virtual 42 | instance itself. 43 | 44 | The following recommendations should be followed when using the Neutron 45 | L3 agent: 46 | 47 | - Only attach a floating IP address to a virtual instance when that 48 | instance should be accessible from networks outside the cloud. 49 | - Terminate or stop the instance along with disassociating the floating 50 | IP address to ensure that all connections are closed. 51 | 52 | The Neutron development team plans to address this issue in a future 53 | version of Neutron. 54 | 55 | ### Contacts / References ### 56 | Author Priti Desai, Symantec 57 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0020 58 | Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1334926 59 | OpenStack Security ML : openstack-security@lists.openstack.org 60 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 61 | -------------------------------------------------------------------------------- /security-notes/OSSN-0022: -------------------------------------------------------------------------------- 1 | Nova Networking does not enforce security group rules following a soft 2 | reboot of an instance 3 | --- 4 | 5 | ### Summary ### 6 | In deployments using Nova Networking, security group rules associated 7 | with an instance may not be enforced after a soft reboot. Nova is 8 | designed to apply the configured security group rules to an instance 9 | when certain operations are performed, such as a normal boot operation. 10 | If an operation has been performed that results in the clearing of 11 | security group rules, such as restarting the nova compute service, then 12 | performing a soft reboot of that instance will cause it to be 13 | started without security group rules being applied. 14 | 15 | Deployments using Neutron are not impacted. 16 | 17 | ### Affected Services / Software ### 18 | Nova, Havana, Grizzly 19 | 20 | ### Discussion ### 21 | In Nova deployments using Nova Networking, security groups are 22 | implemented using iptables, which is used to configure and control 23 | network traffic into Nova instances. When an instance is first booted 24 | using the normal boot method (nova boot ), the security 25 | group rules are applied to that instance. 26 | 27 | When an instance is rebooted using the soft reboot method (nova reboot 28 | ), the security group rules are not reapplied since they 29 | should have been already applied when the instance was initially 30 | booted. If the security group rules have not been applied following an 31 | event that resulted in their clearing, such as restarting the compute 32 | service, the instance will be brought up without security group 33 | enforcement. This situation is most likely to arise in cases where the 34 | Nova compute service has been terminated or restarted, which removes 35 | all iptables rules. If a stopped instance is then started by using a 36 | soft reboot, it will not have any security group rules applied. A hard 37 | reboot (nova reboot --hard ) reapplies the security group 38 | rules, so it is not susceptible to this issue. 39 | 40 | Depending on the deployment architecture, this could breach security 41 | assumptions and leave an instance vulnerable to network based attacks. 42 | 43 | This issue only affects the Havana and Grizzly releases. The Icehouse 44 | release does not allow a stopped instance to be started using a soft 45 | reboot, therefore this issue does not affect the Icehouse release. 46 | 47 | ### Recommended Actions ### 48 | Do not to use the soft reboot method to start instances from the 49 | stopped state. If instances are in the stopped state, boot using "nova 50 | boot " or reboot using "nova reboot --hard " 51 | to force the security group rules to be applied. 52 | 53 | ### Contacts / References ### 54 | Author: Doug Chivers, HPE 55 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0022 56 | Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1316822 57 | OpenStack Security ML : openstack-security@lists.openstack.org 58 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 59 | -------------------------------------------------------------------------------- /security-notes/OSSN-0026: -------------------------------------------------------------------------------- 1 | Unrestricted write permission to config files can allow code execution 2 | --- 3 | 4 | ### Summary ### 5 | In numerous places throughout OpenStack projects, variables are read 6 | directly from configuration files and used to construct statements 7 | which are executed with the privileges of the OpenStack service. Since 8 | configuration files are trusted, the input is not checked or sanitized. 9 | If a malicious user is able to write to these files, they may be able 10 | to execute arbitrary code as the OpenStack service. 11 | 12 | ### Affected Services / Software ### 13 | Nova / All versions, Trove / Juno, possibly others 14 | 15 | ### Discussion ### 16 | Some OpenStack services rely on operating system commands to perform 17 | certain actions. In some cases these commands are created by appending 18 | input from configuration files to a specified command, and passing the 19 | complete command directly to the operating system shell to execute. 20 | For example: 21 | 22 | --- begin example example.py snippet --- 23 | command='ls -al ' + config.DIRECTORY 24 | subprocess.Popen(command, shell=True) 25 | --- end example example.py snippet --- 26 | 27 | In this case, if config.DIRECTORY is set to something benign like 28 | '/opt' the code behaves as expected. If, on the other hand, an 29 | attacker is able to set config.DIRECTORY to something malicious such as 30 | '/opt ; rm -rf /etc', the shell will execute both 'ls -al /opt' and 'rm 31 | -rf /etc'. When called with shell=True, the shell will blindly execute 32 | anything passed to it. Code with the potential for shell injection 33 | vulnerabilities has been identified in the above mentioned services and 34 | versions, but vulnerabilities are possible in other services as well. 35 | 36 | Please see the links at the bottom for a couple of examples in Nova and 37 | Trove. 38 | 39 | ### Recommended Actions ### 40 | Ensure permissions for configuration files across all OpenStack 41 | services are set so that only the owner user can read/write to them. 42 | In cases where other processes or users may have write access to 43 | configuration files, ensure that all settings are sanitized and 44 | validated. 45 | 46 | Additionally the principle of least privilege should always be observed 47 | - files should be protected with the most restrictive permissions 48 | possible. Other serious security issues, such as the exposure of 49 | plaintext credentials, can result from permissions which allow 50 | malicious users to view sensitive data (read access). 51 | 52 | ### Contacts / References ### 53 | Author: Travis McPeak, HPE 54 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0026 55 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1343657 56 | OpenStack Security ML : openstack-security@lists.openstack.org 57 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 58 | Shell Injection: 59 | https://docs.python.org/2/library/subprocess.html#frequently-used-arguments 60 | Additional LaunchPad Bugs: 61 | https://bugs.launchpad.net/trove/+bug/1349939 62 | https://bugs.launchpad.net/nova/+bug/1192971 63 | -------------------------------------------------------------------------------- /security-notes/OSSN-0029: -------------------------------------------------------------------------------- 1 | Neutron FWaaS rules lack port restrictions when using protocol 'any' 2 | --- 3 | 4 | ### Summary ### 5 | A bug in the experimental Neutron FWaaS (Firewall as a Service) 6 | extension results in iptables rules being generated that do not reflect 7 | desired port restrictions. This behaviour is triggered when a protocol 8 | other than 'udp' or 'tcp' is specified, e.g. 'any'. 9 | 10 | The scope of this bug is limited to the experimental Neutron FWaaS 11 | extension and systems built upon it. It does not affect the supported 12 | core Neutron functionality. Security Groups are not affected. 13 | 14 | ### Affected Services / Software ### 15 | Neutron FWaaS, Grizzly, Havana, Icehouse 16 | 17 | ### Discussion ### 18 | When specifying firewall rules using Neutron that should match multiple 19 | protocols, it is convenient to specify a protocol of 'any' in place of 20 | defining multiple specific rules. 21 | 22 | For example, in order to allow DNS (TCP and UDP) requests, the following 23 | rule might be defined: 24 | 25 | neutron firewall-rule-create --protocol any --destination-port 53 \ 26 | --action allow 27 | 28 | However, this rule results in the generation of iptables firewall rules 29 | that do not reflect the desired port restriction. An example generated 30 | iptables rule might look like the following: 31 | 32 | -A neutron-l3-agent-iv441c58eb2 -j ACCEPT 33 | 34 | Note that the restriction on port 53 is missing. As a result, the 35 | generated rule will match and accept any traffic being processed by the 36 | rule chain to which it belongs. 37 | 38 | Additionally, iptables arranges sets of rules into chains and processes 39 | packets entering a chain one rule at a time. Rule matching stops at the 40 | first matched exit condition (e.g. accept or drop). Since, the generated 41 | rule above will match and accept all packets, it will effectively short 42 | circuit any filtering rules lower down in the chain. Consequently, this 43 | can break other firewall rules regardless of the protocol specified when 44 | defining those rules with Neutron. They simply need to appear later in 45 | the generated iptables rule chain. 46 | 47 | This bug is triggered when any protocol other than 'tcp' or 'udp' is 48 | specified in conjunction with a source or destination port number. 49 | 50 | ### Recommended Actions ### 51 | The Neutron FWaaS extension is currently experimental, and should not be 52 | used in production at this point. If you are using it, you should avoid 53 | the use of 'any' when specifying the protocol for Neutron FWaaS rules. 54 | Instead, create multiple rules for both 'tcp' and 'udp' protocols 55 | independently. 56 | 57 | This issue has been fixed in the Juno release of OpenStack. 58 | 59 | ### Contacts / References ### 60 | Author: Tim Kelsey, HP 61 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0029 62 | Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1365961 63 | OpenStack Security ML : openstack-security@lists.openstack.org 64 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 65 | -------------------------------------------------------------------------------- /security-notes/OSSN-0031: -------------------------------------------------------------------------------- 1 | Nova Baremetal is insecure for use in multi-tenant environments 2 | --- 3 | 4 | ### Summary ### 5 | Data of previous tenants may be exposed to new ones when using Nova 6 | Baremetal. 7 | 8 | ### Affected Services / Software ### 9 | Nova Baremetal, All Releases 10 | 11 | ### Discussion ### 12 | Nova Baremetal is intended for testing and development only, it is not 13 | intended to be production ready. Experience has shown that despite that 14 | warning the OpenStack community is keen to embrace new technologies and 15 | deploy at-risk. This OSSN serves to signpost some of the risks. 16 | 17 | Without secure boot, and without full openflow hardware networking 18 | during the boot process, it is impossible to trust multiple tenants on 19 | baremetal at all - because the vectors for attack are so low level that 20 | instances may be running in a virtual environment and unaware of it, 21 | with the virtual environment capturing secrets, forcing entropy pools to 22 | be predictable and other such hostile behaviour. 23 | 24 | ### Recommended Actions ### 25 | Do not use Nova Baremetal where secure separation of tenants on hardware 26 | is a requirement without a full verifiable boot chain and network 27 | hardware. 28 | 29 | ### Contacts / References ### 30 | Author: Robert Clark, HP 31 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0031 32 | Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1174153 33 | OpenStack Security ML : openstack-security@lists.openstack.org 34 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 35 | -------------------------------------------------------------------------------- /security-notes/OSSN-0032: -------------------------------------------------------------------------------- 1 | Disabling a tenant does not disable a user token 2 | --- 3 | 4 | ### Summary ### 5 | When a tenant is disabled in Keystone, tokens that have been issued to 6 | that tenant are not invalidated. This can result in users having access 7 | to your cloud after you have attempted to revoke them. 8 | 9 | ### Affected Services / Software ### 10 | Keystone, Folsom, Grizzly 11 | 12 | ### Discussion ### 13 | Keystone does not purge the tokens given out to tenants when a tenant 14 | is disabled. In some scenarios this could be very important to cloud 15 | providers. Take the case where a cloud provider must revoke a tenant's 16 | access because of some legal investigation. Even though the tenant is 17 | disabled it would be possible for them to terminate VMs / delete Swift 18 | files etc. There are many other abuse-cases. 19 | 20 | ### Recommended Actions ### 21 | This issue has been fixed in the OpenStack Havana release. The fix has 22 | also been backported to OpenStack Grizzly as a part of the 2013.1.4 23 | Keystone release. 24 | 25 | How the tokens are stored depends on your cloud deployment. If you 26 | deploy using Memcached to back Keystone then flushing the cache when 27 | disabling a token would resolve this issue for you, at the cost of other 28 | token lookups which are no longer in the cache requiring Keystone 29 | interaction. 30 | 31 | It is of course possible to script something to remove tokens from any 32 | backend DB or cache, but there is no 'official' way to do this. 33 | 34 | NOTE: Flushing Memcached can result in losing token revocation 35 | information as addressed in https://bugs.launchpad.net/ossn/+bug/1182920 36 | 37 | ### Contacts / References ### 38 | Author: Robert Clark, HP 39 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0032 40 | Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1179955 41 | OpenStack Security ML : openstack-security@lists.openstack.org 42 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 43 | CVE: CVE-2013-4222 44 | -------------------------------------------------------------------------------- /security-notes/OSSN-0033: -------------------------------------------------------------------------------- 1 | Some SSL-Enabled connections fail to perform basic certificate checks 2 | --- 3 | 4 | ### Summary ### 5 | In many places, OpenStack components use HTTPSConnection to establish 6 | an SSL connection between endpoints. Early Python versions of this 7 | class do not provide many of the assurances one would expect when 8 | using SSL and leaves connections open to potential man-in-the-middle attacks. 9 | 10 | ### Affected Services / Software ### 11 | All OpenStack services, Havana, Icehouse, Juno 12 | 13 | ### Discussion ### 14 | A secure SSL session relies on validation of a X.509 certificate. Basic 15 | checks include: 16 | 17 | - Certificate Authority trust verification 18 | - Certificate revocation status 19 | - Certificate expiration 20 | - Certificate subject name matching 21 | 22 | The HTTPSConnection class is used in a large number of locations and 23 | early Python versions failed to check that certificates are signed by a 24 | valid authority. Without that check in place, the subsequent checks (some 25 | highlighted above) are largely invalid. 26 | 27 | The result is that an attacker who has access to the network traffic 28 | between two endpoints relying on HTTPSConnection can trivially create a 29 | certificate that will be accepted by HTTPSConnection as valid - allowing 30 | the attacker to intercept, read and modify traffic that should be 31 | encrypted by SSL. 32 | 33 | Later versions of Python, namedly 2.7.9 and 3.4.3, do perform proper 34 | validation in establishing connections. So this OSSN only applies 35 | to environments running older versions of Python. 36 | 37 | ### Recommended Actions ### 38 | Some projects have updated their code to be more secure, others have 39 | not. The OSSP suggest cloud deployers check the status of the bug 40 | mentioned in the 'References' section of this note to see if the 41 | projects they require have updated. 42 | 43 | ### Contacts / References ### 44 | Author: Robert Clark, HP 45 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0033 46 | Launchpad Bugs : 47 | 48 | - https://bugs.launchpad.net/ossn/+bug/1188189 49 | - https://bugs.launchpad.net/ossn/+bug/1436082 50 | - https://bugs.launchpad.net/nova/+bug/1276207 51 | - https://bugs.launchpad.net/vmware-nsx/+bug/1487962 52 | - https://bugs.launchpad.net/vmware-nsx/+bug/1488265 53 | 54 | Python 2.x doc : https://docs.python.org/2/library/httplib.html#httplib.HTTPSConnection 55 | Python 3.x doc : https://docs.python.org/3.4/library/http.client.html#http.client.HTTPSConnection 56 | 57 | OpenStack Security ML : openstack-security@lists.openstack.org 58 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 59 | -------------------------------------------------------------------------------- /security-notes/OSSN-0034: -------------------------------------------------------------------------------- 1 | Restarting memcached loses revoked token list 2 | --- 3 | 4 | ### Summary ### 5 | When a cloud is deployed using Memcached as a backend for Keystone 6 | tokens, there is a security concern that restarting Memcached will lose 7 | the list of revoked tokens, potentially allowing bad tokens / users to 8 | access the system after they had been revoked. 9 | 10 | ### Affected Services / Software ### 11 | Keystone, Memcached, Havana, Icehouse, Juno 12 | 13 | ### Discussion ### 14 | The list of revoked tokens, stored in Memcached could be lost if the 15 | Memcached service is stopped or crashes before the revocation list is 16 | persisted on disk. 17 | 18 | There might be ways to mitigate this issue in the future, such as 19 | running Memcached on multiple machines to ensure redundancy should the 20 | Keystone server fail. In a clustered environment, it will only be an 21 | issue if all of the Memcached machines shutdown. This would require 22 | replication of data between the Memcached backends, which is not 23 | possible with Keystone today. 24 | 25 | Memcachedb might also be a potential way to mitigate this issue: 26 | 27 | http://memcachedb.org/ 28 | 29 | NOTE: Some deployments may intentionally flush Memcached in response to 30 | https://bugs.launchpad.net/ossn/+bug/1179955 - please exercise caution 31 | when considering how to approach this problem. 32 | 33 | ### Recommended Actions ### 34 | This is a fundamental problem with using in-memory ephemeral storage for 35 | security information. If your deployment has strong security 36 | requirements or a reliance on up-to-date revoked token information, we 37 | suggest you consider using an on-disk DB such as MySQL / PostgreSQL or 38 | perhaps look into Memcachedb. 39 | 40 | ### Contacts / References ### 41 | Author: Robert Clark, HP 42 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0034 43 | Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1182920 44 | OpenStack Security ML : openstack-security@lists.openstack.org 45 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 46 | -------------------------------------------------------------------------------- /security-notes/OSSN-0035: -------------------------------------------------------------------------------- 1 | HTTP Strict Transport Security not enabled on Horizon Dashboard 2 | --- 3 | 4 | ### Summary ### 5 | Deployers using Horizon for production or internet facing operations 6 | should strongly consider configuring HTTP Strict Transport Security 7 | (HSTS) for their deployment. 8 | 9 | ### Affected Services / Software ### 10 | Horizon, SSL, TLS, Apache, Nginx 11 | 12 | ### Discussion ### 13 | HTTP Strict Transport Security (HSTS) enforces that all communications 14 | with a server go over SSL. This mitigates the threat from attacks such 15 | as SSL-Strip which replaces links on the wire, stripping away https 16 | prefixes and potentially allowing an attacker to view confidential 17 | information on the wire. 18 | 19 | HSTS can be enabled in Apache and Nginx, the two primary ways of serving 20 | Horizon at scale. 21 | 22 | ### Recommended Actions ### 23 | If using Apache httpd to host Horizon, add the following to the relevant 24 | 'VirtualHost' entry in your Apache httpd configuration file: 25 | 26 | --- begin example httpd configuration snippet --- 27 | Header add Strict-Transport-Security "max-age=15768000" 28 | --- end example httpd configuration snippet --- 29 | 30 | We suggest also using mod_rewrite to ensure all visitors to Horizon land 31 | on a secure page. To accomplish this, add the following into your Apache 32 | httpd configuration file: 33 | 34 | --- begin example httpd configuration snippet --- 35 | 36 | RewriteEngine On 37 | RewriteCond %{HTTPS} off 38 | RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} 39 | 40 | --- end example httpd configuration snippet --- 41 | 42 | If using Nginx to host Horizon, add the following to your Nginx 43 | configuration file: 44 | 45 | --- begin example Nginx configuration snippet --- 46 | add_header Strict-Transport-Security max-age=15768000; 47 | --- end example Nginx configuration snippet --- 48 | 49 | As always, test these configuration settings before deploying them to 50 | production in order to catch any bugs or errors. 51 | 52 | ### Contacts / References ### 53 | Author: Robert Clark, HP 54 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0035 55 | SSL Strip : http://www.thoughtcrime.org/software/sslstrip 56 | Original LaunchPad Bug : https://bugs.launchpad.net/horizon/+bug/1191050 57 | OpenStack Security ML : openstack-security@lists.openstack.org 58 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 59 | HTTP Strict Transport Security: 60 | https://www.owasp.org/index.php/HTTP_Strict_Transport_Security 61 | -------------------------------------------------------------------------------- /security-notes/OSSN-0036: -------------------------------------------------------------------------------- 1 | Horizon does not set Secure Attribute in cookies 2 | --- 3 | 4 | ### Summary ### 5 | Horizon does not, by default, set the Secure Attribute in cookies. 6 | 7 | ### Affected Services / Software ### 8 | Horizon, Django, SSL, TLS 9 | 10 | ### Discussion ### 11 | When used in production, Horizon should have the Secure Attribute for 12 | cookies set. When this flag is set, browsers will only transfer the 13 | cookie over secure channels. Without it set, browsers may transfer the 14 | cookie over plain-text channels, potentially exposing the contents to an 15 | attacker who can then use the cookie to authenticate with the Horizon 16 | server as the original user. 17 | 18 | ### Recommended Actions ### 19 | Enable secure cookie by setting the SESSION_COOKIE_SECURE config flag to 20 | true as described in the Django documentation: 21 | 22 | https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SESSION_COOKIE_SECURE 23 | 24 | ### Contacts / References ### 25 | Author: Robert Clark, HP 26 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0036 27 | Related OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0035 28 | Original LaunchPad Bug : https://bugs.launchpad.net/horizon/+bug/1191051 29 | OpenStack Security ML : openstack-security@lists.openstack.org 30 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 31 | -------------------------------------------------------------------------------- /security-notes/OSSN-0037: -------------------------------------------------------------------------------- 1 | Configure Horizon to mitigate BREACH/CRIME attacks 2 | --- 3 | 4 | ### Summary ### 5 | Horizon is vulnerable to BREACH/CRIME style chosen plaintext attacks in 6 | it's default configuration. 7 | 8 | ### Affected Services / Software ### 9 | Horizon, Django, Apache, Nginx, SSL, TLS 10 | 11 | ### Discussion ### 12 | The BREACH attack may be used to compromise Django's cross-site request 13 | forgery (CSRF) protection. OpenStack's Horizon web dashboard is built on 14 | the Django framework, and is consequently affected. There is no fix 15 | available in Horizon itself, but there are protection options. 16 | 17 | BREACH takes advantage of vulnerabilities when serving compressed data 18 | over SSL/TLS. 19 | 20 | ### Recommended Actions ### 21 | Since BREACH is related to serving compressed data, disabling 22 | compression of web responses can be used to mitigate these type of 23 | attacks. Some methods for this include: 24 | 25 | Disable Django's GZIP Middleware: 26 | 27 | https://docs.djangoproject.com/en/dev/ref/middleware/#module-django.middleware.gzip 28 | 29 | Disable GZip compression in your web server's config. For Apache httpd, 30 | you can do this by disabling mod_deflate: 31 | 32 | http://httpd.apache.org/docs/2.2/mod/mod_deflate.html 33 | 34 | For Nginx, you can do this by disabling the gzip module: 35 | 36 | http://wiki.nginx.org/HttpGzipModule 37 | 38 | ### Contacts / References ### 39 | Author: Robert Clark, HP 40 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0037 41 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1209250 42 | OpenStack Security ML : openstack-security@lists.openstack.org 43 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 44 | Django advice on BREACH : 45 | https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/ 46 | More info on BREACH : http://breachattack.com/ 47 | -------------------------------------------------------------------------------- /security-notes/OSSN-0038: -------------------------------------------------------------------------------- 1 | Suds client subject to cache poisoning by local attacker 2 | --- 3 | 4 | ### Summary ### 5 | Suds is a Python SOAP client for consuming Web Services. Its default 6 | cache implementation stores pickled objects to a predictable path in 7 | /tmp. This can be used by a local attacker to redirect SOAP requests via 8 | symlinks or run a privilege escalation or code execution attack. 9 | 10 | ### Affected Services / Software ### 11 | Cinder, Nova, Grizzly, Havana, Icehouse 12 | 13 | ### Discussion ### 14 | The Python 'suds' package is used by oslo.vmware to interface with SOAP 15 | service APIs and both Cinder and Nova have dependencies on oslo.vmware 16 | when using VMware drivers. By default suds uses an on-disk cache that 17 | places pickle files, serialised Python objects, into a known location 18 | '/tmp/suds'. A local attacker could use symlinks or place crafted files 19 | into this location that will later be deserialised by suds. 20 | 21 | By manipulating the content of the cached pickle files, an attacker can 22 | redirect or modify SOAP requests. Alternatively, pickle may be used to 23 | run injected Python code during the deserialisation process. This can 24 | allow the spawning of a shell to execute arbitrary OS level commands 25 | with the permissions of the service using suds, thus leading to possible 26 | privilege escalation. 27 | 28 | At the time of writing, the suds package appears largely unmaintained 29 | upstream. However, vendors have released patched versions that do not 30 | suffer from the predictable cache path problem. Ubuntu is known to offer 31 | one such patched version (python-suds_0.4.1-2ubuntu1.1). 32 | 33 | ### Recommended Actions ### 34 | The recommended solution to this issue is to disable cache usage in the 35 | configuration as shown: 36 | 37 | 'client.set_options(cache=None)' 38 | 39 | A fix has been released to oslo.vmware (0.6.0) that disables the use of 40 | the disk cache by default. Cinder and Nova have both adjusted their 41 | requirements to include this fixed version. Deployers wishing to re-enable 42 | the cache should ascertain whether or not their vendor shipped suds package 43 | is susceptible and consider the above advice. 44 | 45 | ### Contacts / References ### 46 | Author: Tim Kelsey, HPE 47 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0038 48 | Original Launchpad Bug : https://bugs.launchpad.net/ossn/+bug/1341954 49 | OpenStack Security ML : openstack-security@lists.openstack.org 50 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 51 | Suds: https://pypi.python.org/pypi/suds 52 | CVE: CVE-2013-2217 53 | -------------------------------------------------------------------------------- /security-notes/OSSN-0042: -------------------------------------------------------------------------------- 1 | Keystone token scoping provides no security benefit 2 | --- 3 | 4 | ### Summary ### 5 | Keystone provides "scoped" tokens that are constrained to use by a 6 | single project. A user may expect that their scoped token can only be 7 | used to perform operations for the project it is scoped to, which is not 8 | the case. A service or other party who obtains the scoped token can use 9 | it to obtain a token for a different authorized scope, which may be 10 | considered a privilege escalation. 11 | 12 | ### Affected Services / Software ### 13 | Keystone, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, Kilo 14 | 15 | ### Discussion ### 16 | This is not a bug in keystone, it's a design feature that some users may 17 | expect to bring security enhancement when it does not. The OSSG is 18 | issuing this security note to highlight the issue. 19 | 20 | Many operations in OpenStack will take a token from the user and pass it 21 | to another service to perform some portion of the intended operation. 22 | This token is very powerful and can be used to perform many actions for 23 | the user. Scoped tokens appear to limit their use to the project and 24 | roles they were granted for but can also be used to request tokens with 25 | other scopes. It's important to note that this only works with currently 26 | valid tokens. Once a token expires it cannot be used to gain a new 27 | token. 28 | 29 | Token scoping helps avoid accidental leakage of tokens because using 30 | tokens with other services requires the extra step of requesting a new 31 | re-scoped token from keystone. Scoping can help with audit trails and 32 | promote good code practices. There's currently no way to create a 33 | tightly scoped token that cannot be used to request a re-scoped token. A 34 | scoped token cannot be relied upon to restrict actions to only that 35 | scope. 36 | 37 | ### Recommended Action ### 38 | Users and deployers of OpenStack must not rely on the scope of tokens 39 | to limit what actions can be performed using them. 40 | 41 | Concerned users are encouraged to read (OSSG member) Nathan Kinder's 42 | blog post on this issue and some of the potential future solutions. 43 | 44 | ### Contacts / References ### 45 | Author: Robert Clark, IBM 46 | Nathan Kinder on Token Scoping : https://blog-nkinder.rhcloud.com/?p=101 47 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0042 48 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1341816 49 | OpenStack Security ML : openstack-security@lists.openstack.org 50 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 51 | -------------------------------------------------------------------------------- /security-notes/OSSN-0044: -------------------------------------------------------------------------------- 1 | Older versions of noVNC allow session theft 2 | --- 3 | 4 | ### Summary ### 5 | Commonly packaged versions of noVNC allow an attacker to hijack user 6 | sessions even when TLS is enabled. noVNC fails to set the secure flag 7 | when setting cookies containing an authentication token. 8 | 9 | ### Affected Services / Software ### 10 | Nova, when embedding noVNC prior to v0.5 11 | 12 | ### Discussion ### 13 | Versions of noVNC prior to October 28, 2013 do not properly set the 14 | secure flag on cookies for pages served over TLS. Since noVNC stores 15 | authentication tokens in these cookies, an attacker who can modify 16 | user traffic can steal these tokens and connect to the VNC session. 17 | 18 | Affected deployments can be identified by looking for the "secure" 19 | flag on the token cookie set by noVNC on TLS-enabled installations. If 20 | the secure flag is missing, the installation is vulnerable. 21 | 22 | At the time of writing, Debian, Ubuntu and Fedora do not provide 23 | versions of this package with the appropriate patch. 24 | 25 | ### Recommended Actions ### 26 | noVNC should be updated to version 0.5 or later. If this is not 27 | possible, the upstream patch should be applied individually. 28 | 29 | Upstream patch: 30 | https://github.com/kanaka/noVNC/commit/ad941faddead705cd611921730054767a0b32dcd 31 | 32 | ### Contacts / References ### 33 | Author: Paul McMillan, Nebula 34 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0044 35 | Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1420942 36 | OpenStack Security ML : openstack-security@lists.openstack.org 37 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 38 | CVE: in progress-http://www.openwall.com/lists/oss-security/2015/02/17/1 39 | 40 | -------------------------------------------------------------------------------- /security-notes/OSSN-0046: -------------------------------------------------------------------------------- 1 | Setting services to debug mode can also set Pecan to debug 2 | --- 3 | 4 | ### Summary ### 5 | When debug mode is set for a service using Pecan (via --debug or 6 | CONF.debug=True) Pecan is also set to debug. This can result in 7 | accidental information disclosures. 8 | 9 | ### Affected Services / Software ### 10 | Blazar, Ceilometer, Cue, Gnocchi, Ironic, Kite, Libra, Pecan, Tuskar 11 | 12 | ### Discussion ### 13 | Although it's best practice to run production environments with 14 | debugging functionality disabled, experience shows us that many 15 | deployers choose to run OpenStack with debugging enabled to aid with 16 | administration and fault finding. 17 | 18 | When Pecan is running in debug mode, the following capabilities are made 19 | available to anyone who can interact with the API service: 20 | 21 | * Retrieve a stack trace of failed Pecan calls 22 | * Retrieve a full list of environment variables containing potentially 23 | sensitive information such as API credentials, passwords etc. 24 | * Set an execution breakpoint which hangs the service with a pdb shell, 25 | resulting in a denial of service 26 | 27 | ### Recommended Actions ### 28 | At time of writing, Ceilometer, Gnocchi and Ironic have released fixes. 29 | Deployers are encouraged to apply these fixes (see launchpad bug in 30 | References) in their clouds. For services that do not have a fix, or 31 | where fixes cannot be applied in existing deployments, we advise not 32 | using the debug configuration for affected services in production 33 | environments. 34 | 35 | ### Contacts / References ### 36 | Author: Robert Clark, IBM 37 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0046 38 | Original LaunchPad Bug : https://bugs.launchpad.net/ironic/+bug/1425206 39 | OpenStack Security ML : openstack-security@lists.openstack.org 40 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 41 | Pecan : http://www.pecanpy.org/ 42 | -------------------------------------------------------------------------------- /security-notes/OSSN-0052: -------------------------------------------------------------------------------- 1 | Python-swiftclient exposes raw token values in debug logs 2 | --- 3 | 4 | ### Summary ### 5 | The password and authentication token configuration options for the 6 | python-swiftclient are not marked as secret. The values of these options 7 | will be logged to the standard logging output when the controller is run 8 | in debug mode. 9 | 10 | ### Affected Services / Software ### 11 | Python-swiftclient, Swift, Glance, Juno, Kilo 12 | 13 | ### Discussion ### 14 | When using the python-swiftclient to connect to Glance, and the 15 | :glance-api.conf: has set the value of the debug option to True, the 16 | requests sent through the API, including user and token details, will be 17 | captured in the local log mechanism. 18 | 19 | ### Recommended Actions ### 20 | It is recommended to use the debug level in configurations only when 21 | necessary to troubleshoot an issue. When the debug flag is set, the 22 | resulting logs should be treated as having sensitive information and as 23 | such should have strict permissions around the file and containing 24 | directory set in the operating system. Additionally, the logs should 25 | not be transported off the system in plaintext such as through syslog. 26 | 27 | The debug level can be turned off by setting the following option in 28 | the `glance-api.conf` file: 29 | 30 | [DEFAULT] 31 | debug = false 32 | 33 | ### Contacts / References ### 34 | Author: Nathaniel Dillon, HPE 35 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0052 36 | Original LaunchPad Bug : https://bugs.launchpad.net/python-swiftclient/+bug/1470740 37 | OpenStack Security ML : openstack-security@lists.openstack.org 38 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 39 | -------------------------------------------------------------------------------- /security-notes/OSSN-0054: -------------------------------------------------------------------------------- 1 | Potential Denial of Service in Horizon login 2 | --- 3 | 4 | ### Summary ### 5 | Horizon uses the Python based Django web framework. Older versions of 6 | this framework allow an unauthorized user to fill up the session store 7 | database causing a Horizon denial of service. A fix for Django is 8 | available but works only with Kilo and later versions of Horizon. 9 | 10 | ### Affected Services / Software ### 11 | Horizon, Django, Essex, Folsom, Grizzly, Havana, Icehouse, Juno 12 | 13 | ### Discussion ### 14 | Django will record the session ID of web requests even when the request 15 | is from an unauthorized user. This allows an attacker to populate the 16 | session store database with invalid session information, potentially 17 | causing a denial of service condition by filling the database with 18 | useless session information. 19 | 20 | ### Recommended Actions ### 21 | The Django developers have released a fix for this issue which is 22 | included in software versions 1.4.21, 1.7.9 and 1.8.3. Horizon 23 | administrators should ensure that they are using an up to date version 24 | of Django to avoid being affected by this vulnerability. 25 | 26 | Versions of Horizon prior to Kilo cannot run with the fixed version of 27 | Django, and may require updating to a newer version of OpenStack. 28 | Administrators can test if their deployment is affected by attempting to 29 | inject invalid sessions into the session store database using the 30 | following script and then querying the session store database to check 31 | if multiple 'aaaaa' session ID's were recorded. 32 | 33 | ---- begin example ---- 34 | for i in {1..100} 35 | do 36 | curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null 37 | done 38 | ---- end example ---- 39 | 40 | If possible, affected users should upgrade to the Kilo or newer release 41 | of Horizon, allowing them to use the fixed version of Django. 42 | 43 | ### Contacts / References ### 44 | Author: Robert Clark, IBM 45 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0054 46 | Django fix : https://www.djangoproject.com/weblog/2015/jul/08/security-releases/ 47 | Django CVE : CVE-2015-5143 48 | Original LaunchPad Bug : https://bugs.launchpad.net/horizon/+bug/1457551 49 | OpenStack Security ML : openstack-security@lists.openstack.org 50 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 51 | -------------------------------------------------------------------------------- /security-notes/OSSN-0055: -------------------------------------------------------------------------------- 1 | Service accounts may have cloud admin privileges 2 | --- 3 | 4 | ### Summary ### 5 | OpenStack services (for example Nova and Glance) typically use a 6 | service account in Keystone to perform actions. In some cases this 7 | service account has full admin privileges, may therefore perform any 8 | action on your cloud, and should be protected appropriately. 9 | 10 | ### Affected Services / Software ### 11 | Most OpenStack services / all versions 12 | 13 | ### Discussion ### 14 | In many cases, OpenStack services require an OpenStack account to 15 | perform API actions such as validating Keystone tokens. Some 16 | deployment tools grant administrative level access to these service 17 | accounts, making these accounts very powerful. 18 | 19 | A service account with administrator access could be used to: 20 | 21 | - destroy/modify/access data 22 | - create or destroy admin accounts 23 | - potentially escalate to undercloud access 24 | - log in to Horizon 25 | 26 | ### Recommended Actions ### 27 | Service accounts can use the "service" role rather than admin. You 28 | can check what role the service account has by performing the following 29 | steps: 30 | 31 | 1. List roles: 32 | 33 | openstack role list 34 | 35 | 2. Check the role assignment for the service user in question: 36 | 37 | openstack role assignment list --user 38 | 39 | 3. Compare the ID listed in the "role" column from step 2 with the role 40 | IDs listed in step 1. If the role is listed as "admin", the service 41 | account has full admin privileges on the cloud. 42 | 43 | It is possible to change the role to "service" for some accounts but 44 | this may have unexpected consequences for services such as Nova and 45 | Neutron, and is therefore not recommended for inexperienced admins. 46 | 47 | If a service account does have admin, it's advisable to closely 48 | monitor login events for that user to ensure that it is not used 49 | unexpectedly. In particular, pay attention to unusual IPs using the 50 | service account. 51 | 52 | ### Contacts / References ### 53 | Author: Travis McPeak, HPE and Brant Knudson, IBM 54 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0055 55 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1464750 56 | OpenStack Security ML : openstack-security@lists.openstack.org 57 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 58 | 59 | -------------------------------------------------------------------------------- /security-notes/OSSN-0056: -------------------------------------------------------------------------------- 1 | Cached keystone tokens may be accepted after revocation 2 | --- 3 | 4 | ### Summary ### 5 | Keystone auth_token middleware token and revocation list caching is used 6 | to reduce the load on the keystone service. The default token cache time 7 | is set to 300 seconds and the default token revocation list cache time 8 | is set to 10 seconds. This creates a misleading expectation that revoked 9 | tokens will not be accepted more than 10 seconds after revocation, 10 | however the maximum validity of a cached token must be assumed to be the 11 | cache duration. System owners should make a risk based decision to 12 | balance token lifespan with performance requirements and if the use of 13 | revoked tokens is an unacceptable risk then caching should be disabled. 14 | 15 | ### Affected Services / Software ### 16 | OpenStack Services that use Keystone middleware: Juno, Kilo, Liberty 17 | 18 | ### Discussion ### 19 | There are multiple options for configuring token caching in the keystone 20 | auth_token middleware. These options include token_cache_time, 21 | revocation_cache_time and check_revocations_for_cached, with each option 22 | affecting the different stages of token caching and revocation. 23 | Depending on the configuration the previously mentioned options, an 24 | attacker could use a compromised token for up to token_cache_time seconds 25 | before the token becomes disabled. To mitigate this vulnerability, a 26 | change was issued in Juno where the default Token Revocation List (TRL) 27 | cache time was reduced to 10 seconds and the 28 | check_revocations_for_cached option was added. The addition of a token 29 | to a TRL does not guarantee that cached tokens will be rejected 30 | considering the operational nature of token caching. For instance, if 31 | the check_revocations_for_cached is disabled then tokens are valid after 32 | caching token_cache_time or the designated expiration given to the 33 | token. Otherwise (if check_revocations_for_cached is enabled) then 34 | tokens are rejected after the revocation_cache_time. 35 | 36 | System owners should weigh the risk of an attacker using a revoked token 37 | versus the performance implications of reducing the token cache time. 38 | 39 | ### Recommended Actions ### 40 | Review the implications of the default 300 second token cache time and 41 | any risks associated with the use of revoked tokens for up to that cache 42 | time. If this is unacceptable, reduce the cache time to reduce the 43 | attack window or disable token caching entirely. 44 | 45 | ### Contacts / References ### 46 | Author: Shellee Arnold, HPE 47 | Author: Dough Chivers, HPE 48 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0056 49 | Original LaunchPad Bug : https://bugs.launchpad.net/python-keystoneclient/+bug/1287301 50 | OpenStack Security ML : openstack-security@lists.openstack.org 51 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 52 | -------------------------------------------------------------------------------- /security-notes/OSSN-0057: -------------------------------------------------------------------------------- 1 | DoS attack on Glance service can lead to interruption or disruption 2 | --- 3 | 4 | ### Summary ### 5 | The typical Glance workflow allows authenticated users to create an 6 | image and upload the image content in a separate step. This can be 7 | abused by malicious users to flood the Glance database with entries 8 | for zero sized images. 9 | 10 | ### Affected Services / Software ### 11 | Glance, Icehouse, Juno, Kilo, Liberty 12 | 13 | ### Discussion ### 14 | Glance by default allows an authenticated user to create zero size 15 | images. Those images do not consume resources on the storage backend 16 | and do not hit any limits for size, but do take up space in the 17 | database. 18 | 19 | Malicious users can potentially cause database resource depletion with 20 | an endless flood of 'image-create' requests. 21 | 22 | ### Recommended Actions ### 23 | For current stable OpenStack releases, users can workaround this 24 | vulnerability by using rate-limiting proxies to cover access to the 25 | Glance API. Rate-limiting is a common mechanism to prevent DoS and 26 | Brute-Force attacks. Rate limiting on the API requests allows a delay 27 | in the consequences of the attack, but does not prevent it. 28 | 29 | For example, if you are using a proxy such as Repose, enable the rate 30 | limiting feature by following these steps: 31 | 32 | https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter 33 | 34 | An alternative approach to mitigate this issue would be to restrict 35 | image creates to trusted administrators within your deployed Glance 36 | policy.json file. 37 | 38 | "add_image": "role:admin", 39 | 40 | Another preventative action would be to monitor the logs to identify 41 | excessive image create requests. One example of such a log message 42 | is as follows (single line, wrapped): 43 | 44 | ---- begin example glance-api.log snippet ---- 45 | DEBUG glance.registry.client.v1.api [req-da1cafc0-f41f-4587-a484-672ba7f3546e 46 | admin 8b04efc28055428c940505838314f262 - - -] 47 | Adding image metadata... add_image_metadata 48 | /usr/lib/python2.7/dist-packages/glance/registry/client/v1/api.py:161 49 | ---- end example glance-api.log snippet ---- 50 | 51 | ### Contacts / References ### 52 | Author: Eric Brown, VMware 53 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0057 54 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1401170 55 | OpenStack Security ML : openstack-security@lists.openstack.org 56 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 57 | -------------------------------------------------------------------------------- /security-notes/OSSN-0058: -------------------------------------------------------------------------------- 1 | Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes 2 | --- 3 | 4 | ### Summary ### 5 | When using the LVMISCSIDriver with Cinder, the credentials for CHAP 6 | authentication are not formatted correctly in the tgtadm configuration 7 | file. This leads to a condition where an operator will expect that 8 | volumes can only be mounted with the authentication credentials when, 9 | in fact, they can be mounted without the credentials. 10 | 11 | ### Affected Services / Software ### 12 | Cinder, Icehouse 13 | 14 | ### Discussion ### 15 | When requesting that LVMISCSIDriver based volumes use the CHAP 16 | authentication protocol, Cinder will add the credentials for 17 | authentication to the configuration file for the tgtadm 18 | application. In pre-Juno versions of Cinder the key name for these 19 | credentials is incorrect. This incorrect key name will cause tgtadm 20 | to not properly parse those credentials. 21 | 22 | With incorrect credentials in place, tgtadm will fail to authenticate 23 | volume mounting when requested by Cinder. The failed setting of 24 | credentials through the configuration file will also allow 25 | unauthenticated access to these volumes. This can allow instances 26 | on the same network as the volumes to mount them without providing the 27 | credentials to the tgtadm application. 28 | 29 | This behavior can be confirmed by displaying the accounts associated 30 | with a volume. For volumes which have authentication enabled, you will 31 | see an account listed in the output of the tgtadm application. The 32 | account names created by Cinder will be randomly generated and will 33 | appear as 20 character strings. To print the information for volumes 34 | the following command can be run on nodes with attached volumes: 35 | 36 | # tgtadm --lld iscsi --op show --mode target 37 | 38 | User names will be found in the `Account information:` section. 39 | 40 | ### Recommended Actions ### 41 | If possible, Cinder should be updated to the Juno release or newer. If 42 | this is not possible, then the following guidance will help mitigate 43 | unwanted traffic to the affected nodes. 44 | 45 | 1. Identify the nodes that will be exposing Cinder volumes with the 46 | LVMISCSIDriver and the nodes that will need to attach those volumes. 47 | 48 | 2. Implement either security group port rules or iptables rules on 49 | the nodes exposing the volumes to only allow traffic through port 3260 50 | from nodes that will need to attach volumes. 51 | 52 | ### Contacts / References ### 53 | Author: Michael McCune, Red Hat 54 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0058 55 | Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1329214 56 | OpenStack Security ML : openstack-security@lists.openstack.org 57 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 58 | -------------------------------------------------------------------------------- /security-notes/OSSN-0059: -------------------------------------------------------------------------------- 1 | Trusted VM can be powered on untrusted hosts 2 | --- 3 | 4 | ### Summary ### 5 | A trusted VM that has been launched earlier on a trusted host can 6 | still be powered on from the same host even after the trusted host is 7 | compromised. 8 | 9 | ### Affected Services / Software ### 10 | Nova, Trusted Computing Pools 11 | 12 | ### Discussion ### 13 | Trusted Computing Pools aim to ensure the trustworthiness of the hosts 14 | leveraging hardware-based security features. When an instance is 15 | scheduled, the scheduler finds a trusted host by calling the remote 16 | Attestation API for each host to check whether it is trusted or not. 17 | Then, the scheduler calls the corresponding compute node to launch 18 | the VM. Once the VM is launched, the scheduler is no longer involved 19 | unless a migration, a resize or an evacuation is asked for that VM. 20 | 21 | Malicious users can bypass the trust check by the Attestation API using 22 | these steps: 1) Launch a trusted VM on a trusted host; 2) Stop the 23 | VM on the trusted host; 3) Compromise the host; 4) Power on the VM from 24 | the compromised host. There is no check by the Attestation API for 25 | powering on the VM in this case. 26 | 27 | ### Recommended Actions ### 28 | We recommend investigating further if the trust check by Attestation 29 | API fails but the VM still boots. Another approach is to combine 30 | secure boot with trusted boot. At the same time, Nova team has 31 | discussed deprecating Trusted Filter. 32 | 33 | ### Contacts / References ### 34 | Author: Michael Xin, Rackspace 35 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0059 36 | Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1456228 37 | OpenStack Security ML : openstack-security@lists.openstack.org 38 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 39 | Nova Team Email Proposing Deprecation: 40 | http://lists.openstack.org/pipermail/openstack-dev/2015-June/067766.html 41 | CR Demoting TrustedFilter to "experimental": 42 | https://review.openstack.org/#/c/194592 43 | -------------------------------------------------------------------------------- /security-notes/OSSN-0060: -------------------------------------------------------------------------------- 1 | Glance configuration option can lead to privilege escalation 2 | --- 3 | 4 | ### Summary ### 5 | Glance exposes a configuration option called `use_user_token` in the 6 | configuration file `glance-api.conf`. It should be noted that the 7 | default setting (`True`) is secure. If, however, the setting is 8 | changed to `False` and valid admin credentials are supplied in the 9 | following section (`admin_user` and `admin_password`), Glance API 10 | commands will be executed with admin privileges regardless of the 11 | intended privilege level of the calling user. 12 | 13 | ### Affected Services / Software ### 14 | Glance, Juno, Kilo, Liberty 15 | 16 | ### Discussion ### 17 | 18 | The `use_user_token` configuration option was created to enable 19 | automatic re-authentication for tokens whch are close to expiration, 20 | thus preventing the tokens from expiring in the middle of 21 | longer-lasting Glance commands. Unfortunately the implementation 22 | enables privilege escalation attacks by automatically executing API 23 | commands as an administrator level user. 24 | 25 | By default `use_user_token` is set to `True` which is secure. If the 26 | option is disabled (set to `False`) and valid admin credentials are 27 | specified in the `glance-api.conf` file, API commands will be executed 28 | as the supplied admin user regardless of the intended privileges of the 29 | calling user. Glance API v2 configurations which don't enable the 30 | registry service (`data_api = glance.db.registry.api`) aren't affected. 31 | 32 | Enabling unauthenticated and lower privileged users to execute Glance 33 | commands with administrator privileges is very dangerous and may 34 | expose risks including: 35 | 36 | - tampering with images 37 | - deleting images 38 | - denial of service attacks 39 | 40 | ### Recommended Actions ### 41 | A comprehensive fix will be included in the Mitaka release. Meanwhile 42 | it is recommended that all users ensure that `use_user_token` is left 43 | at the default setting (`True`) or commented out. 44 | 45 | ### Contacts / References ### 46 | Author: Travis McPeak, HPE 47 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0060 48 | Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1493448 49 | OpenStack Security Documentation : https://security.openstack.org 50 | OpenStack Security Project : https://wiki.openstack.org/wiki/Security 51 | Bug Introduction : https://review.openstack.org/#/c/29967/ 52 | -------------------------------------------------------------------------------- /security-notes/OSSN-0061: -------------------------------------------------------------------------------- 1 | Glance image signature uses an insecure hash algorithm (MD5) 2 | --- 3 | 4 | ### Summary ### 5 | During the Liberty release the Glance project added a feature that 6 | supports verifying images by their signature. There is a flaw in the 7 | implementation that degrades verification by using the weak MD5 8 | algorithm. 9 | 10 | ### Affected Services / Software ### 11 | Glance, Liberty 12 | 13 | ### Discussion ### 14 | A signature algorithm is typically created by hashing data and then 15 | encrypting that hash in some way. In the case of the new Glance feature 16 | the signature algorithm does not hash the image to be verified. It 17 | rehashes the existing MD5 checksum that is used to locally verify the 18 | integrity of image data stored in Glance. 19 | 20 | The Glance image signature algorithm uses configurable hash algorithms. 21 | No matter which algorithm is used, the overall security of the algorithm 22 | is degraded to that of MD5 because instead of applying it to the image 23 | data it's applied only to the MD5 checksum that already exists in 24 | Glance. 25 | 26 | The image signature algorithm is a relatively new feature, introduced in 27 | the Liberty release. 28 | 29 | ### Recommended Actions ### 30 | Users concerned with image security should be aware that the current 31 | Glance signature algorithm is not secure by today's cryptographic 32 | standards. 33 | 34 | A specification for a fix has been proposed by the Glance development 35 | team and is targeted for the Mitaka release. 36 | 37 | ### Contacts / References ### 38 | Author: Robert Clark, IBM 39 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0061 40 | Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1516031 41 | OpenStack Security ML : openstack-security@lists.openstack.org 42 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 43 | Glance Spec for fix : https://review.openstack.org/#/c/252462/ 44 | CVE : CVE-2015-8234 45 | -------------------------------------------------------------------------------- /security-notes/OSSN-0063: -------------------------------------------------------------------------------- 1 | Nova and Cinder key manager for Barbican misuses cached credentials 2 | --- 3 | 4 | ### Summary ### 5 | During the Icehouse release the Cinder and Nova projects added a feature 6 | that supports storage volume encryption using keys stored in Barbican. 7 | The Barbican key manager, that is part of Nova and Cinder, had a bug 8 | that could cause an authorized user to lose access to an encryption key 9 | or allow the wrong user to gain access to an encryption key. 10 | 11 | ### Affected Services / Software ### 12 | Cinder: Icehouse, Juno, Kilo, Liberty 13 | Nova: Juno, Kilo, Liberty 14 | 15 | ### Discussion ### 16 | The Barbican key manager is a feature that is part of Nova and Cinder to 17 | allow those projects to create and retrieve keys in Barbican. The key 18 | manager includes a cache function that allows for a copy_key() operation 19 | to work while only validating the token once with Keystone. 20 | 21 | This cache function had a bug such that the cached token was used for 22 | operations where it was no longer valid. The symptoms of this error 23 | vary, but include a user not being able to access their key or the wrong 24 | user being able to access a key. 25 | 26 | An affected user would see an error similar to this in their cinder log: 27 | 28 | ---- begin cinder.log sample snippet ---- 29 | 2015-12-03 09:09:03.648 TRACE cinder.volume.api Unauthorized: The 30 | request you have made requires authentication. (Disable debug mode to 31 | suppress these details.) (HTTP 401) (Request-ID: 32 | req-d2c52e0b-c16d-43ec-a7a0-7611113f1270) 33 | ---- end cinder.log sample snippet ---- 34 | 35 | ### Recommended Actions ### 36 | Users wishing to use the Barbican key manager to provided keys for 37 | volume encryption with Nova and Cinder should ensure they are using a 38 | patched version. 39 | 40 | A specification for a fix has been merged for the Mitaka release of both 41 | Nova and Cinder. Additionally these patches have been backported to 42 | stable/kilo and stable/liberty. 43 | 44 | ### Contacts / References ### 45 | Author: Dave McCowan, Cisco 46 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0063 47 | Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1523646 48 | OpenStack Security ML : openstack-security@lists.openstack.org 49 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 50 | Nova patch for Mitaka : https://review.openstack.org/254358/ 51 | Nova patch for stable/liberty: https://review.openstack.org/288490 52 | Cinder patch for Mitaka : https://review.openstack.org/254357/ 53 | Cinder patch for stable/liberty: https://review.openstack.org/266678 54 | Cinder patch for stable/kilo: https://review.openstack.org/266680 55 | CVE : N/A 56 | -------------------------------------------------------------------------------- /security-notes/OSSN-0066: -------------------------------------------------------------------------------- 1 | MongoDB guest instance allows any user to connect 2 | --- 3 | 4 | ### Summary ### 5 | When creating a new MongoDB single instance or cluster the default setting in 6 | MongoDB `security.authorization` was set as disabled. This resulted in no need 7 | to provide user credentials to connect to the mongo instance and perform read / 8 | write operations from any network that is attached on instance create. 9 | 10 | ### Affected Services / Software ### 11 | Trove, Liberty 12 | 13 | ### Discussion ### 14 | MongoDB contains a security config set within `mongo.conf` as follows: 15 | 16 | security: 17 | authorization: "enabled" 18 | 19 | When creating a new MongoDB instance, or cluster within Trove the `security` 20 | value was not populated resulting in MongoDB adopting the default value of 21 | `disabled`. With security authorization disabled there would be no enforcement 22 | of user authentication, allowing users to connect and perform read/write data 23 | operations from any network that is attached on instance create. 24 | 25 | A fix was implemented within Mitaka and back ported to Liberty that addresses 26 | the problem by enabling authorization by default on single instances. This can 27 | be toggled via configuration groups. 28 | 29 | Cluster security is determined by the Trove config variable 30 | `mongodb.cluster_secure`. This cannot be toggled once the cluster is created. 31 | 32 | ### Recommended Actions ### 33 | Single instances are now use role based access control (RBAC) by default. To 34 | disable RBAC, the Trove user can attach a security group with 35 | `security.authorization` set to `disabled`. It can be re-enabled by detaching 36 | the security group or changing the value to `enabled`. 37 | 38 | The Trove config variable `mongodb.cluster_secure` 39 | (boolean type, in `trove.conf`) determines the RBAC state of MongoDB clusters 40 | that are created. Setting this to true enables RBAC while false disables it. 41 | This applies to all MongoDB clusters, and requires a restart of the trove-api 42 | service to change, and cannot be toggled on running clusters. 43 | 44 | ### Contacts / References ### 45 | Author: Luke Hinds, Red Hat 46 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066 47 | Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841 48 | Mailing List : [Security] tag on openstack-dev@lists.openstack.org 49 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 50 | -------------------------------------------------------------------------------- /security-notes/OSSN-0070: -------------------------------------------------------------------------------- 1 | Bandit versions lower than 1.1.0 do not escape HTML in issue reports 2 | --- 3 | 4 | ### Summary ### 5 | Bandit versions lower than 1.1.0 have a bug in the HTML report formatter that 6 | does not escape HTML in issue context snippets. This could lead to an XSS if 7 | HTML reports are hosted as part of a CI pipeline. 8 | 9 | ### Affected Services / Software ### 10 | Bandit: < 1.1.0 11 | 12 | ### Discussion ### 13 | Bandit versions lower than 1.1.0 have a bug in the HTML report formatter that 14 | does not escape HTML in issue context snippets. This could lead to an XSS 15 | attack if HTML reports are hosted as part of a CI pipeline because HTML in the 16 | source code would be copied verbatim into the report. For example: 17 | 18 | import subprocess 19 | subprocess.Popen("", shell=True) 20 | 21 | Will cause "" to be inserted into the HTML report. 22 | This issue could allow for arbitrary code injection into CI/CD pipelines that 23 | feature accessible HTML reports generated from Bandit runs. 24 | 25 | ### Recommended Actions ### 26 | Update bandit to version 1.1.0 or greater. 27 | 28 | ### Contacts / References ### 29 | Author: Tim Kelsey , HPE 30 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0063 31 | Original LaunchPad Bug : https://bugs.launchpad.net/bandit/+bug/1612988 32 | OpenStack Security ML : openstack-security@lists.openstack.org 33 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 34 | CVE: N/A 35 | -------------------------------------------------------------------------------- /security-notes/OSSN-0073: -------------------------------------------------------------------------------- 1 | Horizon dashboard leaks internal information through cookies 2 | --- 3 | 4 | ### Summary ### 5 | When horizon is configured, its URL contains the IP address of 6 | the internal URL of keystone, as the default value for the identity 7 | service is "internalURL".[1] 8 | 9 | The cookie "login_region" will be set to the value configured as 10 | OPENSTACK_KEYSTONE_URL, given in the local_settings.py file. 11 | 12 | Usually, the OPENSTACK_KEYSTONE_URL is the publicURL, and hence 13 | the cookie URL will also be the public one. If set to internal URL 14 | (by default), then the login cookie URL will be the internal URL or IP. 15 | So, by putting the OPENSTACK_KEYSTONE_URL in the cookie that is sent to 16 | the public network, horizon leaks the values of the internal network IP 17 | address. 18 | 19 | ### Affected Services and Software ### 20 | horizon 21 | 22 | ### Discussion ### 23 | This is not a bug in horizon, but a possible misconfiguration issue. 24 | 25 | Exposing the internal URL is not a bug, since one can view the internal 26 | URL as it's a freely accessible endpoint to authorized users, or 27 | it's hidden behind a firewall. Also, the data for internal URLs are 28 | freely available in the catalog and the catalog is not considered 29 | private information. 30 | 31 | ### Contacts / References ### 32 | Author: Khanak Nangia, Intel 33 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0073 34 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1585831 35 | Related bug : https://bugs.launchpad.net/horizon/+bug/1597864 36 | OpenStack Security ML : openstack-dev@lists.openstack.org 37 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 38 | 39 | [1]: https://docs.openstack.org/horizon/latest/contributor/topics/index.html 40 | -------------------------------------------------------------------------------- /security-notes/OSSN-0077: -------------------------------------------------------------------------------- 1 | Pre-auth COPY in versioned_writes can result in a successful COPY that 2 | wouldn't have been authorized 3 | --- 4 | 5 | ### Summary ### 6 | This issue is related to the versioning feature of swift and potentially 7 | allows unauthorized users to drive up the storage usage of a third party 8 | account. 9 | 10 | Specifically a user can create versions of existing objects belonging to 11 | projects for which he has no authorization. The malicious user cannot 12 | read or write the specific object, or create objects with arbitrary content. 13 | 14 | ### Affected Services / Software ### 15 | Swift < 2.10.0 16 | 17 | ### Discussion ### 18 | A versioned write PUT uses a pre-authed request to move an object into 19 | the versioned container before checking whether the user is authorized. 20 | So a user can select a versioned object path that it does not have access to, 21 | request a put on that versioned object, and the request will execute the copy 22 | part before it fails due to lack of permissions. 23 | 24 | ### Recommended Actions ### 25 | Update Swift to version 2.10.0 where possible. 26 | 27 | ### Contacts / References ### 28 | Author: Vincenzo Di Somma 29 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0077 30 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1562175 31 | Mailing List : [Security] tag on openstack-dev@lists.openstack.org 32 | OpenStack Security Group : https://launchpad.net/~openstack-ossg 33 | -------------------------------------------------------------------------------- /security-notes/OSSN-0078: -------------------------------------------------------------------------------- 1 | copy_from in Image Service API v1 allows network port scan 2 | ---------------------------------------------------------- 3 | 4 | ### Summary ### 5 | The `copy_from` feature in Image Service API v1 supplied by Glance can 6 | allow an attacker to perform masked network port scans. 7 | 8 | ### Affected Services / Software ### 9 | Version 1 of the Glance Image Service (deprecated in Newton). 10 | 11 | ### Discussion ### 12 | In Version 1 of the Glance Image Service API it is possible to create 13 | images with a URL such as `http://localhost:22`. This could then allow 14 | an attacker to enumerate internal network details while appearing 15 | masked, since the scan would appear to originate from the Glance image 16 | service. 17 | 18 | ### Recommended Actions ### 19 | Version 1 of the Glance Image Service API was deprecated in the Newton 20 | cycle, so operators should upgrade to a later version that will allow 21 | use of Version 2. 22 | 23 | Existing deployments can limit policy on `copy_from` by restricting use 24 | to `admin` within `policy.json` as follows: 25 | 26 | "copy_from": "role:admin" 27 | 28 | ### Contacts / References ### 29 | Author: Luke Hinds, Red Hat 30 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0078 31 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1606495 32 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 33 | -------------------------------------------------------------------------------- /security-notes/OSSN-0079: -------------------------------------------------------------------------------- 1 | Ceph credentials included in logs using older versions of libvirt/qemu 2 | ---------------------------------------------------------------------- 3 | 4 | ### Summary ### 5 | Older versions of libvirt included network storage authentication 6 | information on the qemu command line. If libvirt raises an exception 7 | which logs the qemu command line it used, for example an error starting 8 | a domain, this authentication information will available in the logs. 9 | 10 | ### Affected Services / Software ### 11 | Versions 2.5 and earlier of QEMU and libvirt versions of 2.1 or ealier. 12 | 13 | The issue has been resolved in all QEMU versions 2.6 and above and 14 | libvirt 2.2 and above. 15 | 16 | No patches or specific releases of Nova or Ceph are required, the 17 | issue is completely resolved in QEMU and libvirt. 18 | 19 | ### Discussion ### 20 | If a deployment is using ceph, a libvirt error starting a domain would 21 | log the cephx secret key and the monitor addresses on the qemu command 22 | line. 23 | 24 | A local attacker could then use this flaw to gain access of the cephx 25 | secret key and perform certain privileged operations within the cluster. 26 | 27 | An existing CVE is already present for this issue [1]. 28 | 29 | ### Recommended Actions ### 30 | The issue has been resolved upstream. Users running qemu version 2.6 or 31 | later, and libvirt version 2.2 or later, are not vulnerable. 32 | 33 | No change is required in Nova or Ceph to resolve this issue. 34 | 35 | ### Contacts / References ### 36 | Author: Luke Hinds, Red Hat 37 | https://access.redhat.com/security/cve/CVE-2015-5160 38 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0079 39 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1686743 40 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 41 | -------------------------------------------------------------------------------- /security-notes/OSSN-0081: -------------------------------------------------------------------------------- 1 | sha512_crypt is insufficient for password hashing 2 | ------------------------------------------------- 3 | 4 | ### Summary ### 5 | 6 | Use of sha512_crypt for password hashing in versions of Keystone prior to Pike, 7 | is insufficient and provides limited protection against brute-forcing of 8 | password hashes. 9 | 10 | ### Affected Services / Software ### 11 | OpenStack Identity Service (Keystone). OpenStack Releases Ocata, Newton. 12 | 13 | ### Discussion ### 14 | 15 | Keystone uses sha512_crypt for password hashing. This provides insufficient and 16 | limited protection, since sha512_crypt algorithm has a low computational cost 17 | factor, therefore making it easier to crack passwords offline in a short period 18 | of time. 19 | 20 | The correct mechanism is to use the more secure hashing algorithms with a 21 | higher computational cost factor such as bcrypt, scrypt, or pbkdf2_sha512 22 | instead of sha512_crypt. 23 | 24 | ### Recommended Actions ### 25 | 26 | It is recommended that operators upgrade to the Pike release where all future 27 | passwords would be bcrypt hashed. 28 | 29 | Operators should also force password changes on all users [1], which will 30 | result in the users newly generated passwords being bcrypt hashed. 31 | 32 | ### Contacts / References ### 33 | Author: Luke Hinds 34 | [1]: https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#force-users-to-change-password-upon-first-use 35 | [2] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf 36 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0081 37 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1668503 38 | Mailing List : [Security] tag on openstack-dev@lists.openstack.org 39 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 40 | -------------------------------------------------------------------------------- /security-notes/OSSN-0082: -------------------------------------------------------------------------------- 1 | Heap and Stack based buffer overflows in dnsmasq prior to version 2.78 2 | ---------------------------------------------------------------------- 3 | 4 | ### Summary ### 5 | A series of heap and stack based buffer overflows have been discovered in 6 | versions of dnsmasq prior to release 2.78. 7 | 8 | ### Affected Services / Software ### 9 | Any neutron based OpenStack deployment on a version of dnsmasq prior to 10 | 2.78. 11 | 12 | ### Discussion ### 13 | The following attack vectors have been assigned the following CVE numbers. 14 | 15 | * CVE-2017-14491 16 | * CVE-2017-14492 17 | * CVE-2017-14493 18 | * CVE-2017-14494 19 | * CVE-2017-14495 20 | * CVE-2017-14496 21 | * CVE-2017-13704 22 | 23 | Each of these CVE's exposes a neutron based OpenStack deployment to various 24 | attacks such as leakage of sensitive memory information or causing a denial of 25 | service. Nodes are exposed to this risk by the crafting of various nefarious 26 | DNS or DHCP requests. 27 | 28 | ### Recommended Actions ### 29 | Operators should update the dnsmasq service using the affected nodes operating 30 | systems packaging tools to version 2.78 and later, or a distribution packaged 31 | version that contains relevant backports for these vulnerabilities. 32 | 33 | ### Contacts / References ### 34 | Author: Luke Hinds 35 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0082 36 | Mailing List : [Security] tag on openstack-dev@lists.openstack.org 37 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 38 | CVE: CVE-2017-14491 39 | -------------------------------------------------------------------------------- /security-notes/OSSN-0083: -------------------------------------------------------------------------------- 1 | Keystone policy rule "identity:get_identity_providers" was ignored 2 | --- 3 | 4 | ### Summary ### 5 | A policy rule in Keystone did not behave as intended leading to a less 6 | secure configuration than would be expected. 7 | 8 | ### Affected Services / Software ### 9 | OpenStack Identity Service (Keystone) versions through Mitaka, as well 10 | as Newton (<= 10.0.3), and Ocata (<= 11.0.3). 11 | 12 | ### Discussion ### 13 | Deployments were unaffected by this problem if the default rule was 14 | changed or the "get_identity_providers" rule was manually changed to 15 | be "get_identity_provider" (singular) in keystone's `policy.json`. 16 | 17 | A spelling mistake in the default policy configuration caused these 18 | rules to be ignored. As a result operators that attempted to restrict 19 | this API were unlikely to actually enforce it. 20 | 21 | ### Recommended Actions ### 22 | Update Keystone to a minimum version of 12.0.0.0b3. Additionally, this 23 | fix has been backported to Ocata (11.0.3) and Newton (10.0.3). 24 | 25 | Fix any lingering rules: `identity:get_identity_providers` should 26 | be changed to `identity:get_identity_provider`. 27 | 28 | ### Contacts / References ### 29 | Author: Nick Tait 30 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0083 31 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1703369 32 | Mailing List : [Security] tag on openstack-dev@lists.openstack.org 33 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 34 | -------------------------------------------------------------------------------- /security-notes/OSSN-0084: -------------------------------------------------------------------------------- 1 | Data retained after deletion of a ScaleIO volume 2 | --- 3 | 4 | ### Summary ### 5 | Certain storage volume configurations allow newly created volumes to 6 | contain previous data. This could lead to leakage of sensitive 7 | information between tenants. 8 | 9 | ### Affected Services / Software ### 10 | Cinder releases up to and including Queens with ScaleIO volumes 11 | using thin volumes and zero padding. 12 | 13 | ### Discussion ### 14 | Using both thin volumes and zero padding does not ensure data contained 15 | in a volume is actually deleted. The default volume provisioning rule is 16 | set to thick so most installations are likely not affected. Operators 17 | can check their configuration in `cinder.conf` or check for zero padding 18 | with this command `scli --query_all`. 19 | 20 | #### Recommended Actions #### 21 | 22 | Operators can use the following two workarounds, until the release of 23 | Rocky (planned 30th August 2018) which resolves the issue. 24 | 25 | 1. Swap to thin volumes 26 | 27 | 2. Ensure ScaleIO storage pools use zero-padding with: 28 | 29 | `scli --modify_zero_padding_policy 30 | (((--protection_domain_id | 31 | --protection_domain_name ) 32 | --storage_pool_name ) | --storage_pool_id ) 33 | (--enable_zero_padding | --disable_zero_padding)` 34 | 35 | ### Contacts / References ### 36 | Author: Nick Tait 37 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084 38 | Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573 39 | Mailing List : [Security] tag on openstack-dev@lists.openstack.org 40 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 41 | -------------------------------------------------------------------------------- /security-notes/OSSN-0085: -------------------------------------------------------------------------------- 1 | Cinder configuration option can leak secret key from Ceph backend 2 | --- 3 | 4 | ### Summary ### 5 | This vulnerability is present only when Cinder has a Ceph backend 6 | *and* the ``rbd_keyring_conf`` option in the Cinder configuration 7 | file is set. (The option is unset by default.) Under these 8 | circumstances, the keyring content may be leaked to a regular user. 9 | 10 | ### Affected Services / Software ### 11 | Cinder, Pike, Queens, Rocky, Stein, Train, Ussuri 12 | 13 | ### Discussion ### 14 | When the ``rbd_keyring_conf`` option is set, a user who creates a volume 15 | and then does a local attach of that volume using the Cinder REST API, 16 | may discover the keyring content for the Ceph cluster. (This does not 17 | apply to the normal Nova attach process. The user must contact the 18 | Cinder REST API directly for this exploit.) 19 | 20 | If this user then gains access to the Ceph cluster independently of 21 | Cinder, these credentials may be used to access any volume in the 22 | cluster. 23 | 24 | This issue was reported by Raphael Glon of OVH. 25 | 26 | NOTE: This issue is different from OSSA-2019-003, through which Ceph 27 | credentials could be leaked from the Nova REST API during error 28 | conditions, but we suggest you take this opportunity to review that 29 | security advisory and make sure your system has been updated or patched 30 | to address it: 31 | 32 | https://security.openstack.org/ossa/OSSA-2019-003.html 33 | 34 | ### Recommended Actions ### 35 | Any installation currently using the ``rbd_keyring_conf`` option should 36 | immediately stop using that option. In order for Cinder backups to 37 | continue working, the Ceph keyring secrets should be deployed directly 38 | on cinder-backup hosts in their standard location: 39 | 40 | /etc/ceph/.client..keyring 41 | 42 | The ``rbd_keyring_conf`` is deprecated in the Ussuri release and will 43 | be removed early in the 'V' development cycle. There is no replacement 44 | planned for this functionality. 45 | 46 | ### Contacts / References ### 47 | Author: Brian Rosmaita, Red Hat 48 | This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0085 49 | Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1849624 50 | Mailing List : [Security] tag on openstack-discuss@lists.openstack.org 51 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 52 | -------------------------------------------------------------------------------- /security-notes/OSSN-0091: -------------------------------------------------------------------------------- 1 | BMC emulators developed in OpenStack community do not preserve passwords on VMs 2 | --- 3 | 4 | ### Summary ### 5 | When deploying VirtualBMC or Sushy-Tools in an unsupported, production-like 6 | configuration, it can remove secret data, including VNC passwords, from a 7 | libvirt domain permanently. Operators impacted by this vulnerability must 8 | reconfigure any secret data, including VNC passwords, for the libvirt domain. 9 | 10 | These virtual machine emulators are tools to help emulate a physical machine's 11 | Baseboard Management Controller (BMC) to aid in development and testing of 12 | software that would otherwise require physical machines to perform integration 13 | testing activities. They are not intended or supported for production or 14 | long-term use of any kind. 15 | 16 | ### Affected Services / Software ### 17 | - Sushy-Tools, <=0.21.0 18 | - VirtualBMC, <=2.2.2 19 | 20 | There is no impact to any OpenStack software or services intended for 21 | production use. 22 | 23 | ### Discussion ### 24 | To perform some advanced operations on Libvirt virtual machines, the underlying 25 | XML document describing the virtual machine's domain must be extracted, 26 | modified, and then updated. These specific actions are for aspects such as 27 | "setting a boot device" (VirtualBMC, Sushy-Tools), Setting a boot mode 28 | (Sushy-Tools), and setting a virtual media device (Sushy-Tools). 29 | 30 | This issue is triggered when a VM has any kind of "secure" information defined 31 | in the XML domain definition. If an operator deploys VirtualBMC or Sushy-Tools 32 | to manage one of these libvirt VMs, the first time any action is performed that 33 | requires rewriting of the XML domain definition, all secure information -- 34 | including a VNC console password, if set -- is lost and removed from the domain 35 | definition, leaving the libvirt VM's exposed to a malicious console user. 36 | 37 | ### Recommended Actions ### 38 | Operators who may have been impacted by this vulnerability should immediately 39 | remove use of VirtualBMC and/or Sushy-Tools from their production environment. 40 | Then, validate and if necessary, reconfigure passwords for VNC access or any 41 | other impacted secrets. 42 | 43 | ### Credits ### 44 | Julia Kreger, Red Hat 45 | 46 | ### Contacts / References ### 47 | Author: Jay Faulkner, G-Research Open Source Software 48 | This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0091#Discussion 49 | Original Storyboard bug: https://storyboard.openstack.org/#!/story/2010382 50 | Mailing List : [Security] tag on openstack-discuss@lists.openstack.org 51 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 52 | CVE: CVE-2022-44020 53 | -------------------------------------------------------------------------------- /security-notes/OSSN-0093: -------------------------------------------------------------------------------- 1 | Unsafe Environment Handling in MuranoPL 2 | --- 3 | 4 | ### Summary ### 5 | The Murano service's MuranoPL extension to the YAQL language fails 6 | to sanitize the supplied environment, leading to potential leakage 7 | of sensitive service account information. Murano is an inactive 8 | project, so no fix is currently under development for this 9 | vulnerability. It is strongly recommended that any OpenStack 10 | deployments disable or fully remove Murano, if installed, at the 11 | earliest opportunity. 12 | 13 | ### Affected Services / Software ### 14 | - murano: all versions 15 | 16 | ### Discussion ### 17 | The YAQL interpreter project has released a new major version 18 | (3.0.0) which removes support for format strings, a feature 19 | necessary to exploit this condition in MuranoPL. Because Murano is 20 | not considered under active maintenance in OpenStack, its complete 21 | removal from all deployments is still strongly advised. 22 | 23 | Note that this behavior change in YAQL means configurations relying 24 | on string formatting will no longer be interpreted the same after 25 | upgrading, which could cause them to not work as intended by their 26 | users in services which accept YAQL (including Heat and Mistral). 27 | Reliance on that feature is considered to be unusual, but users 28 | should be made aware in case it negatively impacts their 29 | configuration. 30 | 31 | ### Recommended Actions ### 32 | Disable the Murano service in, or fully remove it from, all 33 | OpenStack deployments at the earliest opportunity. 34 | 35 | ### Credits ### 36 | kirualawliet and Zhiniang Peng (@edwardzpeng) from Sangfor Security 37 | Research Team 38 | 39 | ### Contacts / References ### 40 | Authors: 41 | - Jeremy Stanley, OpenStack Vulnerability Coordinator 42 | This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0093 43 | Original Launchpad bug: https://launchpad.net/bugs/2048114 44 | Mailing List : [security-sig] tag on openstack-discuss@lists.openstack.org 45 | OpenStack Security : https://security.openstack.org/ 46 | CVE: CVE-2024-29156 47 | -------------------------------------------------------------------------------- /security-notes/README.md: -------------------------------------------------------------------------------- 1 | OpenStack Security Notes (OSSN) 2 | =============================== 3 | 4 | The OpenStack Security Group (OSSG) publishes Security Notes to advise users 5 | of security related issues. Security notes are similar to advisories; they 6 | address vulnerabilities in 3rd party tools typically used within OpenStack 7 | deployments and provide guidance on common configuration mistakes that can 8 | result in an insecure operating environment. 9 | 10 | Repository Layout 11 | ----------------- 12 | 13 | This repository contains published Security Notes and templates that should 14 | be used when creating new Security Notes. 15 | 16 | notes - contains Security Notes in e-mail format (see the templates) 17 | templates - contains e-mail and wiki format templates 18 | 19 | Useful Links 20 | ------------ 21 | 22 | A list of published Security Notes is available here: 23 | 24 | https://wiki.openstack.org/wiki/Security_Notes 25 | 26 | The process used to create new Security Notes is available here: 27 | 28 | https://wiki.openstack.org/wiki/Security/Security_Note_Process 29 | -------------------------------------------------------------------------------- /security-notes/template.txt: -------------------------------------------------------------------------------- 1 | Title (single sentence) 2 | --- 3 | 4 | ### Summary ### 5 | A few sentences describing the issue at a high level. 6 | 7 | ### Affected Services / Software ### 8 | A comma separated list of affected services and OpenStack releases. 9 | 10 | ### Discussion ### 11 | A detailed discussion of the problem. This should have enough detail 12 | that the person reading can determine if their deployment is affected, 13 | when the problem was introduced, and what types of attacks/problems that 14 | an affected deployment would be exposed to. 15 | 16 | ### Recommended Actions ### 17 | A detailed description of what can be done to remediate the problem (if 18 | possible). If the recommendation involves configuration changes, 19 | example snippets of configuration files should be included here. 20 | 21 | ### Contacts / References ### 22 | Author: 23 | This OSSN : 24 | Original LaunchPad Bug : 25 | Mailing List : [Security] tag on openstack-discuss@lists.openstack.org 26 | OpenStack Security Project : https://launchpad.net/~openstack-ossg 27 | CVE: 28 | -------------------------------------------------------------------------------- /security-threat-analysis/source/figures/Example_Generated-sequence-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-threat-analysis/source/figures/Example_Generated-sequence-diagram.png -------------------------------------------------------------------------------- /security-threat-analysis/source/figures/Template_Architecture-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-threat-analysis/source/figures/Template_Architecture-diagram.png -------------------------------------------------------------------------------- /security-threat-analysis/source/figures/Template_DFD.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-threat-analysis/source/figures/Template_DFD.png -------------------------------------------------------------------------------- /security-threat-analysis/source/figures/Template_Sequence-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-threat-analysis/source/figures/Template_Sequence-diagram.png -------------------------------------------------------------------------------- /security-threat-analysis/source/figures/arch_diagram.diag: -------------------------------------------------------------------------------- 1 | blockdiag { 2 | 3 | // Set labels and shapes for components 4 | api_access [label = "Api Access", shape = cloud]; 5 | component_1 [label = "Component Name"]; 6 | component_2 [label = "Component Name"]; 7 | multi_component [label = "Component Name (>200)", stacked]; 8 | node_in_cluster [label = "A node in a cluster"]; 9 | future_component [label = "Future component", style = dashed] 10 | db [label = "Database name", shape = flowchart.database] 11 | mq [label = "Message queue", shape = roundedbox] 12 | thirdparty [label = "Database name"] 13 | 14 | 15 | // Define groups 16 | group { 17 | orientation = landscape; 18 | label = "Nova VM Network"; 19 | shape = line; 20 | style = dotted; 21 | 22 | group { 23 | orientation = portrait; 24 | label = "Name of subsystem"; 25 | shape = line; 26 | style = dotted; 27 | 28 | //components 29 | component_1; 30 | component_2; 31 | } 32 | 33 | group { 34 | orientation = portrait; 35 | label = "Name of cluster"; 36 | shape = line; 37 | style = dotted; 38 | 39 | //components 40 | node_in_cluster; 41 | } 42 | } 43 | 44 | group { 45 | orientation = landscape; 46 | label = "Production Network"; 47 | shape = line; 48 | style = dotted; 49 | 50 | //components 51 | multi_component; 52 | future_component; 53 | } 54 | 55 | group { 56 | label = "3rdparty.com"; 57 | shape = line; 58 | style = dashed; 59 | 60 | //components 61 | thirdparty; 62 | } 63 | 64 | //Add the components and draw the lines 65 | api_access -> component_1 [label = "1. Interface label (HTTPS)"]; 66 | component_1 -> component_2 [label = "2. Label (HTTP)"]; 67 | 68 | component_2 -> multi_component [label = "3. Label (HTTPs)"]; 69 | node_in_cluster -> future_component [label = "9. Future Interface", style = dashed]; 70 | node_in_cluster -> thirdparty 71 | db; 72 | mq; 73 | } 74 | -------------------------------------------------------------------------------- /security-threat-analysis/source/figures/arch_diagram.xml: -------------------------------------------------------------------------------- 1 | 7VpNc+I4E/41VM0eQmEcSOYYMp9Vkym2MrX77uktYQvQjm2xshxgfv10yy1b/oAlAVykdjiA3ZJbcj9Pt1otev59vPmo2Gr5IEMe9YaDcNPz3/WGw7eja/hGwZYEAz8XLJQIc5FXCh7FD07CAUkzEfK00lFLGWmxqgoDmSQ80BUZU0quq93mMqqOumILO2IpeAxY1JT+KUK9zKW3w3Ep/8TFYmlH9sZv85YZC74vlMwSGq839OfmkzfHzOoyL+q/BxsqKUENXsWbex6hHa2Ncmt82NFaTFLxhCay/wFowgeeWJTRe95NP4PgLgh4muaNqd5aI8DDYG+4maRLtkJhEMkMdE3WS6H544oFKFwDA0C21HEEdx5c0jBcaU6EaJmqEdE8P3IZc6220IUeGBERiD/eNd2vSzQ8S5alg8SYZIwIsCg0l3aBCzJNu5mIqo6ZvsonBpI/HuDrK9drqb43rPUvNpmLKLqXkVRwn8gErRqydMlxTGw3nCnuIjbj0VSmQguZoOHBbBwenaBRBfD0S62Dljgei8SitfsdNcyk1jI+DUSFrQmj2yZEhT+7EPm24zEYUXxxMWIxB4kETxuk2SzdpprHz0WpRGFQB2gHgFOmwdRoW7DW4Pq1YHc7qvoXRY6Kf1l8XfCGgxOA5zU9bNiHe2MY+H3z6du36W/NeBRCjKZbqfRSLmTCoveltAafgyvfCP0/FPdHdPeXbUlg8k4T3mIbKviba72lxYllWoKoHPeLRNiceIfT2w8HvI3MlKEehipa15hacOp12w6a4hHT4qmq/RgAaGjH/vcyXgGpYboQ4YwnHeM4Lb5yAtL6gxpp7SLhktYS+dSLgtXr2Mx3ODuOYKxJKJ7gcoGXhsOPQOK8BdQ7jeegtr025C25bKhdIbZpOy+1DY+r1PYM5zrgNo3t4GQxSFcssQg0+V7g5HZ7DW5Q5EpduAGlueeOyuelJyUPLj2N6Ah2mkfvlGL4lO2wkiLReV7tmrfQf9hi2Qw8lXDjYDH+J8OtxAS4pa8on7jDtzAcKJpLcrt+0aInEgm/sgxCRV4fx66pcROv+yiDtEvt9KaDguGvHK01R/NvDszRTpFfe+ToDuve4nL3IdOZKqKlg+JntMgcMftPrnierVK4S95NR0ueT/n0iaNyw7zdm/DouHww30mHWxvB1AAKW9gL4yNWAAIb3y4/LSi22V2kBV6ztNSkZBLCAinXpo7E0lQEu7KB2xs3HyizgylXAqaGkbf08B3u/jIO0qxdCu7IWx2r2vzLNaqVPS+BiDdTTBlKUO3iT5jWocqnTs+4hb+amlqlxmq1avLXbah5SbLSrMt4uGw4q8OJdkyY49ScjKfiB5uZDkgIyr6g92jSG71DJQes4LEIQxMfTYowKcq51mHLgu4er6WyNE2mqMtW2We4ttOdrwb94Y0toxNuV6T+paSyXeR8ngK9j4Sawo0D9VTJMAtMxvSrTlqWsm3eVpyFNONyWwgp8r2jAnOz1POQwTnKlUhSzZIyXXN8zd0bvwEhi9FmpgnKf4c66AUsiaNaBt3pTjnP/iqWt8nzwLHw5Vut00TCTnfXbre6kZzhTnPP1vIdgxjM4AirqSKpFn32Mbk4/drChjg08eISYLIQEEzXLTCda3fYcpL4ACeIeKjatPTvGYdOB5paK/m9OHKFt3etanGINws8dO7PI7kOlkzpfigULLf/DwHuHeB0gcjYHlISIiN7VuI6jpWd3HGaZyonLhO1+J9b3PFVOAUstv0AFs7n1X+6rwq9iryhyqZOyz8+6Thnnfc5J2wVPF+4tWup+u7a3J28vNByXv1tKchj8B8Y+D+My0sFaplrt5lAc39xWXVvAyA0Wgz3HiP9CnEHhLgi7HQR4l7pIXjNJYdtf4w6kUvCbfnftLxCUP7Zz3//Ew== -------------------------------------------------------------------------------- /security-threat-analysis/source/figures/library_example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openstack/security-doc/d025f28e5849457082a7134db11932570456a34d/security-threat-analysis/source/figures/library_example.png -------------------------------------------------------------------------------- /security-threat-analysis/source/index.rst: -------------------------------------------------------------------------------- 1 | ================================== 2 | OpenStack Security Threat Analysis 3 | ================================== 4 | 5 | Abstract 6 | ~~~~~~~~ 7 | 8 | This is the index 9 | 10 | Contents 11 | ~~~~~~~~ 12 | 13 | .. toctree:: 14 | :maxdepth: 1 15 | 16 | threat-analysis-process.rst 17 | templates/architecture-page.rst 18 | templates/review-findings.rst 19 | templates/review-notes.rst 20 | architecture-diagram-guidance.rst 21 | todo.rst 22 | 23 | 24 | Search in this guide 25 | ~~~~~~~~~~~~~~~~~~~~ 26 | 27 | * :ref:`search` 28 | -------------------------------------------------------------------------------- /security-threat-analysis/source/templates/review-findings.rst: -------------------------------------------------------------------------------- 1 | ================================= 2 | Security review findings template 3 | ================================= 4 | 5 | security review findings - version/release 6 | ========================================================= 7 | 8 | **Status**: Draft/Completed 9 | 10 | **Release**: Juno/Kilo/Liberty/Newton 11 | 12 | **Version**: 0.01 if applicable 13 | 14 | **Review Date**: mm/dd/yyyy 15 | 16 | **Review Body**: 17 | 18 | **Contacts**: 19 | 20 | - PTL: name - irc handle 21 | 22 | - Architect: name - irc handle 23 | 24 | - Security Reviewer: name - irc handle 25 | 26 | - OpenStack Security Project Reviewer: (only applicable for third party 27 | security reviews) 28 | 29 | 30 | 1. Finding title 31 | ~~~~~~~~~~~~~~~~ 32 | 33 | - Risk: 34 | - Impact: 35 | - Likelihood: 36 | - Impact: 37 | - Overall Risk Rating: 38 | - Bug: 39 | - Recommendation: 40 | - Investigation Results: 44 | 45 | 46 | 2. Finding title 47 | ~~~~~~~~~~~~~~~~ 48 | 49 | - Risk: 50 | - Impact: 51 | - Likelihood: 52 | - Impact: 53 | - Overall Risk Rating: 54 | - Bug: 55 | - Recommendation: 56 | - Investigation Results: 60 | 61 | 62 | 3. Finding title 63 | ~~~~~~~~~~~~~~~~ 64 | 65 | - Risk: 66 | - Impact: 67 | - Likelihood: 68 | - Impact: 69 | - Overall Risk Rating: 70 | - Bug: 71 | - Recommendation: 72 | - Investigation Results: 76 | -------------------------------------------------------------------------------- /security-threat-analysis/source/templates/review-notes.rst: -------------------------------------------------------------------------------- 1 | ============================== 2 | Security review notes template 3 | ============================== 4 | 5 | security review notes - 6 | ======================================================== 7 | 8 | **Status**: Draft/Completed 9 | 10 | **Release**: Juno/Kilo/Liberty/Newton 11 | 12 | **Version**: 0.01 if applicable 13 | 14 | **Review Date**: mm/dd/yyyy 15 | 16 | **Review Body**: 17 | 18 | **Contacts**: 19 | 20 | - PTL: name - irc handle 21 | 22 | - Architect: name - irc handle 23 | 24 | - Security Reviewer: name - irc handle 25 | 26 | **Reviewers**: 27 | 28 | - : 29 | - : 30 | - OpenStack Security Project: (only applicable for 31 | third party reviews) 32 | 33 | 34 | Review 35 | ~~~~~~ 36 | 37 | 38 | Abuse cases 39 | ----------- 40 | 41 | - 42 | - 43 | 44 | 45 | Architectural diagram walkthrough 46 | --------------------------------- 47 | 48 | - notes 49 | 50 | 51 | Sequence/DFD diagram walkthrough 52 | -------------------------------- 53 | 54 | - notes 55 | 56 | 57 | Actions 58 | ------- 59 | 60 | 1. action 1 61 | 2. action 2 62 | -------------------------------------------------------------------------------- /security-threat-analysis/source/todo.rst: -------------------------------------------------------------------------------- 1 | ==================== 2 | Threat Analysis Todo 3 | ==================== 4 | 5 | Needed 6 | ~~~~~~ 7 | 8 | 9 | #. page saying what TAs have been done, and haven't. 10 | #. Etherpad template for review tracking 11 | #. process 12 | #. Improve documentation around context for OpenStack deployments, namely that 13 | they reflect best practice, and the documentation should explain what to do 14 | when things can be changed. 15 | #. Add information on filling in interfaces table from diagram. 16 | #. Remove U-C, O-C, I-C guidance 17 | #. Add guidance that explains the importance of paying special attention to 18 | interfaces that cross trust boundaries 19 | #. Reviewer to build sequence diagrams in real time during the review 20 | #. Document how we assess a third party review to be in line with our key 21 | security assertions. I think perhaps we need a mapping table or something. 22 | #. Should we prioritise assets. 23 | #. Data assets should be listed in the architecture page before the review. 24 | #. Figure out how to protect etherpad contents while retaining ability to share 25 | and collaboratively edit it. 26 | #. Add 'review CIA for data assets to process' 27 | #. change 'review CIA for each interface' to ' 'review CIA for each interface 28 | that crosses a security domain or each interface that doesn't use TLS' 29 | #. Best practice for each type of asset connection 30 | #. Document what a trust boundary is 31 | #. Document what an asset is. Config file? elements within a config file? 32 | #. Document what level of detail we want for external dependencies and give 33 | examples. 34 | -------------------------------------------------------------------------------- /test-requirements.txt: -------------------------------------------------------------------------------- 1 | # The order of packages is significant, because pip processes them in the order 2 | # of appearance. Changing the order has an impact on the overall integration 3 | # process, which may cause wedges in the gate later. 4 | 5 | doc8 # Apache-2.0 6 | openstack-doc-tools>=2.0.0 # Apache-2.0 7 | sphinx>=2.0.0,!=2.1.0 # BSD 8 | openstackdocstheme>=2.1.1 # Apache-2.0 9 | 10 | # For translations 11 | Babel>=2.3.4,!=2.4.0 # BSD 12 | -------------------------------------------------------------------------------- /tools/build-all-rst.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash -e 2 | 3 | mkdir -p publish-docs/html 4 | 5 | # This marker is needed for infra publishing 6 | MARKER_TEXT="Project: $ZUUL_PROJECT Ref: $ZUUL_REFNAME Build: $ZUUL_UUID Revision: $ZUUL_NEWREV" 7 | 8 | doc-tools-build-rst security-guide --build build \ 9 | --target security-guide 10 | echo $MARKER_TEXT > publish-docs/html/security-guide/.root-marker 11 | doc-tools-build-rst security-threat-analysis --build build \ 12 | --target security-threat-analysis 13 | echo $MARKER_TEXT > publish-docs/html/security-threat-analysis/.root-marker 14 | -------------------------------------------------------------------------------- /tools/generatepot-rst.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash -xe 2 | 3 | # 4 | # Licensed under the Apache License, Version 2.0 (the "License"); you may 5 | # not use this file except in compliance with the License. You may obtain 6 | # a copy of the License at 7 | # 8 | # http://www.apache.org/licenses/LICENSE-2.0 9 | # 10 | # Unless required by applicable law or agreed to in writing, software 11 | # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT 12 | # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the 13 | # License for the specific language governing permissions and limitations 14 | # under the License. 15 | 16 | DOCNAME=$1 17 | 18 | if [ -z "$DOCNAME" ] ; then 19 | echo "usage $0 DOCNAME" 20 | exit 1 21 | fi 22 | 23 | # We're not doing anything for this directory. 24 | if [[ "$DOCNAME" = "common" ]] ; then 25 | exit 0 26 | fi 27 | 28 | rm -f $DOCNAME/source/locale/$DOCNAME.pot 29 | sphinx-build -b gettext $DOCNAME/source/ $DOCNAME/source/locale/ 30 | 31 | # common is translated as part of openstack-manuals, do not 32 | # include the file in the combined tree. 33 | rm $DOCNAME/source/locale/common.pot 34 | 35 | # Take care of deleting all temporary files so that git add 36 | # doc/$DOCNAME/source/locale will only add the single pot file. 37 | msgcat --sort-by-file $DOCNAME/source/locale/*.pot \ 38 | > $DOCNAME/source/$DOCNAME.pot 39 | rm $DOCNAME/source/locale/*.pot 40 | rm -rf $DOCNAME/source/locale/.doctrees/ 41 | mv $DOCNAME/source/$DOCNAME.pot $DOCNAME/source/locale/$DOCNAME.pot 42 | -------------------------------------------------------------------------------- /tox.ini: -------------------------------------------------------------------------------- 1 | [tox] 2 | minversion = 1.6 3 | envlist = linters,publishdocs 4 | skipsdist = True 5 | 6 | [testenv] 7 | basepython = python3 8 | setenv = 9 | VIRTUAL_ENV={envdir} 10 | deps = -r{toxinidir}/test-requirements.txt 11 | allowlist_externals = 12 | bash 13 | cp 14 | mkdir 15 | rm 16 | sed 17 | 18 | [testenv:venv] 19 | commands = {posargs} 20 | 21 | [testenv:linters] 22 | commands = 23 | doc8 -e '' security-notes 24 | doc8 -e '' security-guide 25 | doc8 -e '' security-threat-analysis 26 | 27 | [testenv:publishdocs] 28 | allowlist_externals = {toxinidir}/tools/build-all-rst.sh 29 | # Prepare all documents so that they can get published on 30 | # docs.openstack.org with just copying publish-docs/* over. 31 | commands = 32 | # Build and copy RST Guides 33 | {toxinidir}/tools/build-all-rst.sh 34 | 35 | [testenv:buildlang] 36 | # Run as "tox -e buildlang -- $LANG" 37 | allowlist_externals = 38 | doc-tools-check-languages 39 | bash 40 | commands = 41 | doc-tools-check-languages doc-tools-check-languages.conf test {posargs} 42 | 43 | [testenv:publishlang] 44 | allowlist_externals = doc-tools-check-languages 45 | commands = doc-tools-check-languages doc-tools-check-languages.conf test all 46 | 47 | [testenv:docs] 48 | allowlist_externals = {toxinidir}/tools/build-all-rst.sh 49 | commands = 50 | # Build and copy RST Guides 51 | {toxinidir}/tools/build-all-rst.sh 52 | 53 | [testenv:generatepot-rst] 54 | # Generate POT files for translation, needs {posargs} like: 55 | # tox -e generatepot-rst -- security-guide 56 | commands = {toxinidir}/tools/generatepot-rst.sh {posargs} 57 | 58 | [doc8] 59 | # Settings for doc8: 60 | # These files have extra long lines that cannot be avoided, let's ignore them. 61 | ignore-path = security-notes/OSSN-0047,security-notes/OSSN-0068,common,security-guide/build,security-threat-analysis/build 62 | # File extensions to use 63 | extensions = .rst,.txt 64 | --------------------------------------------------------------------------------