Glossary terms mark ups are added for few terms

In this patch glossary term mark-ups are added for few
terms which are helpful for readers

Change-Id: I239f361c6908b366e3b3d0760ab68f627f7b1cea

security-guide/source/compliance/overview.rst

@@ -16,10 +16,10 @@ Identify where risks exist in a cloud architecture and apply controls
 to mitigate the risks. In areas of significant concern, layered
 defenses provide multiple complementary controls to manage risk down to
 an acceptable level. For example, to ensure adequate isolation between
-cloud tenants, we recommend hardening QEMU, using a hypervisor with
-SELinux support, enforcing mandatory access control policies, and
-reducing the overall attack surface. The foundational principle is to
-harden an area of concern with multiple layers of defense such that if
+cloud tenants, we recommend hardening :term:`QEMU <Quick EMUlator (QEMU)>`,
+using a hypervisor with SELinux support, enforcing mandatory access control
+policies, and reducing the overall attack surface. The foundational principle
+is to harden an area of concern with multiple layers of defense such that if
 any one layer is compromised, other layers will exist to offer
 protection and minimize exposure.
 

security-guide/source/compute/hardening-the-virtualization-layers.rst

@@ -69,14 +69,14 @@ provides the hardware interface for the virtual machine. Instances use this
 functionality to provide network, storage, video, and other devices that may be
 needed. With this in mind, most instances in your environment will exclusively
 use virtual hardware, with a minority that will require direct hardware access.
-The major open source hypervisors use QEMU for this functionality. While QEMU
-fills an important need for virtualization platforms, it has proven to be a
-very challenging software project to write and maintain. Much of the
-functionality in QEMU is implemented with low-level code that is difficult for
-most developers to comprehend. Furthermore, the hardware virtualized by QEMU
-includes many legacy devices that have their own set of quirks. Putting all of
-this together, QEMU has been the source of many security problems, including
-hypervisor breakout attacks.
+The major open source hypervisors use :term:`QEMU <Quick EMUlator (QEMU)>` for
+this functionality. While QEMU fills an important need for virtualization
+platforms, it has proven to be a very challenging software project to write
+and maintain. Much of the functionality in QEMU is implemented with low-level
+code that is difficult for most developers to comprehend. Furthermore, the
+hardware virtualized by QEMU includes many legacy devices that have their own
+set of quirks. Putting all of this together, QEMU has been the source of many
+security problems, including hypervisor breakout attacks.
 
 Therefore, it is important to take proactive steps to harden QEMU. Three
 specific steps are recommended: minimizing the code base, using compiler

security-guide/source/compute/hypervisor-selection.rst

@@ -13,9 +13,9 @@ OpenStack-supported hypervisor technologies, there are significant differences
 in the security architecture and features for each hypervisor, particularly
 when considering the security threat vectors which are unique to elastic
 OpenStack environments. As applications consolidate into single
-Infrastructure-as-a-Service (IaaS) platforms, instance isolation at the
-hypervisor level becomes paramount. The requirement for secure isolation holds
-true across commercial, government, and military communities.
+Infrastructure-as-a-Service (:term:`IaaS`) platforms, instance isolation at
+the hypervisor level becomes paramount. The requirement for secure isolation
+holds true across commercial, government, and military communities.
 
 Within the OpenStack framework, you can choose among many hypervisor platforms
 and corresponding OpenStack plug-ins to optimize your cloud environment. In the

security-guide/source/data-processing/deployment.rst

@@ -54,7 +54,7 @@ One of the primary tasks of the data processing controller is to
 communicate with the instances it spawns. These instances are
 provisioned and then configured depending on the framework being
 used. The communication between the controller and the instances uses
-secure shell (SSH) and HTTP protocols.
+:term:`secure shell (SSH)` and HTTP protocols.
 
 When provisioning clusters each instance will be given an IP address in
 the networks provided by the user. The first network is often referred

security-guide/source/introduction/introduction-to-openstack.rst

@@ -154,12 +154,13 @@ storage.
 Shared File Systems
 -------------------
 
