diff --git a/doc/common/section_nova_cli_metadata.xml b/doc/common/section_nova_cli_metadata.xml index 2cd6f170f1..10eccf6353 100644 --- a/doc/common/section_nova_cli_metadata.xml +++ b/doc/common/section_nova_cli_metadata.xml @@ -19,30 +19,30 @@ included on the metadata line: $ nova show smallimage2 +------------------------+---------------------------------------------------------------+ -| Property | Value | +| Property | Value | +------------------------+---------------------------------------------------------------+ -| OS-DCF:diskConfig | MANUAL | -| OS-EXT-STS:power_state | 1 | -| OS-EXT-STS:task_state | None | -| OS-EXT-STS:vm_state | active | -| accessIPv4 | | -| accessIPv6 | | -| config_drive | | -| created | 2012-05-16T20:48:23Z | -| flavor | m1.small | -| hostId | de0c201e62be88c61aeb52f51d91e147acf6cf2012bb57892e528487 | -| id | 8ec95524-7f43-4cce-a754-d3e5075bf915 | -| image | natty-image | -| key_name | | -| metadata | {u'description': u'Small test image', u'creator': u'joecool'} | -| name | smallimage2 | -| private network | 172.16.101.11 | -| progress | 0 | -| public network | 10.4.113.11 | -| status | ACTIVE | -| tenant_id | e830c2fbb7aa4586adf16d61c9b7e482 | -| updated | 2012-05-16T20:48:35Z | -| user_id | de3f4e99637743c7b6d27faca4b800a9 | +| OS-DCF:diskConfig | MANUAL | +| OS-EXT-STS:power_state | 1 | +| OS-EXT-STS:task_state | None | +| OS-EXT-STS:vm_state | active | +| accessIPv4 | | +| accessIPv6 | | +| config_drive | | +| created | 2012-05-16T20:48:23Z | +| flavor | m1.small | +| hostId | de0c201e62be88c61aeb52f51d91e147acf6cf2012bb57892e528487 | +| id | 8ec95524-7f43-4cce-a754-d3e5075bf915 | +| image | natty-image | +| key_name | | +| metadata | {u'description': u'Small test image', u'creator': u'joecool'} | +| name | smallimage2 | +| private network | 172.16.101.11 | +| progress | 0 | +| public network | 10.4.113.11 | +| status | ACTIVE | +| tenant_id | e830c2fbb7aa4586adf16d61c9b7e482 | +| updated | 2012-05-16T20:48:35Z | +| user_id | de3f4e99637743c7b6d27faca4b800a9 | +------------------------+---------------------------------------------------------------+ diff --git a/doc/glossary/openstack-glossary.xml b/doc/glossary/openstack-glossary.xml index 21c6ba60c0..927c6cdb0c 100644 --- a/doc/glossary/openstack-glossary.xml +++ b/doc/glossary/openstack-glossary.xml @@ -8,14 +8,14 @@ xml:id="openstack-glossary"> OpenStack Glossary - - OpenStack Glossary - Use this glossary to get definitions of OpenStack-related + + OpenStack Glossary + Use this glossary to get definitions of OpenStack-related words and phrases. To add to this glossary, fork the openstack-manuals repository on github.com and update the source files through the OpenStack contribution process. - - + + diff --git a/doc/security-guide/ch004_book-introduction.xml b/doc/security-guide/ch004_book-introduction.xml index 43ec2423c3..c8eeaf1387 100644 --- a/doc/security-guide/ch004_book-introduction.xml +++ b/doc/security-guide/ch004_book-introduction.xml @@ -73,7 +73,7 @@ The Compute Service facilitates this management through an abstraction layer that interfaces with supported hypervisors, which we address later on in more detail. Later in the guide, we focus generically on the virtualization stack as it relates to hypervisors. - For information about the current state of feature support, see + For information about the current state of feature support, see OpenStack Hypervisor Support Matrix. diff --git a/doc/security-guide/ch024_authentication.xml b/doc/security-guide/ch024_authentication.xml index bb1a8d1c1f..96488151cb 100644 --- a/doc/security-guide/ch024_authentication.xml +++ b/doc/security-guide/ch024_authentication.xml @@ -28,10 +28,10 @@ Authentication and authorization policy in OpenStack may be delegated to an external LDAP server. A typical use case is an organization that seeks to deploy a private cloud and already has a database of employees, the users. This may be in an LDAP system. Using LDAP as a source of authority authentication, requests to Identity Service are delegated to the LDAP service, which will authorize or deny requests based on locally set policies. A token is generated on successful authentication. Note that if the LDAP system has attributes defined for the user such as admin, finance, HR etc, these must be mapped into roles and groups within Identity for use by the various OpenStack services. The etc/keystone.conf file provides the mapping from the LDAP attributes to Identity attributes. The Identity Service MUST NOT be allowed to write to LDAP services used for authentication outside of the OpenStack deployment as this would allow a sufficiently privileged keystone user to make changes to the LDAP directory. This would allow privilege escalation within the wider organization or facilitate unauthorized access to other information and resources. In such a deployment, user provisioning would be out of the realm of the OpenStack deployment. - + There is an OpenStack Security Note (OSSN) regarding keystone.conf permissions. There is an OpenStack Security Note (OSSN) regarding potential DoS attacks. - +
External Authentication Methods @@ -79,7 +79,7 @@ Each OpenStack service has a policy file in json format, called policy.json. The policy file specifies rules, and the rule that governs each resource. A resource could be API access, the ability to attach to a volume, or to fire up instances. The policies can be updated by the cloud administrator to further control access to the various resources. The middleware could also be further customized. Note that your users must be assigned to groups/roles that you refer to in your policies. Below is a snippet of the Block Storage service policy.json file. -   + { "context_is_admin": [["role:admin"]], "admin_or_owner": [["is_admin:True"], ["project_id:%(project_id)s"]], diff --git a/doc/security-guide/ch031_neutron-architecture.xml b/doc/security-guide/ch031_neutron-architecture.xml index 1059a81d77..179ea4de95 100644 --- a/doc/security-guide/ch031_neutron-architecture.xml +++ b/doc/security-guide/ch031_neutron-architecture.xml @@ -54,7 +54,7 @@ For additional information see the Networking chapter in the - OpenStack Cloud Administrator Guide. + OpenStack Cloud Administrator Guide.
diff --git a/doc/security-guide/ch052_devices.xml b/doc/security-guide/ch052_devices.xml index fa98bceafc..5cb3c7d5e0 100644 --- a/doc/security-guide/ch052_devices.xml +++ b/doc/security-guide/ch052_devices.xml @@ -14,7 +14,7 @@ - The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD. + The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD. A hardware infection occurs when an instance makes a malicious modification to the firmware or some other part of a device. As this device is used by other instances, or even the host OS, the malicious code can spread into these systems. The end result is that one instance can run code outside of its security domain. This is a potential problem in any hardware sharing scenario. The problem is specific to this scenario because it is harder to reset the state of physical hardware than virtual hardware. Solutions to the hardware infection problem are domain specific. The strategy is to identify how an instance can modify hardware state then determine how to reset any modifications when the instance is done using the hardware. For example, one option could be to re-flash the firmware after use. Clearly there is a need to balance hardware longevity with security as some firmwares will fail after a large number of writes. TPM technology, described in link:Management/Node Bootstrapping, provides a solution for detecting unauthorized firmware changes. Regardless of the strategy selected, it is important to understand the risks associated with this kind of hardware sharing so that they can be properly mitigated for a given deployment scenario. @@ -42,7 +42,7 @@
Minimizing the Qemu Codebase One classic security principle is to remove any unused components from your system. QEMU provides support for many different virtual hardware devices. However, only a small number of devices are needed for a given instance. Most instances will use the virtio devices. However, some legacy instances will need access to specific hardware, which can be specified using glance metadata: -   + glance image-update \     --property hw_disk_bus=ide \     --property hw_cdrom_bus=ide \ @@ -71,7 +71,7 @@ glance image-update \ Putting this all together, and adding in some additional useful protections, we recommend the following compiler options for gcc when compiling QEMU: -   + CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=4 -pie -fPIE -ftrapv -­D_FORTIFY_SOURCE=2 ­O2 -Wl,-z,relro,-z,now" We recommend testing your QEMU executable file after it is compiled to ensure that the compiler hardening worked properly. Most cloud deployments will not want to build software such as QEMU by hand. It is better to use packaging to ensure that the process is repeatable and to ensure that the end result can be easily deployed throughout the cloud. The references below provide some additional details on applying compiler hardening options to existing packages. @@ -120,7 +120,7 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-
Labels and Categories KVM-based virtual machine instances are labelled with their own SELinux data type, known as svirt_image_t. Kernel level protections prevent unauthorized system processes, such as malware, from manipulating the virtual machine image files on disk. When virtual machines are powered off, images are stored as svirt_image_t as shown below: -   + system_u:object_r:svirt_image_t:SystemLow image1 system_u:object_r:svirt_image_t:SystemLow image2 system_u:object_r:svirt_image_t:SystemLow image3 diff --git a/doc/security-guide/ch064_certifications-compliance-statements.xml b/doc/security-guide/ch064_certifications-compliance-statements.xml index d9b9377b24..94af98930c 100644 --- a/doc/security-guide/ch064_certifications-compliance-statements.xml +++ b/doc/security-guide/ch064_certifications-compliance-statements.xml @@ -9,7 +9,7 @@
SOC 1 (SSAE 16) / ISAE 3402 Service Organization Controls (SOC) criteria are defined - by the American Institute of Certified Public Accountants (AICPA). SOC controls assess relevant financial statements and assertions of a service provider, such as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing Standards No. 70 (SAS 70) Type II report. These controls commonly include physical data centers in scope. + by the American Institute of Certified Public Accountants (AICPA). SOC controls assess relevant financial statements and assertions of a service provider, such as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing Standards No. 70 (SAS 70) Type II report. These controls commonly include physical data centers in scope. There are two types of SOC 1 reports: Type 1 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date. diff --git a/doc/training-guides/sources/cinder/threading.xml b/doc/training-guides/sources/cinder/threading.xml index 3b3e7ad9f1..6023beac92 100644 --- a/doc/training-guides/sources/cinder/threading.xml +++ b/doc/training-guides/sources/cinder/threading.xml @@ -41,9 +41,9 @@ This scenario can be avoided by adding calls to the eventlet sleep method in the long-running code path. The sleep call will trigger a context switch if there are pending threads, and using an argument of 0 will avoid introducing delays in the case that there is only a single green thread:: - from eventlet import greenthread - ... - greenthread.sleep(0) + from eventlet import greenthread + ... + greenthread.sleep(0)
@@ -62,4 +62,4 @@ a discussion of the `impact on performance`_. .. _mailing list thread: https://lists.launchpad.net/openstack/msg08118.html
-
\ No newline at end of file +