openstack/openstack-manuals
Code Issues Proposed changes

Replace tabs with spaces

Browse Source 
Replace tabs with spaces in files

Change-Id: I058657fa8d294210502c647b2612e139d079b440
This commit is contained in:
Andreas Jaeger 2013-12-26 22:18:52 +01:00
parent a02a29af61
commit e127b409d2
8 changed files with 42 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
doc/common/section_nova_cli_metadata.xml
View File

@ -19,30 +19,30 @@
included on the <literal>metadata</literal> line:
<screen><prompt>$</prompt> <userinput>nova show smallimage2</userinput>
<computeroutput>+------------------------+---------------------------------------------------------------+
| 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 |
+------------------------+---------------------------------------------------------------+</computeroutput></screen>
</para>
</section>

10
doc/glossary/openstack-glossary.xml
View File

@ -8,14 +8,14 @@
xml:id="openstack-glossary">
<title>OpenStack Glossary</title>
<!-- <?dbhtml stop-chunking?> -->
<chapter xml:id="glossary">
<title>OpenStack Glossary</title>
<para>Use this glossary to get definitions of OpenStack-related
<chapter xml:id="glossary">
<title>OpenStack Glossary</title>
<para>Use this glossary to get definitions of OpenStack-related
words and phrases.</para>
<para>To add to this glossary, fork the
<literal>openstack-manuals</literal> repository on
github.com and update the source files through the
OpenStack contribution process.</para>
<xi:include href="glossary-terms.xml"/>
</chapter>
<xi:include href="glossary-terms.xml"/>
</chapter>
</book>

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

@ -73,7 +73,7 @@
<para>The Compute Service facilitates this management through an abstraction layer that interfaces with supported hypervisors, which we address later on in more detail.</para>
<para>Later in the guide, we focus generically on the
virtualization stack as it relates to hypervisors.</para>
<para>For information about the current state of feature support, see
<para>For information about the current state of feature support, see
<link
xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
>OpenStack Hypervisor Support Matrix</link>.</para>

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

