[OSDOCS#17176]: CQA-3: Container Security and Hardening

modules/security-compliance-nist.adoc

@@ -6,6 +6,9 @@
 [id="security-compliance-nist_{context}"]
 = Understanding compliance and risk management
 
+[role="_abstract"]
+Compliance and risk management frameworks help ensure that your cluster infrastructure meets strict regulatory readiness and cryptographic security standards.
+
 ifndef::openshift-origin[]
 FIPS compliance is one of the most critical components required in
 highly secure environments, to ensure that only supported cryptographic
@@ -15,5 +18,8 @@ include::snippets/fips-snippet.adoc[]
 endif::openshift-origin[]
 
 To understand Red Hat's view of {product-title} compliance frameworks, refer
-to the Risk Management and Regulatory Readiness chapter of the
-link:https://access.redhat.com/articles/5059881[OpenShift Security Guide Book].
+to the Risk Management and Regulatory Readiness chapter of the OpenShift Security Guide Book.
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://access.redhat.com/articles/5059881[OpenShift Security Guide Book]

modules/security-hosts-vms-openshift.adoc

@@ -6,9 +6,11 @@
 [id="security-hosts-vms-openshift_{context}"]
 = Securing {product-title}
 
+[role="_abstract"]
 When you deploy {product-title}, you have the choice of an
 installer-provisioned infrastructure (there are several available platforms)
 or your own user-provisioned infrastructure.
+
 ifndef::openshift-origin[]
 Some low-level security-related configuration, such as enabling FIPS
 mode or adding kernel modules required at first boot, might 

modules/security-hosts-vms-rhcos.adoc

@@ -6,6 +6,7 @@
 [id="security-hosts-vms-rhcos_{context}"]
 = Securing containers on {op-system-first}
 
+[role="_abstract"]
 Containers simplify the act of deploying many applications to run on the same host, using the same kernel and container runtime to spin up each container. The applications can be owned by many users and, because they are kept separate, can run different, and even incompatible, versions of those applications at the same time without issue.
 
 In Linux, containers are just a special type of process, so securing containers is similar in many ways to securing any other running process. An environment for running containers starts with an operating system that can secure the host kernel from containers and other processes running on the host, as well as secure containers from each other.
@@ -14,7 +15,7 @@ Because {product-title} {product-version} runs on {op-system} hosts, with the op
 
 * _Linux namespaces_ enable creating an abstraction of a particular global system resource to make it appear as a separate instance to processes within a namespace. Consequently, several containers can use the same computing resource simultaneously without creating a conflict. Container namespaces that are separate from the host by default include mount table, process table, network interface, user, control group, UTS, and IPC namespaces. Those containers that need direct access to host namespaces need to have elevated permissions to request that access.
 ifdef::openshift-enterprise,openshift-webscale,openshift-aro[]
-See link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/building_running_and_managing_containers/index[Building, running, and managing containers] from the {op-system-base} 9 container documentation for details on the types of namespaces.
+See the {op-system-base} 9 container documentation for details on the types of namespaces.
 endif::[]
 
 * _SELinux_ provides an additional layer of security to keep containers isolated from each other and from the host. SELinux allows administrators to enforce mandatory access controls (MAC) for every user, application, process, and file.
@@ -26,13 +27,19 @@ Disabling SELinux on {op-system} is not supported.
 
 * _CGroups_ (control groups) limit, account for, and isolate the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes. CGroups are used to ensure that containers on the same host are not impacted by each other.
 
-* _Secure computing mode (seccomp)_ profiles can be associated with a container to restrict available system calls. See page 94 of the link:https://www.redhat.com/en/resources/openshift-security-guide-ebook[Red Hat OpenShift security guide] for details about seccomp.
+* _Secure computing mode (seccomp)_ profiles can be associated with a container to restrict available system calls. See the Red Hat OpenShift security guide for details about seccomp.
 
-* Deploying containers using _{op-system}_ reduces the attack surface by minimizing the host environment and tuning it for containers. The link:https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cri-o_runtime/index[CRI-O container engine] further reduces that attack surface by implementing only those features required by Kubernetes and {product-title} to run and manage containers, as opposed to other container engines that implement desktop-oriented standalone features.
+* Deploying containers using _{op-system}_ reduces the attack surface by minimizing the host environment and tuning it for containers. The CRI-O container engine further reduces that attack surface by implementing only those features required by Kubernetes and {product-title} to run and manage containers, as opposed to other container engines that implement desktop-oriented standalone features.
 
 {op-system} is a version of {op-system-base-full} that is specially configured to work as control plane (master) and worker nodes on {product-title} clusters. So {op-system} is tuned to efficiently run container workloads, along with Kubernetes and {product-title} services.
 
 [NOTE]
 ====
 To further protect {op-system} systems in {product-title} clusters, most containers, except those managing or monitoring the host system itself, should run as a non-root user. Dropping the privilege level or creating containers with the least amount of privileges possible is recommended best practice for protecting your own {product-title} clusters.
 ====
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/building_running_and_managing_containers/index[Building, running, and managing containers (Red Hat Enterprise Linux 9)]
+* link:https://www.redhat.com/en/resources/openshift-security-guide-ebook[Red Hat OpenShift Security Guide E-book]
+* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cri-o_runtime/index[CRI-O Container Runtime Guide]

modules/security-hosts-vms-vs-containers.adoc

@@ -6,6 +6,7 @@
 [id="security-hosts-vms-vs-containers_{context}"]
 = Comparing virtualization and containers
 
+[role="_abstract"]
 Traditional virtualization provides another way to keep application
 environments separate on the same physical host. However, virtual machines
 work in a different way than containers.
@@ -30,7 +31,10 @@ particularly appropriate for cloud-native applications. Containers are
 generally much smaller than VMs and consume less memory and CPU.
 
 ifndef::openshift-origin[]
-See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/overview_of_containers_in_red_hat_systems/introduction_to_linux_containers#linux_containers_compared_to_kvm_virtualization[Linux Containers Compared to KVM Virtualization]
-in the {op-system-base} 7 container documentation to learn about the differences between container and VMs.
+See the {op-system-base} 7 container documentation to learn about the differences between Linux containers and KVM virtualization.
 endif::[]
 
+[role="_additional-resources"]
+.Additional resources
+* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/overview_of_containers_in_red_hat_systems/introduction_to_linux_containers#linux_containers_compared_to_kvm_virtualization[Linux Containers Compared to KVM Virtualization]
+

modules/security-platform-admission.adoc

@@ -6,6 +6,7 @@
 [id="security-platform-admission_{context}"]
 = Protecting control plane with admission plugins
 
+[role="_abstract"]
 While RBAC controls access rules between users and groups and available projects, _admission plugins_ define access to the {product-title} master API. Admission plugins form a chain of rules that consist of:
 
 * Default admissions plugins: These implement a default set of policies and resources limits that are applied to components of the {product-title} control plane.

modules/security-platform-authentication.adoc

@@ -9,6 +9,7 @@
 [id="security-platform-auth-controlling-access_{context}"]
 == Controlling access using OAuth
 
+[role="_abstract"]
 You can use API access control via authentication and authorization for securing
 your container platform. The {product-title} master includes a built-in OAuth
 server. Users can obtain OAuth access tokens to authenticate themselves to the
@@ -35,9 +36,7 @@ You can restrict access to specific endpoints, methods, and services and apply
 access policy for groups of users. Application plans allow you to set rate
 limits for API usage and control traffic flow for groups of developers.
 
-For a tutorial on using APIcast v2, the containerized 3scale API Gateway, see
-link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.0/html/deployment_options/apicast-openshift[Running APIcast on Red Hat OpenShift]
-in the 3scale documentation.
+For a tutorial on using APIcast v2, the containerized 3scale API Gateway, see the Red Hat 3scale API Management deployment documentation.
 
 [id="security-platform-red-hat-sso_{context}"]
 == Red Hat Single Sign-On
@@ -62,3 +61,7 @@ secure multitenant master by providing the following:
 - Access to the API Server uses X.509 certificates or OAuth access tokens
 - Project quota limits the damage that a rogue token could do
 - The etcd service is not exposed directly to the cluster
+
+[role="_additional-resources"]
+.Additional resources
+* link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.0/html/deployment_options/apicast-openshift[Running APIcast on Red Hat OpenShift]

modules/security-platform-certificates.adoc

@@ -6,6 +6,7 @@
 [id="security-platform-certificates_{context}"]
 = Managing certificates for the platform
 
+[role="_abstract"]
 {product-title} has multiple components within its framework that use REST-based HTTPS communication leveraging encryption via TLS certificates. {product-title}'s installer configures these certificates during installation. There are some primary components that generate this traffic:
 
 * masters (API server and controllers)

modules/security-platform-multi-tenancy.adoc

@@ -6,6 +6,7 @@
 [id="security-platform-multi-tenancy_{context}"]
 = Isolating containers with multitenancy
 
+[role="_abstract"]
 Multitenancy allows applications on an {product-title} cluster that are owned by multiple users, and run across multiple hosts and namespaces,
 to remain isolated from each other and from outside attacks. You obtain multitenancy by applying role-based access control (RBAC)
 to Kubernetes namespaces.

security/container_security/security-compliance.adoc

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
 For many {product-title} customers, regulatory readiness, or compliance, on
 some level is required before any systems can be put into production.
 That regulatory readiness can be imposed by national standards, industry

security/container_security/security-hosts-vms.adoc

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
 Both containers and virtual machines provide ways of separating
 applications running on a host from the operating system itself.
 Understanding {op-system}, which is the operating system used by

security/container_security/security-platform.adoc

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
 {product-title} and Kubernetes APIs are key to automating container management at scale. APIs are used to:
 
 * Validate and configure the data for pods, services, and replication controllers.