From 85e0836e88c5b0a66135f72e099b341c5182e212 Mon Sep 17 00:00:00 2001 From: aksjoshi Date: Fri, 26 Jun 2026 14:54:59 +0530 Subject: [PATCH] Make changes --- modules/security-build-designing.adoc | 27 ++++-------- modules/security-build-inputs.adoc | 8 ++-- modules/security-build-knative.adoc | 3 +- modules/security-build-management.adoc | 33 +++++--------- modules/security-build-once.adoc | 32 +++++++------- modules/security-deploy-continuous.adoc | 5 +-- modules/security-deploy-image-sources.adoc | 21 ++------- modules/security-deploy-secrets.adoc | 24 +++-------- modules/security-deploy-signature.adoc | 30 +++---------- modules/security-deploy-trigger.adoc | 19 ++------ modules/security-storage-block.adoc | 3 +- modules/security-storage-persistent.adoc | 26 ++++------- modules/security-storage-shared.adoc | 4 +- .../security-understanding-containers.adoc | 19 ++++---- modules/security-understanding-openshift.adoc | 14 +++--- .../container_security/security-build.adoc | 5 +-- .../container_security/security-deploy.adoc | 7 +-- .../container_security/security-storage.adoc | 10 ++--- .../security-understanding.adoc | 43 ++++++------------- 19 files changed, 115 insertions(+), 218 deletions(-) diff --git a/modules/security-build-designing.adoc b/modules/security-build-designing.adoc index e3b880b23c74..ed4d6306e38e 100644 --- a/modules/security-build-designing.adoc +++ b/modules/security-build-designing.adoc @@ -6,29 +6,20 @@ [id="security-build-designing_{context}"] = Designing your build process +[role="_abstract"] +You can design your container image management to separate control across teams by using layered images, integrate automated security testing into your CI process, and sign custom containers to ensure integrity between build and deployment. + You can design your container image management and build process to use container layers so that you can separate control. image::build_process2.png["Designing Your Build Process", align="center"] -For example, an operations team manages base images, while architects manage -middleware, runtimes, databases, and other solutions. Developers can then focus -on application layers and focus on writing code. +For example, an operations team manages base images, while architects manage middleware, runtimes, databases, and other solutions. Developers can then focus on application layers and focus on writing code. -Because new vulnerabilities are identified daily, you need to proactively check -container content over time. To do this, you should integrate automated security -testing into your build or CI process. For example: +Because new vulnerabilities are identified daily, you need to proactively check container content over time. To do this, you should integrate automated security testing into your build or CI process. For example: -* SAST / DAST – Static and Dynamic security testing tools. -* Scanners for real-time checking against known vulnerabilities. Tools like these -catalog the open source packages in your container, notify you of any known -vulnerabilities, and update you when new vulnerabilities are discovered in -previously scanned packages. +* SAST / DAST - Static and Dynamic security testing tools. +* Scanners for real-time checking against known vulnerabilities. Tools such as these catalog the open source packages in your container, notify you of any known vulnerabilities, and update you when new vulnerabilities are discovered in previously scanned packages. -Your CI process should include policies that flag builds with issues discovered -by security scans so that your team can take appropriate action to address those -issues. You should sign your custom built containers to ensure that nothing is -tampered with between build and deployment. +Your CI process should include policies that flag builds with issues discovered by security scans so that your team can take appropriate action to address those issues. You should sign your custom built containers to ensure that nothing is tampered with between build and deployment. -Using GitOps methodology, you can use the same CI/CD mechanisms to -manage not only your application configurations, but also your -{product-title} infrastructure. +Using GitOps methodology, you can use the same CI/CD mechanisms to manage not only your application configurations, but also your {product-title} infrastructure. diff --git a/modules/security-build-inputs.adoc b/modules/security-build-inputs.adoc index 9ba0a040abf2..3652f49c09ad 100644 --- a/modules/security-build-inputs.adoc +++ b/modules/security-build-inputs.adoc @@ -6,10 +6,12 @@ [id="security-build-inputs_{context}"] = Securing inputs during builds +[role="_abstract"] +You can protect sensitive credentials required during builds by defining input secrets that give access to dependent resources without exposing those credentials in the final application image. + In some scenarios, build operations require credentials to access dependent resources, but it is undesirable for those credentials to be available in the final application image produced by the build. You can define input secrets for this purpose. -For example, when building a Node.js application, you can set up your private mirror for Node.js modules. To download modules from that private mirror, you must supply a custom `.npmrc` file for the build that contains -a URL, user name, and password. For security reasons, you do not want to expose your credentials in the application image. +For example, when building a Node.js application, you can set up your private mirror for Node.js modules. To download modules from that private mirror, you must supply a custom `.npmrc` file for the build that has a URL, user name, and password. For security reasons, you do not want to expose your credentials in the application image. Using this example scenario, you can add an input secret to a new `BuildConfig` object. @@ -22,7 +24,7 @@ Using this example scenario, you can add an input secret to a new `BuildConfig` $ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc ---- + -This creates a new secret named `secret-npmrc`, which contains the base64 encoded content of the `~/.npmrc` file. +This creates a new secret named `secret-npmrc`, which has the base64 encoded content of the `~/.npmrc` file. . Add the secret to the `source` section in the existing `BuildConfig` object: + diff --git a/modules/security-build-knative.adoc b/modules/security-build-knative.adoc index 5f913640c850..29bb091cc6d2 100644 --- a/modules/security-build-knative.adoc +++ b/modules/security-build-knative.adoc @@ -6,7 +6,8 @@ [id="security-build-knative_{context}"] = Building Knative serverless applications -Relying on Kubernetes and Kourier, you can build, deploy, and manage serverless applications by using OpenShift Serverless in {product-title}. +[role="_abstract"] +You can build, deploy, and manage serverless applications by using OpenShift Serverless in {product-title}, relying on Kubernetes and Kourier, leveraging S2I builder images and Knative services for scalable, event-driven workloads. As with other builds, you can use S2I images to build your containers, then serve them using Knative services. View Knative application builds through the *Topology* view of the {product-title} web console. diff --git a/modules/security-build-management.adoc b/modules/security-build-management.adoc index 930da6a7842f..742bd6175fbe 100644 --- a/modules/security-build-management.adoc +++ b/modules/security-build-management.adoc @@ -6,30 +6,19 @@ [id="security-build-management_{context}"] = Managing builds -You can use Source-to-Image (S2I) to combine source code and base images. -_Builder images_ make use of S2I to enable your development and operations teams -to collaborate on a reproducible build environment. -With Red Hat S2I images available as Universal Base Image (UBI) images, -you can now freely redistribute your software with -base images built from real {op-system-base} RPM packages. -Red Hat has removed subscription restrictions to allow this. - -When developers commit code with Git for an application using build images, -{product-title} can perform the following functions: - -* Trigger, either by using webhooks on the code repository or other automated -continuous integration (CI) process, to automatically assemble a new image from -available artifacts, the S2I builder image, and the newly committed code. +[role="_abstract"] +You can use Source-to-Image (S2I) builder images that enable development and operations teams to collaborate on reproducible builds, using Red Hat Universal Base Images that you can freely redistribute with your applications. + +You can use Source-to-Image (S2I) to combine source code and base images. _Builder images_ make use of S2I to enable your development and operations teams to collaborate on a reproducible build environment. With Red Hat S2I images available as Universal Base Image (UBI) images, you can now freely redistribute your software with base images built from real {op-system-base} RPM packages. Red Hat has removed subscription restrictions to allow this. + +When developers commit code with Git for an application by using build images, {product-title} can perform the following functions: + +* Trigger, either by using webhooks on the code repository or other automated continuous integration (CI) process, to automatically assemble a new image from available artifacts, the S2I builder image, and the newly committed code. * Automatically deploy the newly built image for testing. -* Promote the tested image to production where it can be automatically deployed -using a CI process. +* Promote the tested image to production where it can be automatically deployed using a CI process. image::build_process1.png["Source-to-Image Builds", align="center"] -You can use the integrated OpenShift Container Registry to manage access to final images. -Both S2I and native build images are automatically pushed to your OpenShift Container -Registry. +You can use the integrated OpenShift Container Registry to manage access to final images. Both S2I and native build images are automatically pushed to your OpenShift Container Registry. -In addition to the included Jenkins for CI, you can also integrate your own -build and CI environment with {product-title} using RESTful APIs, as well as use -any API-compliant image registry. +In addition to the included Jenkins for CI, you can also integrate your own build and CI environment with {product-title} using RESTful APIs, and use any API-compliant image registry. diff --git a/modules/security-build-once.adoc b/modules/security-build-once.adoc index d5320acfae5d..62bff5e8586e 100644 --- a/modules/security-build-once.adoc +++ b/modules/security-build-once.adoc @@ -6,26 +6,26 @@ [id="security-build-once_{context}"] = Building once, deploying everywhere -Using {product-title} as the standard platform for container builds enables you -to guarantee the security of the build environment. Adhering to a "build once, -deploy everywhere" philosophy ensures that the product of the build process is -exactly what is deployed in production. +[role="_abstract"] +You can build container images once in a secure environment and deploy them unchanged across all stages. Using {product-title} as your build standard guarantees this security, ensuring production deployments match verified builds and preventing runtime vulnerabilities. -It is also important to maintain the immutability of your containers. You should -not patch running containers, but rebuild and redeploy them. +It is also important to maintain the immutability of your containers. You should not patch running containers, but rebuild and redeploy them. -As your software moves through the stages of building, testing, and production, it is -important that the tools making up your software supply chain be trusted. The -following figure illustrates the process and tools that could be incorporated -into a trusted software supply chain for containerized software: +As your software moves through the stages of building, testing, and production, it is important that the tools making up your software supply chain be trusted. The following figure illustrates the process and tools that could be incorporated into a trusted software supply chain for containerized software: image::trustedsupplychain.png["", align="center"] -{product-title} can be integrated with trusted code repositories (such as GitHub) -and development platforms (such as Che) for creating and managing secure code. -Unit testing could rely on -link:https://cucumber.io/[Cucumber] and link:https://junit.org/[JUnit]. +{product-title} can be integrated with trusted code repositories (such as GitHub) and development platforms (such as Che) for creating and managing secure code. Unit testing frameworks can validate code quality before builds. -You can inspect your containers for vulnerabilities and configuration issues at build, deploy, or runtime with https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]. For images stored in Quay, you can use the https://access.redhat.com/products/red-hat-quay[Clair scanner] to inspect images at rest. In addition, there are https://catalog.redhat.com/software/vulnerability-scanner/search[certified vulnerability scanners] available in the Red Hat ecosystem catalog. +You can inspect your containers for vulnerabilities and configuration issues at build, deploy, or runtime with Red Hat Advanced Cluster Security for Kubernetes. For images stored in Quay, you can use the Clair scanner to inspect images at rest. In addition, certified vulnerability scanners are available in the Red Hat ecosystem catalog. -Tools such as link:https://sysdig.com[Sysdig] can provide ongoing monitoring of your containerized applications. +Monitoring tools can provide ongoing visibility of your containerized applications. + +[role="_additional-resources"] +.Additional resources +* link:https://cucumber.io/[Cucumber] +* link:https://junit.org/[JUnit] +* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes] +* link:https://access.redhat.com/products/red-hat-quay[Clair scanner] +* link:https://catalog.redhat.com/software/vulnerability-scanner/search[Certified vulnerability scanners] +* link:https://sysdig.com[Sysdig] diff --git a/modules/security-deploy-continuous.adoc b/modules/security-deploy-continuous.adoc index c6f1e90b1e2c..fde01914cd43 100644 --- a/modules/security-deploy-continuous.adoc +++ b/modules/security-deploy-continuous.adoc @@ -6,6 +6,5 @@ [id="security-deploy-continuous_{context}"] = Automating continuous deployment -You can integrate your own continuous deployment (CD) tooling with {product-title}. - -By leveraging CI/CD and {product-title}, you can automate the process of rebuilding the application to incorporate the latest fixes, testing, and ensuring that it is deployed everywhere within the environment. +[role="_abstract"] +You can integrate your own continuous deployment (CD) tool with {product-title}. By leveraging continuous integration and continuous deployment (CI/CD) and {product-title}, you can automate the process of rebuilding the application to incorporate the latest fixes, testing, and ensuring that it is deployed everywhere within the environment. diff --git a/modules/security-deploy-image-sources.adoc b/modules/security-deploy-image-sources.adoc index f17c4e3c252c..2eb63fd93728 100644 --- a/modules/security-deploy-image-sources.adoc +++ b/modules/security-deploy-image-sources.adoc @@ -6,23 +6,13 @@ [id="security-deploy-image-sources_{context}"] = Controlling what image sources can be deployed -It is important that the intended images are actually being deployed, that the -images including the contained content -are from trusted sources, and they have not been altered. Cryptographic signing -provides this assurance. {product-title} enables cluster administrators to apply -security policy that is broad or narrow, reflecting deployment environment and -security requirements. Two parameters define this policy: +[role="_abstract"] +It is important that the intended images are actually being deployed, that the images including the contained content are from trusted sources, and they have not been altered. Cryptographic signing provides this assurance. {product-title} enables cluster administrators to apply security policy that is broad or narrow, reflecting deployment environment and security requirements. Two parameters define this policy: * one or more registries, with optional project namespace * trust type, such as accept, reject, or require public key(s) -You can use these policy parameters to allow, deny, or require a trust -relationship for entire registries, parts of registries, or individual -images. Using trusted public keys, you can ensure that the source is -cryptographically verified. -The policy rules apply to nodes. Policy may be -applied uniformly across all nodes or targeted for different node workloads (for -example, build, zone, or environment). +You can use these policy parameters to allow, deny, or require a trust relationship for entire registries, parts of registries, or individual images. Using trusted public keys, you can ensure that the source is cryptographically verified. The policy rules apply to nodes. Policy might be applied uniformly across all nodes or targeted for different node workloads (for example, build, zone, or environment). .Example image signature policy file [source,json] @@ -60,10 +50,7 @@ example, build, zone, or environment). } ---- -The policy can be saved onto a node as `/etc/containers/policy.json`. -Saving this file to a node is best accomplished using a new -`MachineConfig` object. This -example enforces the following rules: +The policy can be saved onto a node as `/etc/containers/policy.json`. Saving this file to a node is best accomplished using a new `MachineConfig` object. This example enforces the following rules: * Require images from the Red Hat Registry (`registry.access.redhat.com`) to be signed by the Red Hat public key. diff --git a/modules/security-deploy-secrets.adoc b/modules/security-deploy-secrets.adoc index ed5a11465188..83a53683c56c 100644 --- a/modules/security-deploy-secrets.adoc +++ b/modules/security-deploy-secrets.adoc @@ -6,14 +6,12 @@ [id="security-deploy-secrets_{context}"] = Creating secrets and config maps -The `Secret` object type provides a mechanism to hold sensitive information such -as passwords, {product-title} client configuration files, `dockercfg` files, -and private source repository credentials. Secrets decouple sensitive content -from pods. You can mount secrets into containers using a volume plugin or the -system can use secrets to perform actions on behalf of a pod. +[role="_abstract"] +The `Secret` object type provides a mechanism to hold sensitive information such as passwords, {product-title} client configuration files, `dockercfg` files, and private source repository credentials. Secrets decouple sensitive content from pods. You can mount secrets into containers by using a volume plugin or the system can use secrets to perform actions on behalf of a pod. -For example, to add a secret to your deployment configuration -so that it can access a private image repository, do the following: +Config maps are similar to secrets, but are designed to support working with strings that do not contain sensitive information. The `ConfigMap` object holds key-value pairs of configuration data that can be consumed in pods or used to store configuration data for system components such as controllers. + +For example, to add a secret to your deployment so that it can access a private image repository, do the following: .Procedure @@ -21,14 +19,6 @@ so that it can access a private image repository, do the following: . Create a new project. -. Navigate to *Resources* -> *Secrets* and create a new secret. Set `Secret Type` to -`Image Secret` and `Authentication Type` to `Image Registry Credentials` to -enter credentials for accessing a private image repository. - -. When creating a deployment configuration (for example, from the *Add to Project* -> -*Deploy Image* page), set the `Pull Secret` to your new secret. +. Navigate to *Resources* -> *Secrets* and create a new secret. Set `Secret Type` to `Image Secret` and `Authentication Type` to `Image Registry Credentials` to enter credentials for accessing a private image repository. -Config maps are similar to secrets, but are designed to support working with -strings that do not contain sensitive information. The `ConfigMap` object holds -key-value pairs of configuration data that can be consumed in pods or used to -store configuration data for system components such as controllers. +. When creating a deployment (for example, from the *Add to Project* -> *Deploy Image* page), set the `Pull Secret` to your new secret. diff --git a/modules/security-deploy-signature.adoc b/modules/security-deploy-signature.adoc index 7a59cea6a060..7d9c45f2b6c6 100644 --- a/modules/security-deploy-signature.adoc +++ b/modules/security-deploy-signature.adoc @@ -6,28 +6,17 @@ [id="security-deploy-signature_{context}"] = Using signature transports -A signature transport is a way to store and retrieve the binary signature blob. -There are two types of signature transports. +[role="_abstract"] +A signature transport is a way to store and retrieve the binary signature blob. There are two types of signature transports. * `atomic`: Managed by the {product-title} API. * `docker`: Served as a local file or by a web server. -The {product-title} API manages signatures that use the `atomic` transport type. -You must store the images that use this signature type in -your OpenShift Container Registry. Because the docker/distribution `extensions` API -auto-discovers the image signature endpoint, no additional -configuration is required. +The {product-title} API manages signatures that use the `atomic` transport type. You must store the images that use this signature type in your OpenShift Container Registry. Because the docker or distribution `extensions` API auto-discovers the image signature endpoint, no additional configuration is required. -Signatures that use the `docker` transport type are served by local file or web -server. These signatures are more flexible; you can serve images from any -container image registry and use an independent server to deliver binary -signatures. +Signatures that use the `docker` transport type are served by local file or web server. These signatures are more flexible; you can serve images from any container image registry and use an independent server to deliver binary signatures. -However, the `docker` transport type requires additional configuration. You must -configure the nodes with the URI of the signature server by placing -arbitrarily-named YAML files into a directory on the host system, -`/etc/containers/registries.d` by default. The YAML configuration files contain a -registry URI and a signature server URI, or _sigstore_: +However, the `docker` transport type requires additional configuration. You must configure the nodes with the Uniform Resource Identifier (URI) of the signature server by placing arbitrarily-named YAML files into a directory on the host system, `/etc/containers/registries.d` by default. The YAML configuration files contain a registry URI and a signature server URI, or _sigstore_: .Example registries.d file [source,yaml] @@ -37,11 +26,4 @@ docker: sigstore: https://access.redhat.com/webassets/docker/content/sigstore ---- -In this example, the Red Hat Registry, `access.redhat.com`, is the signature -server that provides signatures for the `docker` transport type. Its URI is -defined in the `sigstore` parameter. You might name this file -`/etc/containers/registries.d/redhat.com.yaml` and use the Machine Config -Operator to -automatically place the file on each node in your cluster. No service -restart is required since policy and `registries.d` files are dynamically -loaded by the container runtime. +In this example, the Red Hat Registry, `access.redhat.com`, is the signature server that provides signatures for the `docker` transport type. Its URI is defined in the `sigstore` parameter. You might name this file `/etc/containers/registries.d/redhat.com.yaml` and use the Machine Config Operator to automatically place the file on each node in your cluster. No service restart is required since policy and `registries.d` files are dynamically loaded by the container runtime. diff --git a/modules/security-deploy-trigger.adoc b/modules/security-deploy-trigger.adoc index 7d6220c1ae28..a247191f9be0 100644 --- a/modules/security-deploy-trigger.adoc +++ b/modules/security-deploy-trigger.adoc @@ -6,25 +6,14 @@ [id="security-deploy-trigger_{context}"] = Controlling container deployments with triggers -If something happens during the build process, or if a vulnerability is -discovered after an image has been deployed, you can use tooling for automated, -policy-based deployment to remediate. You can use triggers to rebuild and replace images, -ensuring the immutable containers process, -instead of patching running containers, which is not recommended. +[role="_abstract"] +If something happens during the build process, or if a vulnerability is discovered after an image has been deployed, you can use tool for automated, policy-based deployment to remediate. You can use triggers to rebuild and replace images, ensuring the immutable containers process, instead of patching running containers, which is not recommended. image::secure_deployments.png["Secure Deployments", align="center"] -For example, you build an application using three container image layers: core, -middleware, and applications. An issue is discovered in the core image and that -image is rebuilt. After the build is complete, the image is pushed to your -OpenShift Container Registry. {product-title} detects that the image has changed -and automatically rebuilds and deploys the application image, based on the -defined triggers. This change incorporates the fixed libraries and ensures that -the production code is identical to the most current image. +For example, you build an application by using three container image layers: core, middleware, and applications. An issue is discovered in the core image and that image is rebuilt. After the build is complete, the image is pushed to your OpenShift Container Registry. {product-title} detects that the image has changed and automatically rebuilds and deploys the application image, based on the defined triggers. This change incorporates the fixed libraries and ensures that the production code is identical to the most current image. -You can use the `oc set triggers` command to set a deployment trigger. -For example, to set a trigger for a deployment called -deployment-example: +You can use the `oc set triggers` command to set a deployment trigger. For example, to set a trigger for a deployment called deployment-example: [source,terminal] ---- diff --git a/modules/security-storage-block.adoc b/modules/security-storage-block.adoc index a8dc74230ebb..347e87ef00a6 100644 --- a/modules/security-storage-block.adoc +++ b/modules/security-storage-block.adoc @@ -6,4 +6,5 @@ [id="security-network-storage-block_{context}"] = Block storage -For block storage providers like AWS Elastic Block Store (EBS), GCE Persistent Disks, and iSCSI, {product-title} uses SELinux capabilities to secure the root of the mounted volume for non-privileged pods, making the mounted volume owned by and only visible to the container with which it is associated. +[role="_abstract"] +For block storage providers such as AWS Elastic Block Store (EBS), Google Compute Engine (GCE) Persistent Disks, and Internet Small Computer Systems Interface (iSCSI), {product-title} uses Security-Enhanced Linux (SELinux) capabilities to secure the root of the mounted volume for non-privileged pods, making the mounted volume owned by and only visible to the container with which it is associated. diff --git a/modules/security-storage-persistent.adoc b/modules/security-storage-persistent.adoc index 19909043380f..b5f46d2c68a4 100644 --- a/modules/security-storage-persistent.adoc +++ b/modules/security-storage-persistent.adoc @@ -2,14 +2,12 @@ // // * security/container_security/security-storage.adoc -:_mod-docs-content-type: REFERENCE +:_mod-docs-content-type: CONCEPT [id="security-network-storage-persistent_{context}"] = Persistent volume plugins -Containers are useful for both stateless and stateful applications. -Protecting attached storage is a key element of securing stateful services. -Using the Container Storage Interface (CSI), {product-title} can -incorporate storage from any storage back end that supports the CSI interface. +[role="_abstract"] +Containers are useful for both stateless and stateful applications. Protecting attached storage is a key element of securing stateful services. Using the Container Storage Interface (CSI), {product-title} can incorporate storage from any storage back end that supports the CSI interface. {product-title} provides plugins for multiple types of storage, including: @@ -19,23 +17,15 @@ incorporate storage from any storage back end that supports the CSI interface. * Azure Disk * * Azure File * * OpenStack Cinder * -* GCE Persistent Disks * +* Google Compute Engine (GCE) Persistent Disks * * VMware vSphere * * Network File System (NFS) * FlexVolume * Fibre Channel -* iSCSI +* Internet Small Computer Systems Interface (iSCSI) -Plugins for those storage types with dynamic provisioning are marked with -an asterisk (*). Data in transit is encrypted via HTTPS for all -{product-title} components communicating with each other. +Plugins for those storage types with dynamic provisioning are marked with an asterisk (*). Data in transit is encrypted via HTTPS for all {product-title} components communicating with each other. -You can mount a persistent volume (PV) on a host in any way supported by your -storage type. Different types of storage have different capabilities and each -PV's access modes are set to the specific modes supported by that particular -volume. +You can mount a persistent volume (PV) on a host in any way supported by your storage type. Different types of storage have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume. -For example, NFS can support multiple read/write clients, but a specific NFS PV -might be exported on the server as read-only. Each PV has its own set of access -modes describing that specific PV's capabilities, such as `ReadWriteOnce`, -`ReadOnlyMany`, and `ReadWriteMany`. +For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV has its own set of access modes describing that specific PV's capabilities, such as `ReadWriteOnce`, `ReadOnlyMany`, and `ReadWriteMany`. diff --git a/modules/security-storage-shared.adoc b/modules/security-storage-shared.adoc index 86380503056f..b3cc833f2bd4 100644 --- a/modules/security-storage-shared.adoc +++ b/modules/security-storage-shared.adoc @@ -6,5 +6,5 @@ [id="security-network-storage-shared_{context}"] = Shared storage -For shared storage providers like NFS, the PV registers its -group ID (GID) as an annotation on the PV resource. Then, when the PV is claimed by the pod, the annotated GID is added to the supplemental groups of the pod, giving that pod access to the contents of the shared storage. +[role="_abstract"] +For shared storage providers such as Network File System (NFS), the persistent volume (PV) registers its group ID (GID) as an annotation on the PV resource. Then, when the PV is claimed by the pod, the annotated GID is added to the supplemental groups of the pod, giving that pod access to the contents of the shared storage. diff --git a/modules/security-understanding-containers.adoc b/modules/security-understanding-containers.adoc index 0d2254bdd390..bc24c5866db0 100644 --- a/modules/security-understanding-containers.adoc +++ b/modules/security-understanding-containers.adoc @@ -6,18 +6,18 @@ [id="security-understanding-containers_{context}"] = What are containers? -Containers package an application and all its dependencies into a single image -that can be promoted from development, to test, to production, without change. -A container might be part of a larger application that works closely with other -containers. +[role="_abstract"] +Containers package applications and their dependencies into single, portable images that enable consistent deployment across development, test, and production environments. -Containers provide consistency across environments and multiple deployment -targets: physical servers, virtual machines (VMs), and private or public cloud. +The image can be promoted from development, to test, to production, without change. A container might be part of a larger application that works closely with other containers. + +Containers provide consistency across environments and multiple deployment targets: physical servers, virtual machines (VMs), and private or public cloud. Some of the benefits of using containers include: // image::whatarecontainers.png["What Are Containers?", align="center"] +.Container benefits [options="header"] |=== |Infrastructure |Applications @@ -32,6 +32,7 @@ Some of the benefits of using containers include: |Easily access and share containerized components |=== -See link:https://www.redhat.com/en/topics/containers[Understanding Linux containers] from the Red Hat Customer Portal -to find out more about Linux containers. To learn about RHEL container tools, see -link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index[Building, running, and managing containers] in the RHEL product documentation. +[role="_additional-resources"] +.Additional resources +* link:https://www.redhat.com/en/topics/containers[Understanding Linux containers] +* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index[Building, running, and managing containers] diff --git a/modules/security-understanding-openshift.adoc b/modules/security-understanding-openshift.adoc index b437ebf7d880..2c9f436ad071 100644 --- a/modules/security-understanding-openshift.adoc +++ b/modules/security-understanding-openshift.adoc @@ -6,15 +6,13 @@ [id="security-understanding-openshift_{context}"] = What is {product-title}? -Automating how containerized applications are deployed, run, and managed is the job of a platform such as {product-title}. At its core, {product-title} relies on the Kubernetes project to provide the engine for orchestrating containers -across many nodes in scalable data centers. +[role="_abstract"] +{product-title} automates the deployment, operation, and management of containerized applications by using Kubernetes as its orchestration engine, enhanced with Red Hat security, support, and enterprise features. + +Automating how containerized applications are deployed, run, and managed is the job of a platform such as {product-title}. At its core, {product-title} relies on the Kubernetes project to provide the engine for orchestrating containers across many nodes in scalable data centers. Kubernetes is a project, which can run using different operating systems and add-on components that offer no guarantees of supportability from the project. As a result, the security of different Kubernetes platforms can vary. -{product-title} is designed to lock down Kubernetes security and integrate the platform with a variety of extended components. To do this, -{product-title} draws on the extensive Red Hat ecosystem of open source technologies that include the operating systems, authentication, storage, -networking, development tools, base container images, and many other components. +{product-title} is designed to lock down Kubernetes security and integrate the platform with a variety of extended components. To do this, {product-title} draws on the extensive Red Hat ecosystem of open source technologies that include the operating systems, authentication, storage, networking, development tools, base container images, and many other components. -{product-title} can leverage Red Hat's experience in uncovering and rapidly deploying fixes for vulnerabilities in the platform itself -as well as the containerized applications running on the platform. Red Hat's experience also extends to efficiently integrating new -components with {product-title} as they become available and adapting technologies to individual customer needs. +{product-title} can use Red Hat's experience in uncovering and rapidly deploying fixes for vulnerabilities in the platform itself and the containerized applications running on the platform. Red Hat's experience also extends to efficiently integrating new components with {product-title} as they become available and adapting technologies to individual customer needs. diff --git a/security/container_security/security-build.adoc b/security/container_security/security-build.adoc index 86c028196d21..3412726c7c64 100644 --- a/security/container_security/security-build.adoc +++ b/security/container_security/security-build.adoc @@ -6,9 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -In a container environment, the software build process is the stage in the life -cycle where application code is integrated with the required runtime libraries. -Managing this build process is key to securing the software stack. +[role="_abstract"] +You can secure your software supply chain by using trusted base images, integrating security testing, and building once to deploy everywhere. Managing this build process ensures production deployments match verified builds and protects the software stack where code and libraries integrate. // Build once, deploy everywhere include::modules/security-build-once.adoc[leveloffset=+1] diff --git a/security/container_security/security-deploy.adoc b/security/container_security/security-deploy.adoc index 158d0a6f72da..b47c609374de 100644 --- a/security/container_security/security-deploy.adoc +++ b/security/container_security/security-deploy.adoc @@ -6,11 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -You can use a variety of techniques to make sure that the containers you -deploy hold the latest production-quality content and that they have not -been tampered with. These techniques include setting up build triggers to -incorporate the latest code and using signatures to ensure that the container -comes from a trusted source and has not been modified. +[role="_abstract"] +You can use a variety of techniques to make sure that the containers you deploy hold the latest production-quality content and that they have not been tampered with. These techniques include setting up build triggers to incorporate the latest code and using signatures to ensure that the container comes from a trusted source and has not been modified. // Controlling container deployments with triggers include::modules/security-deploy-trigger.adoc[leveloffset=+1] diff --git a/security/container_security/security-storage.adoc b/security/container_security/security-storage.adoc index 5642a14962f8..906828be56d9 100644 --- a/security/container_security/security-storage.adoc +++ b/security/container_security/security-storage.adoc @@ -6,10 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -{product-title} supports multiple types of storage, both -for on-premise and cloud providers. In particular, -{product-title} can use storage types that support the Container -Storage Interface. +[role="_abstract"] +You can understand how {product-title} secures attached storage to protect persistent data in containerized workloads. {product-title} uses Security-Enhanced Linux (SELinux) capabilities, group ID (GID) annotations, and Container Storage Interface (CSI)-compliant storage providers to isolate storage access and prevent unauthorized data exposure. // Persistent volume plugins include::modules/security-storage-persistent.adoc[leveloffset=+1] @@ -23,8 +21,8 @@ include::modules/security-storage-block.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources * xref:../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage] -* xref:../../storage/container_storage_interface/persistent-storage-csi.adoc#persistent-storage-using-csi[Configuring CSI volumes] +* xref:../../storage/container_storage_interface/persistent-storage-csi.adoc#persistent-storage-csi[Configuring CSI volumes] * xref:../../storage/dynamic-provisioning.adoc#dynamic-provisioning[Dynamic provisioning] * xref:../../storage/persistent_storage/persistent-storage-nfs.adoc#persistent-storage-using-nfs[Persistent storage using NFS] -* xref:../../storage/persistent_storage/persistent-storage-aws.adoc#persistent-storage-using-aws-ebs[Persistent storage using AWS Elastic Block Store] +* xref:../../storage/persistent_storage/persistent-storage-aws.adoc#persistent-storage-aws[Persistent storage using AWS Elastic Block Store] * xref:../../storage/persistent_storage/persistent-storage-gce.adoc#persistent-storage-using-gce[Persistent storage using GCE Persistent Disk] diff --git a/security/container_security/security-understanding.adoc b/security/container_security/security-understanding.adoc index e3cb44d56832..f85d7a6c3d09 100644 --- a/security/container_security/security-understanding.adoc +++ b/security/container_security/security-understanding.adoc @@ -6,55 +6,37 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] +You can understand how {product-title} secures containerized workloads across multiple layers host, container orchestration, build, and application to help you meet your organization's security requirements and compliance standards. + Securing a containerized application relies on multiple levels of security: -* Container security begins with a trusted base container image and continues -through the container build process as it moves through your CI/CD pipeline. +* Container security begins with a trusted base container image and continues through the container build process as it moves through your CI/CD pipeline. + [IMPORTANT] ==== -Image streams by default do not automatically update. This default behavior might create a security issue because security updates to images referenced by an image stream do not automatically occur. -For information about how to override this default behavior, see xref:../../openshift_images/image-streams-manage.adoc#images-imagestreams-import_image-streams-managing[Configuring periodic importing of imagestreamtags]. +Image streams by default do not automatically update. This default behavior might create a security issue because security updates to images referenced by an image stream do not automatically occur. You can configure periodic importing to ensure your image streams receive security updates. ==== -* When a container is deployed, its security depends on it running -on secure operating systems and networks, and -establishing firm boundaries between the container itself and -the users and hosts that interact with it. -* Continued security relies on being able to scan container images for -vulnerabilities and having an efficient way to correct and -replace vulnerable images. +* When a container is deployed, its security depends on it running on secure operating systems and networks, and establishing firm boundaries between the container itself and the users and hosts that interact with it. +* Continued security relies on being able to scan container images for vulnerabilities and having an efficient way to correct and replace vulnerable images. -Beyond what a platform such as {product-title} offers out of the box, -your organization will likely have its own security demands. Some level -of compliance verification might be needed before you can even bring -{product-title} into your data center. +Beyond what a platform such as {product-title} offers out of the box, your organization will likely have its own security demands. Some level of compliance verification might be needed before you can even bring {product-title} into your data center. -Likewise, you may need to add your own agents, specialized hardware drivers, -or encryption features to {product-title}, before it can meet your -organization's security standards. +Likewise, you might need to add your own agents, specialized hardware drivers, or encryption features to {product-title}, before it can meet your organization's security standards. -This guide provides a high-level walkthrough of the container security measures -available in {product-title}, including solutions for the host layer, the -container and orchestration layer, and the build and application layer. -It then points you to specific {product-title} documentation to -help you achieve those security measures. +This guide provides a high-level walkthrough of the container security measures available in {product-title}, including solutions for the host layer, the container and orchestration layer, and the build and application layer. It then points you to specific {product-title} documentation to help you achieve those security measures. This guide contains the following information: * Why container security is important and how it compares with existing security standards. -* Which container security measures are provided by the host ({op-system} and {op-system-base}) layer and -which are provided by {product-title}. +* Which container security measures are provided by the host ({op-system} and {op-system-base}) layer and which are provided by {product-title}. * How to evaluate your container content and sources for vulnerabilities. * How to design your build and deployment process to proactively check container content. * How to control access to containers through authentication and authorization. * How networking and attached storage are secured in {product-title}. * Containerized solutions for API management and SSO. -The goal of this guide is to understand the incredible security benefits of -using {product-title} for your containerized workloads and how the entire -Red Hat ecosystem plays a part in making and keeping containers secure. -It will also help you understand how you can engage with the {product-title} -to achieve your organization's security goals. +The goal of this guide is to understand the incredible security benefits of using {product-title} for your containerized workloads and how the entire Red Hat ecosystem plays a part in making and keeping containers secure. It will also help you understand how you can engage with the {product-title} to achieve your organization's security goals. // What are containers? include::modules/security-understanding-containers.adoc[leveloffset=+1] @@ -64,5 +46,6 @@ include::modules/security-understanding-openshift.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources +* xref:../../openshift_images/image-streams-manage.adoc#images-imagestreams-import_image-streams-managing[Configuring periodic importing of imagestreamtags] * xref:../../architecture/architecture.adoc#architecture[{product-title} architecture] * link:https://www.redhat.com/en/resources/openshift-security-guide-ebook[OpenShift Security Guide]