From 65c1c1ae5d99bee4dda36d0c181a8c77f412af51 Mon Sep 17 00:00:00 2001 From: aksjoshi Date: Fri, 26 Jun 2026 23:05:28 +0530 Subject: [PATCH] Make changes --- ...y-container-content-external-scanning.adoc | 59 +++++-------------- .../security-container-content-inside.adoc | 23 ++------ .../security-container-content-scanning.adoc | 25 ++------ .../security-container-content-universal.adoc | 41 +++---------- .../security-monitoring-audit-logging.adoc | 6 +- .../security-monitoring-cluster-logging.adoc | 2 + modules/security-monitoring-events.adoc | 25 +++----- modules/security-network-egress.adoc | 14 ++--- modules/security-network-ingress.adoc | 10 +--- modules/security-network-isolating.adoc | 6 +- modules/security-network-multiple-pod.adoc | 8 +-- modules/security-network-namespaces.adoc | 12 ++-- modules/security-network-policies.adoc | 7 +-- modules/security-registries-ecosystem.adoc | 13 ++-- modules/security-registries-immutable.adoc | 4 +- modules/security-registries-openshift.adoc | 1 + modules/security-registries-quay.adoc | 26 ++------ modules/security-registries-where.adoc | 3 +- .../security-container-content.adoc | 7 +-- .../security-monitoring.adoc | 8 +-- .../container_security/security-network.adoc | 8 +-- .../security-registries.adoc | 27 ++------- 22 files changed, 92 insertions(+), 243 deletions(-) diff --git a/modules/security-container-content-external-scanning.adoc b/modules/security-container-content-external-scanning.adoc index be7a33241a4c..45539e64d5e7 100644 --- a/modules/security-container-content-external-scanning.adoc +++ b/modules/security-container-content-external-scanning.adoc @@ -6,19 +6,13 @@ [id="security-container-content-external-scanning_{context}"] = Integrating external scanning -{product-title} makes use of link:https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/[object annotations] -to extend functionality. External tools, such as vulnerability scanners, can -annotate image objects with metadata to summarize results and control pod -execution. This section describes the recognized format of this annotation so it -can be reliably used in consoles to display useful data to users. +[role="_abstract"] +{product-title} makes use of object annotations to extend functionality. External tools, such as vulnerability scanners, can annotate image objects with metadata to summarize results and control pod execution. This section describes the recognized format of this annotation so it can be reliably used in consoles to display useful data to users. [id="security-image-metadata_{context}"] == Image metadata -There are different types of image quality data, including package -vulnerabilities and open source software (OSS) license compliance. Additionally, -there may be more than one provider of this metadata. To that end, the following -annotation format has been reserved: +There are different types of image quality data, including package vulnerabilities and open source software (OSS) license compliance. Additionally, there might be more than one provider of this metadata. To that end, the following annotation format has been reserved: ---- quality.images.openshift.io/.: {} @@ -31,22 +25,15 @@ quality.images.openshift.io/.: {} |`qualityType` |Metadata type -|`vulnerability` + -`license` + -`operations` + -`policy` +|`vulnerability`, `license`, `operations`, `policy` |`providerId` |Provider ID string -|`openscap` + -`redhatcatalog` + -`redhatinsights` + -`blackduck` + -`jfrog` +|`openscap`, `redhatcatalog`, `redhatinsights`, `blackduck`, `jfrog` |=== [id="security-example-annotation-keys_{context}"] -=== Example annotation keys +== Example annotation keys ---- quality.images.openshift.io/vulnerability.blackduck: {} @@ -55,8 +42,7 @@ quality.images.openshift.io/license.blackduck: {} quality.images.openshift.io/vulnerability.openscap: {} ---- -The value of the image quality annotation is structured data that must adhere to -the following format: +The value of the image quality annotation is structured data that must adhere to the following format: .Annotation value format [option="header"] @@ -79,7 +65,7 @@ the following format: |String |`reference` |Yes -|URL of information source or more details. Required so user may validate the data. +|URL of information source or more details. Required so user might validate the data. |String |`scannerVersion` @@ -125,7 +111,7 @@ representation. The value is range `0..3` where `0` = low. |=== [id="security-example-annotation-values_{context}"] -=== Example annotation values +== Example annotation values This example shows an OpenSCAP annotation for an image with vulnerability summary data and a compliance boolean: @@ -173,14 +159,10 @@ with an external URL for additional details: [id="security-annotating-image-objects_{context}"] == Annotating image objects -While image stream objects -are what an end user of {product-title} operates against, -image objects are annotated with -security metadata. Image objects are cluster-scoped, pointing to a single image -that may be referenced by many image streams and tags. +While image stream objects are what a user of {product-title} operates against, image objects are annotated with security metadata. Image objects are cluster-scoped, pointing to a single image that might be referenced by many image streams and tags. [id="security-example-annotate-CLI_{context}"] -=== Example annotate CLI command +== Example annotate CLI command Replace `` with an image digest, for example `sha256:401e359e0f45bfdcf004e258b72e253fd07fba8cc5c6f2ed4f4608fb119ecc2`: @@ -206,7 +188,7 @@ Use the `images.openshift.io/deny-execution` image policy to programmatically control if an image can be run. [id="security-controlling-pod-execution-example-annotation_{context}"] -=== Example annotation +== Example annotation [source,yaml] ---- @@ -217,19 +199,12 @@ annotations: [id="security-integration-reference_{context}"] == Integration reference -In most cases, external tools such as vulnerability scanners develop a -script or plugin that watches for image updates, performs scanning, and -annotates the associated image object with the results. Typically this -automation calls the {product-title} {product-version} REST APIs to write the annotation. See -{product-title} REST APIs for general -information on the REST APIs. +In most cases, external tools such as vulnerability scanners develop a script or plugin that watches for image updates, performs scanning, and annotates the associated image object with the results. Typically this automation calls the {product-title} {product-version} REST APIs to write the annotation. See {product-title} REST APIs for general information about the REST APIs. [id="security-integration-reference-example-api-call_{context}"] -=== Example REST API call +== Example REST API call -The following example call using `curl` overrides the value of the -annotation. Be sure to replace the values for ``, ``, -``, and ``. +The following example call by using `curl` overrides the value of the annotation. Be sure to replace the values for ``, ``, ``, and ``. .Patch API call [source,terminal] @@ -259,8 +234,6 @@ The following is an example of `PATCH` payload data: ifdef::openshift-origin[] [NOTE] ==== -Due to the complexity of this API call and challenges with escaping characters, -an API developer tool such as link:https://www.getpostman.com/[Postman] may -assist in creating API calls. +Due to the complexity of this API call and challenges with escaping characters, an API developer tool such as Postman might assist in creating API calls. ==== endif::[] diff --git a/modules/security-container-content-inside.adoc b/modules/security-container-content-inside.adoc index 9e73d58b5788..2f7ec90440aa 100644 --- a/modules/security-container-content-inside.adoc +++ b/modules/security-container-content-inside.adoc @@ -6,13 +6,8 @@ [id="security-container-content-inside_{context}"] = Securing inside the container -Applications and infrastructures are composed of readily available components, -many of which are open source packages such as, the Linux operating system, -JBoss Web Server, PostgreSQL, and Node.js. - -Containerized versions of these packages are also available. However, you need -to know where the packages originally came from, what versions are used, who built them, and whether -there is any malicious code inside them. +[role="_abstract"] +Applications and infrastructures are composed of readily available components, many of which are open source packages such as, the Linux operating system, JBoss Web Server, PostgreSQL, and Node.js. Containerized versions of these packages are also available. However, you need to know where the packages originally came from, what versions are used, who built them, and whether there is any malicious code inside them. Some questions to answer include: @@ -20,16 +15,6 @@ Some questions to answer include: * Are there known vulnerabilities in the application layer? * Are the runtime and operating system layers current? -By building your containers from Red Hat -link:https://access.redhat.com/articles/4238681[Universal Base Images] (UBI) you are -assured of a foundation for your container images that consists of -the same RPM-packaged software that is included in Red Hat Enterprise Linux. -No subscriptions are required to either use or redistribute UBI images. +By building your containers from Red Hat Universal Base Images (UBI) you are assured of a foundation for your container images that consists of the same RPM-packaged software that is included in Red Hat Enterprise Linux. No subscriptions are required to either use or redistribute UBI images. -To assure ongoing security of the containers themselves, security -scanning features, used directly from {op-system-base} or added to {product-title}, -can alert you when -an image you are using has vulnerabilities. OpenSCAP image scanning is -available in {op-system-base} and the -link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/red_hat_quay_operator_features/container-security-operator-setup[{rhq-cso}] can be added -to check container images used in {product-title}. +To assure ongoing security of the containers themselves, security scanning features, used directly from {op-system-base} or added to {product-title}, can alert you when an image you are using has vulnerabilities. OpenSCAP image scanning is available in {op-system-base} and the {rhq-cso} can be added to check container images used in {product-title}. diff --git a/modules/security-container-content-scanning.adoc b/modules/security-container-content-scanning.adoc index 80cc3f33de22..77cf2ffc5b12 100644 --- a/modules/security-container-content-scanning.adoc +++ b/modules/security-container-content-scanning.adoc @@ -6,29 +6,14 @@ [id="security-container-content-scanning_{context}"] = Security scanning in {op-system-base} -For {op-system-base-full} systems, OpenSCAP scanning is available -from the `openscap-utils` package. In {op-system-base}, you can use the `openscap-podman` -command to scan images for vulnerabilities. See -link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/security_hardening/index#scanning-the-system-for-configuration-compliance-and-vulnerabilities_security-hardening[Scanning containers and container images for vulnerabilities] in the Red Hat Enterprise Linux documentation. +[role="_abstract"] +For {op-system-base-full} systems, OpenSCAP scanning is available from the `openscap-utils` package. In {op-system-base}, you can use the `openscap-podman` command to scan images for vulnerabilities. -{product-title} enables you to leverage {op-system-base} scanners with your CI/CD process. -For example, you can integrate static code analysis tools that test for security -flaws in your source code and software composition analysis tools that identify -open source libraries to provide metadata on those libraries such as -known vulnerabilities. +{product-title} enables you to use {op-system-base} scanners with your Continuous Integration and Continuous Delivery (CI/CD) process. For example, you can integrate static code analysis tools that test for security flaws in your source code and software composition analysis tools that identify open source libraries to provide metadata on those libraries such as known vulnerabilities. [id="quay-security-scan_{context}"] == Scanning OpenShift images -For the container images that are running in {product-title} -and are pulled from {quay} registries, you can use an Operator to list the -vulnerabilities of those images. The -link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/red_hat_quay_operator_features/container-security-operator-setup[{rhq-cso}] -can be added to {product-title} to provide vulnerability reporting -for images added to selected namespaces. +For the container images that are running in {product-title} and are pulled from {quay} registries, you can use an Operator to list the vulnerabilities of those images. The {rhq-cso} can be added to {product-title} to provide vulnerability reporting for images added to selected namespaces. -Container image scanning for {quay} is performed by the -link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/vulnerability_reporting_with_clair_on_red_hat_quay/index[Clair]. -In {quay}, Clair can search for and report vulnerabilities in -images built from {op-system-base}, CentOS, Oracle, Alpine, Debian, and Ubuntu -operating system software. +Container image scanning for {quay} is performed by Clair. In {quay}, Clair can search for and report vulnerabilities in images built from {op-system-base}, CentOS, Oracle, Alpine, Debian, and Ubuntu operating system software. diff --git a/modules/security-container-content-universal.adoc b/modules/security-container-content-universal.adoc index a74169a90d54..830eaebb5630 100644 --- a/modules/security-container-content-universal.adoc +++ b/modules/security-container-content-universal.adoc @@ -6,45 +6,20 @@ [id="security-container-content-universal_{context}"] = Creating redistributable images with UBI -To create containerized applications, you typically start with a trusted base -image that offers the components that are usually provided by the operating system. -These include the libraries, utilities, and other features the application -expects to see in the operating system's file system. +[role="_abstract"] +You can typically start with a trusted base image that offers the components that are usually provided by the operating system to create containerized applications. These include the libraries, utilities, and other features the application expects to see in the operating system's file system. -Red{nbsp}Hat Universal Base Images (UBI) were created to encourage anyone building their -own containers to start with one that is made entirely from Red{nbsp}Hat Enterprise -Linux rpm packages and other content. These UBI images are updated regularly -to keep up with security patches and free to use and redistribute with -container images built to include your own software. +Red{nbsp}Hat Universal Base Images (UBI) were created to encourage anyone building their own containers to start with one that is made entirely from Red{nbsp}Hat Enterprise Linux RPM packages and other content. These UBI images are updated regularly to keep up with security patches and free to use and redistribute with container images built to include your own software. -Search the -link:https://catalog.redhat.com/software/containers/explore[Red Hat Ecosystem Catalog] -to both find and check the health of different UBI images. -As someone creating secure container images, you might -be interested in these two general types of UBI images: +Search the Red Hat Ecosystem Catalog to both find and check the health of different UBI images. As someone creating secure container images, you might be interested in these two general types of UBI images: -* **UBI**: There are standard UBI images for RHEL 7, 8, and 9 (`ubi7/ubi`, -`ubi8/ubi`, and `ubi9/ubi`), as well as minimal images based on those systems (`ubi7/ubi-minimal`, `ubi8/ubi-mimimal`, and ubi9/ubi-minimal). All of these images are preconfigured to point to free -repositories of {op-system-base} software that you can add to the container images you build, -using standard `yum` and `dnf` commands. +* **UBI**: There are standard UBI images for RHEL 7, 8, and 9 (`ubi7/ubi`, `ubi8/ubi`, and `ubi9/ubi`), and minimal images based on those systems (`ubi7/ubi-minimal`, `ubi8/ubi-mimimal`, and ubi9/ubi-minimal). All of these images are preconfigured to point to free repositories of {op-system-base} software that you can add to the container images you build, using standard `yum` and `dnf` commands. + [NOTE] ==== -Red{nbsp}Hat encourages people to use these images on other distributions, -such as Fedora and Ubuntu. +Red{nbsp}Hat encourages people to use these images on other distributions, such as Fedora and Ubuntu. ==== -* **Red{nbsp}Hat Software Collections**: Search the Red{nbsp}Hat Ecosystem Catalog -for `rhscl/` to find images created to use as base images for specific types -of applications. For example, there are Apache httpd ([x-]`rhscl/httpd-*`), -Python ([x-]`rhscl/python-*`), Ruby ([x-]`rhscl/ruby-*`), Node.js -([x-]`rhscl/nodejs-*`) and Perl ([x-]`rhscl/perl-*`) rhscl images. +* **Red{nbsp}Hat Software Collections**: Search the Red{nbsp}Hat Ecosystem Catalog for `rhscl/` to find images created to use as base images for specific types of applications. For example, there are Apache httpd ([x-]`rhscl/httpd-*`), Python ([x-]`rhscl/python-*`), Ruby ([x-]`rhscl/ruby-*`), Node.js ([x-]`rhscl/nodejs-*`) and Perl ([x-]`rhscl/perl-*`) rhscl images. -Keep in mind that while UBI images are freely available and redistributable, -Red{nbsp}Hat support for these images is only available through Red{nbsp}Hat -product subscriptions. - -See -link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index#using_red_hat_universal_base_images_standard_minimal_and_runtimes[Using Red{nbsp}Hat Universal Base Images] -in the Red Hat Enterprise Linux documentation for information on how to use and build on -standard, minimal and init UBI images. +Remember that while UBI images are freely available and redistributable, Red{nbsp}Hat support for these images is only available through Red{nbsp}Hat product subscriptions. diff --git a/modules/security-monitoring-audit-logging.adoc b/modules/security-monitoring-audit-logging.adoc index fcb2793678b3..4ec726e62857 100644 --- a/modules/security-monitoring-audit-logging.adoc +++ b/modules/security-monitoring-audit-logging.adoc @@ -2,9 +2,9 @@ // // * security/container_security/security-monitoring.adoc +:_mod-docs-content-type: CONCEPT [id="security-monitoring-audit-logs_{context}"] = Audit logs -With _audit logs_, you can follow a sequence of activities associated with how a -user, administrator, or other {product-title} component is behaving. -API audit logging is done on each server. +[role="_abstract"] +With _audit logs_, you can follow a sequence of activities associated with how a user, administrator, or other {product-title} component is behaving. API audit logging is done on each server. diff --git a/modules/security-monitoring-cluster-logging.adoc b/modules/security-monitoring-cluster-logging.adoc index eb96cfd84fad..851a636eed21 100644 --- a/modules/security-monitoring-cluster-logging.adoc +++ b/modules/security-monitoring-cluster-logging.adoc @@ -2,9 +2,11 @@ // // * security/container_security/security-monitoring.adoc +:_mod-docs-content-type: CONCEPT [id="security-monitoring-cluster-logging_{context}"] = Logging +[role="_abstract"] Using the `oc log` command, you can view container logs, build configs and deployments in real time. Different can users have access different access to logs: * Users who have access to a project are able to see the logs for that project by default. diff --git a/modules/security-monitoring-events.adoc b/modules/security-monitoring-events.adoc index b524acb13aed..16c988e5bc65 100644 --- a/modules/security-monitoring-events.adoc +++ b/modules/security-monitoring-events.adoc @@ -2,19 +2,14 @@ // // * security/container_security/security-monitoring.adoc +:_mod-docs-content-type: CONCEPT [id="security-monitoring-events_{context}"] = Watching cluster events -Cluster administrators are encouraged to familiarize themselves with the `Event` resource -type and review the list of system events to -determine which events are of interest. -Events are associated with a namespace, either the namespace of the -resource they are related to or, for cluster events, the `default` -namespace. The default namespace holds relevant events for monitoring or auditing a cluster, -such as node events and resource events related to infrastructure components. +[role="_abstract"] +Cluster administrators are encouraged to familiarize themselves with the `Event` resource type and review the list of system events to determine which events are of interest. Events are associated with a namespace, either the namespace of the resource they are related to or, for cluster events, the `default` namespace. The default namespace holds relevant events for monitoring or auditing a cluster, such as node events and resource events related to infrastructure components. -The master API and `oc` command do not provide parameters to scope a listing of events to only those -related to nodes. A simple approach would be to use `grep`: +The master API and `oc` command do not provide parameters to scope a listing of events to only those related to nodes. A simple approach would be to use `grep`: [source,terminal] ---- @@ -27,9 +22,7 @@ $ oc get event -n default | grep Node 1h 20h 3 origin-node-1.example.local Node Normal NodeHasDiskPressure ... ---- -A more flexible approach is to output the events in a form that other -tools can process. For example, the following example uses the `jq` -tool against JSON output to extract only `NodeHasDiskPressure` events: +A more flexible approach is to output the events in a form that other tools can process. For example, the following example uses the `jq` tool against JSON output to extract only `NodeHasDiskPressure` events: [source,terminal] ---- @@ -54,9 +47,7 @@ $ oc get events -n default -o json \ } ---- -Events related to resource creation, modification, or deletion can also be -good candidates for detecting misuse of the cluster. The following query, -for example, can be used to look for excessive pulling of images: +Events related to resource creation, modification, or deletion can also be good candidates for detecting misuse of the cluster. The following query, for example, can be used to look for excessive pulling of images: [source,terminal] ---- @@ -72,7 +63,5 @@ $ oc get events --all-namespaces -o json \ [NOTE] ==== -When a namespace is deleted, its events are deleted as well. Events can also expire and are deleted to prevent -filling up etcd storage. Events are -not stored as a permanent record and frequent polling is necessary to capture statistics over time. +When a namespace is deleted, its events are deleted as well. Events can also expire and are deleted to prevent filling up etcd storage. Events are not stored as a permanent record and frequent polling is necessary to capture statistics over time. ==== diff --git a/modules/security-network-egress.adoc b/modules/security-network-egress.adoc index f4811beaec58..532ba2b5c47d 100644 --- a/modules/security-network-egress.adoc +++ b/modules/security-network-egress.adoc @@ -2,17 +2,11 @@ // // * security/container_security/security-network.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-egress_{context}"] = Securing egress traffic -{product-title} provides the ability to control egress traffic using either -a router or firewall method. For example, you can use the IP allow list to control database access. -A cluster administrator can assign one or more egress IP addresses to a project by xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[configuring an egress IP address]. -Likewise, a cluster administrator can prevent egress traffic from -going outside of an {product-title} cluster using an egress firewall. +[role="_abstract"] +{product-title} provides the ability to control egress traffic by using either a router or firewall method. For example, you can use the IP allow list to control database access. A cluster administrator can assign one or more egress IP addresses to a project by configuring an egress IP address. Likewise, a cluster administrator can prevent egress traffic from going outside of an {product-title} cluster by using an egress firewall. -By assigning a fixed egress IP address, you can have all outgoing traffic -assigned to that IP address for a particular project. -With the egress firewall, you can prevent a pod from connecting to an -external network, prevent a pod from connecting to an internal network, -or limit a pod's access to specific internal subnets. +By assigning a fixed egress IP address, you can have all outgoing traffic assigned to that IP address for a particular project. With the egress firewall, you can prevent a pod from connecting to an external network, prevent a pod from connecting to an internal network, or limit a pod's access to specific internal subnets. diff --git a/modules/security-network-ingress.adoc b/modules/security-network-ingress.adoc index 78656d4e4b62..84f9ea4f7645 100644 --- a/modules/security-network-ingress.adoc +++ b/modules/security-network-ingress.adoc @@ -2,13 +2,9 @@ // // * security/container_security/security-network.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-ingress_{context}"] = Securing ingress traffic -There are many security implications related to how you configure -access to your Kubernetes services from outside of your {product-title} cluster. -Besides exposing HTTP and HTTPS routes, ingress routing allows you to set up -NodePort or LoadBalancer ingress types. NodePort exposes an application's -service API object from each cluster worker. LoadBalancer lets you assign an -external load balancer to an associated service API object -in your {product-title} cluster. +[role="_abstract"] +There are many security implications related to how you configure access to your Kubernetes services from outside of your {product-title} cluster. Besides exposing HTTP and HTTPS routes, ingress routing allows you to set up NodePort or LoadBalancer ingress types. NodePort exposes an application's service API object from each cluster worker. LoadBalancer lets you assign an external load balancer to an associated service API object in your {product-title} cluster. diff --git a/modules/security-network-isolating.adoc b/modules/security-network-isolating.adoc index ae6f1e28b7a1..092533bcbf66 100644 --- a/modules/security-network-isolating.adoc +++ b/modules/security-network-isolating.adoc @@ -2,9 +2,9 @@ // // * security/container_security/security-network.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-isolating_{context}"] = Isolating applications -{product-title} enables you to segment network traffic on a single cluster to -make multitenant clusters that isolate users, teams, applications, and -environments from non-global resources. +[role="_abstract"] +{product-title} enables you to segment network traffic on a single cluster to make multitenant clusters that isolate users, teams, applications, and environments from non-global resources. diff --git a/modules/security-network-multiple-pod.adoc b/modules/security-network-multiple-pod.adoc index d3d36a15c9ce..1bf8e46d2818 100644 --- a/modules/security-network-multiple-pod.adoc +++ b/modules/security-network-multiple-pod.adoc @@ -2,11 +2,9 @@ // // * security/container_security/security-network.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-multiple-pod_{context}"] = Using multiple pod networks -Each running container has only one network interface by default. -The Multus CNI plugin lets you create multiple CNI networks, and then -attach any of those networks to your pods. In that way, you can do -things like separate private data onto a more restricted network -and have multiple network interfaces on each node. +[role="_abstract"] +Each running container has only one network interface by default. The Multus CNI plugin lets you create multiple CNI networks, and then attach any of those networks to your pods. In that way, you can do things such as separate private data onto a more restricted network and have multiple network interfaces on each node. diff --git a/modules/security-network-namespaces.adoc b/modules/security-network-namespaces.adoc index 3eaa2a678154..c1458f60f8ff 100644 --- a/modules/security-network-namespaces.adoc +++ b/modules/security-network-namespaces.adoc @@ -2,15 +2,11 @@ // // * security/container_security/security-network.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-namespaces_{context}"] = Using network namespaces -{product-title} uses software-defined networking (SDN) to provide a unified -cluster network that enables communication between containers across the -cluster. +[role="_abstract"] +{product-title} uses software-defined networking (SDN) to give a unified cluster network that enables communication between containers across the cluster. -Network policy mode, by default, makes all pods in a project accessible from -other pods and network endpoints. -To isolate one or more pods in a project, you can create `NetworkPolicy` objects -in that project to indicate the allowed incoming connections. -Using multitenant mode, you can provide project-level isolation for pods and services. +Network policy mode, by default, makes all pods in a project accessible from other pods and network endpoints. To isolate one or more pods in a project, you can create `NetworkPolicy` objects in that project to indicate the allowed incoming connections. Using multitenant mode, you can provide project-level isolation for pods and services. diff --git a/modules/security-network-policies.adoc b/modules/security-network-policies.adoc index b3d8a9d3856c..b36707ed8cdd 100644 --- a/modules/security-network-policies.adoc +++ b/modules/security-network-policies.adoc @@ -2,10 +2,9 @@ // // * security/container_security/security-network.adoc +:_mod-docs-content-type: CONCEPT [id="security-network-policies_{context}"] = Isolating pods with network policies -Using _network policies_, you can isolate pods from each other in the same project. -Network policies can deny all network access to a pod, -only allow connections for the Ingress Controller, reject connections from -pods in other projects, or set similar rules for how networks behave. +[role="_abstract"] +Using _network policies_, you can isolate pods from each other in the same project. Network policies can deny all network access to a pod, only allow connections for the Ingress Controller, reject connections from pods in other projects, or set similar rules for how networks behave. diff --git a/modules/security-registries-ecosystem.adoc b/modules/security-registries-ecosystem.adoc index 9cd8d8d0bf84..4477a7f538c1 100644 --- a/modules/security-registries-ecosystem.adoc +++ b/modules/security-registries-ecosystem.adoc @@ -6,16 +6,15 @@ [id="security-registries-ecosystem_{context}"] = Getting containers from Red Hat Registry and Ecosystem Catalog -Red Hat lists certified container images for Red Hat products and partner offerings from the link:https://catalog.redhat.com/software/containers/explore[Container Images] section of the Red Hat Ecosystem Catalog. From that catalog, you can see details of each image, including CVE, software packages listings, and health scores. +[role="_abstract"] +Red Hat lists certified container images for Red Hat products and partner offerings from the Container Images section of the Red Hat Ecosystem Catalog. From that catalog, you can see details of each image, including CVE, software packages listings, and health scores. -Red Hat images are actually stored in what is referred to as the _Red Hat Registry_, which is represented by a public container registry (`registry.access.redhat.com`) and an authenticated registry (`registry.redhat.io`). Both include basically the same set of container images, with -`registry.redhat.io` including some additional images that require authentication with Red Hat subscription credentials. +Red Hat images are actually stored in what is referred to as the _Red Hat Registry_, which is represented by a public container registry (`registry.access.redhat.com`) and an authenticated registry (`registry.redhat.io`). Both include the same set of container images, with `registry.redhat.io` including some additional images that require authentication with Red Hat subscription credentials. -Container content is monitored for vulnerabilities by Red Hat and updated regularly. When Red Hat releases security updates, such as fixes to _glibc_, link:https://access.redhat.com/security/vulnerabilities/drown[DROWN], or link:https://access.redhat.com/blogs/766093/posts/2757141[Dirty Cow], any affected container images are also rebuilt and pushed to the Red Hat Registry. +Container content is monitored for vulnerabilities by Red Hat and updated regularly. When Red Hat releases security updates, such as fixes to _glibc_, DROWN, or Dirty Cow, any affected container images are also rebuilt and pushed to the Red Hat Registry. Red Hat uses a `health index` to reflect the security risk for each container provided through the Red Hat Ecosystem Catalog. Because containers consume software provided by Red Hat and the errata process, old, stale containers are insecure whereas new, fresh containers are more secure. -To illustrate the age of containers, the Red Hat Ecosystem Catalog uses a grading system. A freshness grade is a measure of the oldest and most severe security errata available for an image. "A" is more up to date than "F". See link:https://access.redhat.com/articles/2803031[Container Health Index grades as used inside the Red Hat Ecosystem Catalog] for more details on this grading system. +To illustrate the age of containers, the Red Hat Ecosystem Catalog uses a grading system. A freshness grade is a measure of the oldest and most severe security errata available for an image. "A" is more up to date than "F". -See the link:https://access.redhat.com/security/[Red Hat Product Security Center] for details on security updates and vulnerabilities related to Red Hat software. Check out link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories] -to search for specific advisories and CVEs. +See the Red Hat Product Security Center for details on security updates and vulnerabilities related to Red Hat software. Check out Red Hat Security Advisories to search for specific advisories and CVEs. diff --git a/modules/security-registries-immutable.adoc b/modules/security-registries-immutable.adoc index 7bf7373295da..9fc47dc77c76 100644 --- a/modules/security-registries-immutable.adoc +++ b/modules/security-registries-immutable.adoc @@ -6,6 +6,7 @@ [id="security-registries-immutable_{context}"] = Immutable and certified containers +[role="_abstract"] Consuming security updates is particularly important when managing _immutable containers_. Immutable containers are containers that will never be changed while running. When you deploy immutable containers, you do not step into the running container to replace one or more binaries. From an operational standpoint, you rebuild and redeploy an updated container image to replace a container instead of changing it. Red Hat certified images are: @@ -14,5 +15,4 @@ Red Hat certified images are: * Compatible across the {op-system-base} platforms, from bare metal to cloud * Supported by Red Hat -The list of known vulnerabilities is constantly evolving, so you must track the contents of your deployed container images, as well as newly downloaded images, over time. You can use link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories (RHSAs)] to alert you to any newly discovered issues in Red Hat certified container images, and direct you to the updated image. -Alternatively, you can go to the Red Hat Ecosystem Catalog to look up that and other security-related issues for each Red Hat image. +The list of known vulnerabilities is constantly evolving, so you must track the contents of your deployed container images, and newly downloaded images, over time. You can use Red Hat Security Advisories (RHSAs) to alert you to any newly discovered issues in Red Hat certified container images, and direct you to the updated image. Alternatively, you can go to the Red Hat Ecosystem Catalog to look up that and other security-related issues for each Red Hat image. diff --git a/modules/security-registries-openshift.adoc b/modules/security-registries-openshift.adoc index 368f40baa575..47ba1acdd751 100644 --- a/modules/security-registries-openshift.adoc +++ b/modules/security-registries-openshift.adoc @@ -6,6 +6,7 @@ [id="security-registries-openshift_{context}"] = OpenShift Container Registry +[role="_abstract"] {product-title} includes the _OpenShift Container Registry_, a private registry running as an integrated component of the platform that you can use to manage your container images. The OpenShift Container Registry provides role-based access controls that allow you to manage who can pull and push which container images. {product-title} also supports integration with other private registries that you might already be using, such as {quay}. \ No newline at end of file diff --git a/modules/security-registries-quay.adoc b/modules/security-registries-quay.adoc index 4cd3c5cbffac..c1620aaca3e9 100644 --- a/modules/security-registries-quay.adoc +++ b/modules/security-registries-quay.adoc @@ -6,27 +6,19 @@ [id="security-registries-quay_{context}"] = Storing containers using {quay} -link:https://access.redhat.com/products/red-hat-quay[{quay}] is an -enterprise-quality container registry product from Red Hat. -Development for {quay} is done through the upstream -link:https://docs.projectquay.io/welcome.html[Project Quay]. -{quay} is available to deploy on-premise or through the hosted -version of {quay} at link:https://quay.io[Quay.io]. +[role="_abstract"] +{quay} is an enterprise-quality container registry product from Red Hat. Development for {quay} is done through the upstream Project Quay. {quay} is available to deploy on-premise or through the hosted version of {quay} at Quay.io. Security-related features of {quay} include: * *Time machine*: Allows images with older tags to expire after a set period of time or based on a user-selected expiration time. -* *link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/manage_red_hat_quay/index#repo-mirroring-in-red-hat-quay[Repository mirroring]*: Lets you mirror -other registries for security reasons, such hosting a public repository -on {quay} behind a company firewall, or for performance reasons, to -keep registries closer to where they are used. +* *Repository mirroring*: Lets you mirror other registries for security reasons, such hosting a public repository on {quay} behind a company firewall, or for performance reasons, to keep registries closer to where they are used. -* *Action log storage*: Save {quay} logging output to link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/manage_red_hat_quay/index#proc_manage-log-storage[Elasticsearch storage or Splunk] to allow for later search and analysis. +* *Action log storage*: Save {quay} logging output to Elasticsearch storage or Splunk to allow for later search and analysis. -* *link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html/vulnerability_reporting_with_clair_on_red_hat_quay/index[Clair]*: Scan images against a variety of Linux -vulnerability databases, based on the origins of each container image. +* *Clair*: Scan images against a variety of Linux vulnerability databases, based on the origins of each container image. * *Internal authentication*: Use the default local database to handle RBAC authentication to {quay} or choose from LDAP, Keystone (OpenStack), @@ -39,10 +31,4 @@ from GitHub, GitHub Enterprise, or Google Authentication. from docker, rkt, anonymous access, user-created accounts, encrypted client passwords, or prefix username autocompletion. -Ongoing integration of {quay} with {product-title} continues, -with several {product-title} Operators of particular interest. -The link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/red_hat_quay_operator_features/index#quay-bridge-operator[Quay Bridge Operator] -lets you replace the internal {product-registry} with {quay}. -The link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/red_hat_quay_operator_features/index#container-security-operator-setup[{rhq-cso}] -lets you check vulnerabilities of images running in {product-title} that were -pulled from {quay} registries. +Ongoing integration of {quay} with {product-title} continues, with several {product-title} Operators of particular interest. The Quay Bridge Operator lets you replace the internal {product-registry} with {quay}. The {rhq-cso} lets you check vulnerabilities of images running in {product-title} that were pulled from {quay} registries. diff --git a/modules/security-registries-where.adoc b/modules/security-registries-where.adoc index 5a8ef8a3cd3a..9b90dad6ee16 100644 --- a/modules/security-registries-where.adoc +++ b/modules/security-registries-where.adoc @@ -6,4 +6,5 @@ [id="security-registries-where_{context}"] = Knowing where containers come from? -There are tools you can use to scan and track the contents of your downloaded and deployed container images. However, there are many public sources of container images. When using public container registries, you can add a layer of protection by using trusted sources. +[role="_abstract"] +You can use tools to scan and track the contents of your downloaded and deployed container images. However, there are many public sources of container images. When using public container registries, you can add a layer of protection by using trusted sources. diff --git a/security/container_security/security-container-content.adoc b/security/container_security/security-container-content.adoc index 3af96eb7d795..7504339fc3d0 100644 --- a/security/container_security/security-container-content.adoc +++ b/security/container_security/security-container-content.adoc @@ -6,11 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -To ensure the security of the content inside your containers -you need to start with trusted base images, such as Red Hat -Universal Base Images, and add trusted software. To check the -ongoing security of your container images, there are both -Red Hat and third-party tools for scanning images. +[role="_abstract"] +To ensure the security of the content inside your containers you need to start with trusted base images, such as Red Hat Universal Base Images, and add trusted software. To check the ongoing security of your container images, there are both Red Hat and third-party tools for scanning images. // Security inside the container include::modules/security-container-content-inside.adoc[leveloffset=+1] diff --git a/security/container_security/security-monitoring.adoc b/security/container_security/security-monitoring.adoc index 019864a17d3b..a359e52a0fae 100644 --- a/security/container_security/security-monitoring.adoc +++ b/security/container_security/security-monitoring.adoc @@ -6,12 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -The ability to monitor and audit an {product-title} cluster is an -important part of safeguarding the cluster and its users against -inappropriate usage. - -There are two main sources of cluster-level information that -are useful for this purpose: events and logging. +[role="_abstract"] +The ability to monitor and audit an {product-title} cluster is an important part of safeguarding the cluster and its users against inappropriate usage. There are two main sources of cluster-level information that are useful for this purpose: events and logging. // Cluster events include::modules/security-monitoring-events.adoc[leveloffset=+1] diff --git a/security/container_security/security-network.adoc b/security/container_security/security-network.adoc index e1ffbe30c374..e8f6838b66e7 100644 --- a/security/container_security/security-network.adoc +++ b/security/container_security/security-network.adoc @@ -6,12 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -Network security can be managed at several levels. At the pod level, -network namespaces can prevent containers from seeing other pods or -the host system by restricting network access. Network policies -give you control over allowing and rejecting connections. -You can manage ingress and egress traffic to and from your -containerized applications. +[role="_abstract"] +Network security can be managed at several levels. At the pod level, network namespaces can prevent containers from seeing other pods or the host system by restricting network access. Network policies give you control over allowing and rejecting connections. You can manage ingress and egress traffic to and from your containerized applications. // Network namespaces include::modules/security-network-namespaces.adoc[leveloffset=+1] diff --git a/security/container_security/security-registries.adoc b/security/container_security/security-registries.adoc index 0148b46eae13..6e5f89b13a1d 100644 --- a/security/container_security/security-registries.adoc +++ b/security/container_security/security-registries.adoc @@ -6,29 +6,10 @@ include::_attributes/common-attributes.adoc[] toc::[] -Container registries store container images to: - -* Make images accessible to others -* Organize images into repositories that can include multiple versions of an image -* Optionally limit access to images, based on different authentication methods, or -make them publicly available - -There are public container registries, such as Quay.io and Docker Hub -where many people and organizations share their images. -The Red Hat Registry offers supported Red Hat and partner images, -while the Red Hat Ecosystem Catalog offers detailed descriptions -and health checks for those images. -To manage your own registry, you could purchase a container -registry such as -link:https://access.redhat.com/products/red-hat-quay[{quay}]. - -From a security standpoint, some registries provide special features to -check and improve the health of your containers. -For example, {quay} offers container vulnerability scanning -with Clair security scanner, build triggers to automatically rebuild -images when source code changes in GitHub and other locations, and -the ability to use role-based access control (RBAC) to -secure access to images. +[role="_abstract"] +Container registries store container images to make images accessible to others, organize images into repositories that can include multiple versions of an image, and optionally limit access to images, based on different authentication methods, or make them publicly available. There are public container registries, such as Quay.io and Docker Hub where many people and organizations share their images. The Red Hat Registry offers supported Red Hat and partner images, while the Red Hat Ecosystem Catalog offers detailed descriptions and health checks for those images. To manage your own registry, you could purchase a container registry such as {quay}. + +From a security standpoint, some registries provide special features to check and improve the health of your containers. For example, {quay} offers container vulnerability scanning with Clair security scanner, build triggers to automatically rebuild images when source code changes in GitHub and other locations, and the ability to use role-based access control (RBAC) to secure access to images. // Where do your containers come from? include::modules/security-registries-where.adoc[leveloffset=+1]