@ -28,10 +28,10 @@
<para>Authentication and authorization policy in OpenStack may be delegated to an external LDAP server. A typical use case is an organization that seeks to deploy a private cloud and already has a database of employees, the users. This may be in an LDAP system. Using LDAP as a source of authority authentication, requests to Identity Service are delegated to the LDAP service, which will authorize or deny requests based on locally set policies. A token is generated on successful authentication.</para>
<para>Note that if the LDAP system has attributes defined for the user such as admin, finance, HR etc, these must be mapped into roles and groups within Identity for use by the various OpenStack services. The <emphasis>etc/keystone.conf</emphasis> file provides the mapping from the LDAP attributes to Identity attributes.</para>
<para>The Identity Service <emphasis role="bold">MUST NOT</emphasis> be allowed to write to LDAP services used for authentication outside of the OpenStack deployment as this would allow a sufficiently privileged keystone user to make changes to the LDAP directory. This would allow privilege escalation within the wider organization or facilitate unauthorized access to other information and resources. In such a deployment, user provisioning would be out of the realm of the OpenStack deployment.</para>
<note>
<note>
<para>There is an <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1168252">OpenStack Security Note (OSSN) regarding keystone.conf permissions</link>.</para>
<para>There is an <link xlink:href="https://bugs.launchpad.net/ossn/+bug/1155566">OpenStack Security Note (OSSN) regarding potential DoS attacks</link>.</para>
</note>
</note>
</section>
<section xml:id="ch024_authentication-idp251520">
<title>External Authentication Methods</title>
@ -79,7 +79,7 @@
<para>Each OpenStack service has a policy file in json format, called <emphasis role="bold">policy.json</emphasis>. The policy file specifies rules, and the rule that governs each resource. A resource could be API access, the ability to attach to a volume, or to fire up instances.</para>
<para>The policies can be updated by the cloud administrator to further control access to the various resources. The middleware could also be further customized. Note that your users must be assigned to groups/roles that you refer to in your policies.</para>
<para>Below is a snippet of the Block Storage service policy.json file.</para>
<screen> 
<screen>
{
"context_is_admin": [["role:admin"]],
"admin_or_owner": [["is_admin:True"], ["project_id:%(project_id)s"]],

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

@ -54,7 +54,7 @@
</listitem>
</itemizedlist>
<para>For additional information see the <link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html">Networking chapter</link> in the
<citetitle>OpenStack Cloud Administrator Guide</citetitle>.</para>
<citetitle>OpenStack Cloud Administrator Guide</citetitle>.</para>
</section>
</section>
</chapter>

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

@ -14,7 +14,7 @@
</listitem>
</itemizedlist>
<note>
<para>The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
<para>The IOMMU feature is marketed as VT-d by Intel and AMD-Vi by AMD.</para>
</note>
<para>A hardware infection occurs when an instance makes a malicious modification to the firmware or some other part of a device. As this device is used by other instances, or even the host OS, the malicious code can spread into these systems. The end result is that one instance can run code outside of its security domain. This is a potential problem in any hardware sharing scenario. The problem is specific to this scenario because it is harder to reset the state of physical hardware than virtual hardware.</para>
<para>Solutions to the hardware infection problem are domain specific. The strategy is to identify how an instance can modify hardware state then determine how to reset any modifications when the instance is done using the hardware. For example, one option could be to re-flash the firmware after use. Clearly there is a need to balance hardware longevity with security as some firmwares will fail after a large number of writes. TPM technology, described in <literal>link:Management/Node Bootstrapping</literal>, provides a solution for detecting unauthorized firmware changes. Regardless of the strategy selected, it is important to understand the risks associated with this kind of hardware sharing so that they can be properly mitigated for a given deployment scenario.</para>
@ -42,7 +42,7 @@
<section xml:id="ch052_devices-idp490976">
<title>Minimizing the Qemu Codebase</title>
<para>One classic security principle is to remove any unused components from your system. QEMU provides support for many different virtual hardware devices. However, only a small number of devices are needed for a given instance. Most instances will use the virtio devices. However, some legacy instances will need access to specific hardware, which can be specified using glance metadata:</para>
<screen> 
<screen>
glance image-update \
    --property hw_disk_bus=ide \
    --property hw_cdrom_bus=ide \
@ -71,7 +71,7 @@ glance image-update \
</listitem>
</itemizedlist>
<para>Putting this all together, and adding in some additional useful protections, we recommend the following compiler options for gcc when compiling QEMU:</para>
<screen> 
<screen>
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"</screen>
<para>We recommend testing your QEMU executable file after it is compiled to ensure that the compiler hardening worked properly.</para>
<para>Most cloud deployments will not want to build software such as QEMU by hand. It is better to use packaging to ensure that the process is repeatable and to ensure that the end result can be easily deployed throughout the cloud. The references below provide some additional details on applying compiler hardening options to existing packages.</para>
@ -120,7 +120,7 @@ CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector --param ssp-buffer-
<section xml:id="ch052_devices-idp523744">
<title>Labels and Categories</title>
<para>KVM-based virtual machine instances are labelled with their own SELinux data type, known as svirt_image_t. Kernel level protections prevent unauthorized system processes, such as malware, from manipulating the virtual machine image files on disk. When virtual machines are powered off, images are stored as svirt_image_t as shown below:</para>
<screen> 
<screen>
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

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

@ -9,7 +9,7 @@
<section xml:id="ch064_certifications-compliance-statements-idp47472">
<title>SOC 1 (SSAE 16) / ISAE 3402</title>
<para>Service Organization Controls (SOC) criteria are defined
by the <link xlink:href="http://www.aicpa.org/">American Institute of Certified Public Accountants</link> (AICPA). SOC controls assess relevant financial statements and assertions of a service provider, such as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing Standards No. 70 (SAS 70) Type II report. These controls commonly include physical data centers in scope.</para>
by the <link xlink:href="http://www.aicpa.org/">American Institute of Certified Public Accountants</link> (AICPA). SOC controls assess relevant financial statements and assertions of a service provider, such as compliance with the Sarbanes-Oxley Act. SOC 1 is a replacement for Statement on Auditing Standards No. 70 (SAS 70) Type II report. These controls commonly include physical data centers in scope.</para>
<para>There are two types of SOC 1 reports:</para>
<itemizedlist><listitem>
<para>Type 1 – report on the fairness of the presentation of management’s description of the service organization’s system and the suitability of the design of the controls to achieve the related control objectives included in the description as of a specified date.</para>

6
doc/training-guides/sources/cinder/threading.xml
View File

@ -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)
</para>
</section>
<section xml:id="MySQL-access-and-eventlet">