-The Shared File Systems service (manila) provides a set of services for
-management of shared file systems in a multi-tenant cloud environment, similar
-to how OpenStack provides for block-based storage management through the
-OpenStack Block Storage service project. With the Shared File Systems service,
-you can create a remote file system, mount the file system on your instances,
-and then read and write data from your instances to and from your file system.
+The :term:`Shared File Systems service` (manila) provides a set of services
+for management of shared file systems in a multi-tenant cloud environment,
+similar to how OpenStack provides for block-based storage management through
+the OpenStack Block Storage service project. With the Shared File Systems
+service, you can create a remote file system, mount the file system on your
+instances, and then read and write data from your instances to and from your
+file system.
 
 Networking
 ----------
@@ -187,8 +188,8 @@ security concerns of public web portals.
 Identity service
 ----------------
 
-The OpenStack Identity service (keystone) is a **shared service** that provides
-authentication and authorization services throughout the entire cloud
+The OpenStack :term:`Identity` service (keystone) is a **shared service** that
+provides authentication and authorization services throughout the entire cloud
 infrastructure. The Identity service has pluggable support for multiple forms
 of authentication.
 
@@ -198,9 +199,9 @@ authorization tokens, and secure communication.
 Image service
 -------------
 
-The OpenStack Image service (glance) provides disk image management services.
-The Image service provides image discovery, registration, and delivery services
-to the Compute service, as needed.
+The OpenStack :term:`Image service` (glance) provides disk image management
+services. The Image service provides image discovery, registration, and
+delivery services to the Compute service, as needed.
 
 Trusted processes for managing the life cycle of disk images are required, as
 are all the previously mentioned issues with respect to data security.
@@ -208,9 +209,9 @@ are all the previously mentioned issues with respect to data security.
 Data processing service
 -----------------------
 
-The Data processing service for OpenStack (sahara) provides a platform for the
-provisioning, management, and usage of clusters running popular processing
-frameworks.
+The :term:`Data processing service` for OpenStack (sahara) provides a platform
+for the provisioning, management, and usage of clusters running popular
+processing frameworks.
 
 Security considerations for data processing should focus on data privacy and
 secure communications to provisioned clusters.
@@ -218,11 +219,11 @@ secure communications to provisioned clusters.
 Other supporting technology
 ---------------------------
 
-OpenStack relies on messaging for internal communication between several of its
-services. By default, OpenStack uses message queues based on the Advanced
-Message Queue Protocol (AMQP). Similar to most OpenStack services, it supports
-pluggable components. Today the implementation back end could be RabbitMQ,
-Qpid, or ZeroMQ.
+OpenStack relies on messaging for internal communication between several of
+its services. By default, OpenStack uses message queues based on the
+:term:`Advanced Message Queue Protocol (AMQP)`. Similar to most OpenStack
+services, it supports pluggable components. Today the implementation back end
+could be RabbitMQ, Qpid, or ZeroMQ.
 
 As most management commands flow through the message queuing system, it is a
 primary security concern for any OpenStack deployment. Message queuing security

security-guide/source/introduction/why-and-how-we-wrote-this-book.rst

@@ -179,4 +179,4 @@ The initial work on this book was conducted in an overly air-conditioned room
 that served as our group office for the entirety of the documentation sprint.
 
 Learn more about how to contribute to the OpenStack docs:
-http://wiki.openstack.org/Documentation/HowTo.
+http://docs.openstack.org/contributor-guide/index.html.

security-guide/source/management/management-interfaces.rst

@@ -13,7 +13,7 @@ tenants:
 
 -  OpenStack API
 
--  Secure shell (SSH)
+-  :term:`Secure shell (SSH)<secure shell (SSH)>`
 
 -  OpenStack management utilities such as nova-manage and glance-manage
 

security-guide/source/shared-file-systems.rst

@@ -12,7 +12,9 @@ and then read and write data from your instances to and from your file system.
 A large amount of existing software is designed around file-based storage. The
 Shared File Systems service provides the management of file shares and works
 with various storage providers that use following shared file system protocols:
-NFS, CIFS, GlusterFS, and HDFS.
+:term:`NFS <Network File System (NFS)>`,
+:term:`CIFS <Common Internet File System (CIFS)>`, :term:`GlusterFS`, and
+:term:`HDFS <Hadoop Distributed File System (HDFS)>`.
 
 The Shared File Systems serves the same purpose as the Amazon Elastic File
 System (EFS) offering does.