diff --git a/modules/security-compliance-nist.adoc b/modules/security-compliance-nist.adoc index 78f47db787fd..4d5122c98362 100644 --- a/modules/security-compliance-nist.adoc +++ b/modules/security-compliance-nist.adoc @@ -6,14 +6,11 @@ [id="security-compliance-nist_{context}"] = Understanding compliance and risk management +[role="_abstract"] ifndef::openshift-origin[] -FIPS compliance is one of the most critical components required in -highly secure environments, to ensure that only supported cryptographic -technologies are allowed on nodes. +FIPS compliance is one of the most critical components required in highly secure environments to ensure that only supported cryptographic technologies are allowed on nodes. include::snippets/fips-snippet.adoc[] endif::openshift-origin[] -To understand Red Hat's view of {product-title} compliance frameworks, refer -to the Risk Management and Regulatory Readiness chapter of the -link:https://access.redhat.com/articles/5059881[OpenShift Security Guide Book]. +To understand Red Hat's view of {product-title} compliance frameworks, refer to the Risk Management and Regulatory Readiness chapter of the OpenShift Security Guide Book. diff --git a/modules/security-hosts-vms-openshift.adoc b/modules/security-hosts-vms-openshift.adoc index fd48060dd1e7..9c83d7d908c2 100644 --- a/modules/security-hosts-vms-openshift.adoc +++ b/modules/security-hosts-vms-openshift.adoc @@ -6,31 +6,22 @@ [id="security-hosts-vms-openshift_{context}"] = Securing {product-title} -When you deploy {product-title}, you have the choice of an -installer-provisioned infrastructure (there are several available platforms) -or your own user-provisioned infrastructure. +[role="_abstract"] +When you deploy {product-title}, you have the choice of an installer-provisioned infrastructure (there are several available platforms) or your own user-provisioned infrastructure. ifndef::openshift-origin[] -Some low-level security-related configuration, such as enabling FIPS -mode or adding kernel modules required at first boot, might -benefit from a user-provisioned infrastructure. +Some low-level security-related configuration, such as enabling FIPS mode or adding kernel modules required at first boot, might benefit from a user-provisioned infrastructure. endif::[] ifdef::openshift-origin[] -Some low-level security-related configuration, such as adding kernel modules required at first boot, might -benefit from a user-provisioned infrastructure. +Some low-level security-related configuration, such as adding kernel modules required at first boot, might benefit from a user-provisioned infrastructure. endif::[] Likewise, user-provisioned infrastructure is appropriate for disconnected {product-title} deployments. -Keep in mind that, when it comes to making security enhancements and other -configuration changes to {product-title}, the goals should include: +Remember when it comes to making security enhancements and other configuration changes to {product-title}, the goals should include: -* Keeping the underlying nodes as generic as possible. You want to be able to -easily throw away and spin up similar nodes quickly and in prescriptive ways. -* Managing modifications to nodes through {product-title} as much as possible, -rather than making direct, one-off changes to the nodes. +* Keeping the underlying nodes as generic as possible. You want to be able to easily throw away and spin up similar nodes quickly and in prescriptive ways. +* Managing modifications to nodes through {product-title} as much as possible, rather than making direct, one-off changes to the nodes. -In pursuit of those goals, most node changes should be done during installation through Ignition -or later using MachineConfigs that are applied to sets of nodes by the Machine Config Operator. -Examples of security-related configuration changes you can do in this way include: +In pursuit of those goals, most node changes should be done during installation through Ignition or later using MachineConfigs that are applied to sets of nodes by the Machine Config Operator. Examples of security-related configuration changes you can do in this way include: * Adding kernel arguments @@ -42,5 +33,4 @@ Examples of security-related configuration changes you can do in this way includ * Configuring the chrony time service -Besides the Machine Config Operator, there are several other Operators available to configure {product-title} infrastructure that are managed by the Cluster Version Operator (CVO). The CVO is able to automate many aspects of -{product-title} cluster updates. +Besides the Machine Config Operator, there are several other Operators available to configure {product-title} infrastructure that are managed by the Cluster Version Operator (CVO). The CVO is able to automate many aspects of {product-title} cluster updates. diff --git a/modules/security-hosts-vms-rhcos.adoc b/modules/security-hosts-vms-rhcos.adoc index bb0d9e6f86ae..26018672d8fd 100644 --- a/modules/security-hosts-vms-rhcos.adoc +++ b/modules/security-hosts-vms-rhcos.adoc @@ -6,16 +6,14 @@ [id="security-hosts-vms-rhcos_{context}"] = Securing containers on {op-system-first} +[role="_abstract"] Containers simplify the act of deploying many applications to run on the same host, using the same kernel and container runtime to spin up each container. The applications can be owned by many users and, because they are kept separate, can run different, and even incompatible, versions of those applications at the same time without issue. -In Linux, containers are just a special type of process, so securing containers is similar in many ways to securing any other running process. An environment for running containers starts with an operating system that can secure the host kernel from containers and other processes running on the host, as well as secure containers from each other. +In Linux, containers are just a special type of process, so securing containers is similar in many ways to securing any other running process. An environment for running containers starts with an operating system that can secure the host kernel from containers and other processes running on the host, and secure containers from each other. Because {product-title} {product-version} runs on {op-system} hosts, with the option of using {op-system-base-full} as worker nodes, the following concepts apply by default to any deployed {product-title} cluster. These {op-system-base} security features are at the core of what makes running containers in {product-title} more secure: * _Linux namespaces_ enable creating an abstraction of a particular global system resource to make it appear as a separate instance to processes within a namespace. Consequently, several containers can use the same computing resource simultaneously without creating a conflict. Container namespaces that are separate from the host by default include mount table, process table, network interface, user, control group, UTS, and IPC namespaces. Those containers that need direct access to host namespaces need to have elevated permissions to request that access. -ifdef::openshift-enterprise,openshift-webscale,openshift-aro[] -See link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/building_running_and_managing_containers/index[Building, running, and managing containers] from the {op-system-base} 9 container documentation for details on the types of namespaces. -endif::[] * _SELinux_ provides an additional layer of security to keep containers isolated from each other and from the host. SELinux allows administrators to enforce mandatory access controls (MAC) for every user, application, process, and file. @@ -24,11 +22,11 @@ endif::[] Disabling SELinux on {op-system} is not supported. ==== -* _CGroups_ (control groups) limit, account for, and isolate the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes. CGroups are used to ensure that containers on the same host are not impacted by each other. +* _CGroups_ (control groups) limit, account for, and isolate the resource usage (CPU, memory, disk I/O, network, and so on.) of a collection of processes. CGroups are used to ensure that containers on the same host are not impacted by each other. -* _Secure computing mode (seccomp)_ profiles can be associated with a container to restrict available system calls. See page 94 of the link:https://www.redhat.com/en/resources/openshift-security-guide-ebook[Red Hat OpenShift security guide] for details about seccomp. +* _Secure computing mode (seccomp)_ profiles can be associated with a container to restrict available system calls. -* Deploying containers using _{op-system}_ reduces the attack surface by minimizing the host environment and tuning it for containers. The link:https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cri-o_runtime/index[CRI-O container engine] further reduces that attack surface by implementing only those features required by Kubernetes and {product-title} to run and manage containers, as opposed to other container engines that implement desktop-oriented standalone features. +* Deploying containers using _{op-system}_ reduces the attack surface by minimizing the host environment and tuning it for containers. The CRI-O container engine further reduces that attack surface by implementing only those features required by Kubernetes and {product-title} to run and manage containers, as opposed to other container engines that implement desktop-oriented standalone features. {op-system} is a version of {op-system-base-full} that is specially configured to work as control plane (master) and worker nodes on {product-title} clusters. So {op-system} is tuned to efficiently run container workloads, along with Kubernetes and {product-title} services. diff --git a/modules/security-hosts-vms-vs-containers.adoc b/modules/security-hosts-vms-vs-containers.adoc index 507b14d623a9..e962172cbd29 100644 --- a/modules/security-hosts-vms-vs-containers.adoc +++ b/modules/security-hosts-vms-vs-containers.adoc @@ -6,31 +6,12 @@ [id="security-hosts-vms-vs-containers_{context}"] = Comparing virtualization and containers -Traditional virtualization provides another way to keep application -environments separate on the same physical host. However, virtual machines -work in a different way than containers. -Virtualization relies on a hypervisor spinning up guest -virtual machines (VMs), each of which has its own operating system (OS), -represented by a running kernel, as well as the running application and its dependencies. +[role="_abstract"] +Traditional virtualization provides another way to keep application environments separate on the same physical host. However, virtual machines work in a different way than containers. Virtualization relies on a hypervisor spinning up guest virtual machines (VMs), each of which has its own operating system (OS), represented by a running kernel, and the running application and its dependencies. -With VMs, the hypervisor isolates the guests from each other and from the host -kernel. Fewer individuals and processes have access to the hypervisor, reducing -the attack surface on the physical server. That said, security must still be -monitored: one guest VM might be able to use hypervisor bugs to gain access to -another VM or the host kernel. And, when the OS needs to be patched, it must be -patched on all guest VMs using that OS. +With VMs, the hypervisor isolates the guests from each other and from the host kernel. Fewer individuals and processes have access to the hypervisor, reducing the attack surface on the physical server. That said, security must still be monitored: one guest VM might be able to use hypervisor bugs to gain access to another VM or the host kernel. And, when the operating system needs to be patched, it must be patched on all guest VMs by using that operating system. -Containers can be run inside guest VMs, and there might be use cases where this is -desirable. For example, you might be deploying a traditional application in a -container, perhaps to lift-and-shift an application to the cloud. +Containers can be run inside guest VMs, and there might be use cases where this is desirable. For example, you might be deploying a traditional application in a container, perhaps to lift-and-shift an application to the cloud. -Container separation on a single host, however, provides a more lightweight, -flexible, and easier-to-scale deployment solution. This deployment model is -particularly appropriate for cloud-native applications. Containers are -generally much smaller than VMs and consume less memory and CPU. - -ifndef::openshift-origin[] -See link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/overview_of_containers_in_red_hat_systems/introduction_to_linux_containers#linux_containers_compared_to_kvm_virtualization[Linux Containers Compared to KVM Virtualization] -in the {op-system-base} 7 container documentation to learn about the differences between container and VMs. -endif::[] +Container separation on a single host, however, provides a more lightweight, flexible, and easier-to-scale deployment solution. This deployment model is particularly appropriate for cloud-native applications. Containers are generally much smaller than VMs and consume less memory and CPU. diff --git a/modules/security-platform-admission.adoc b/modules/security-platform-admission.adoc index 72ac9ffa206e..687de042a07f 100644 --- a/modules/security-platform-admission.adoc +++ b/modules/security-platform-admission.adoc @@ -6,11 +6,12 @@ [id="security-platform-admission_{context}"] = Protecting control plane with admission plugins +[role="_abstract"] While RBAC controls access rules between users and groups and available projects, _admission plugins_ define access to the {product-title} master API. Admission plugins form a chain of rules that consist of: * Default admissions plugins: These implement a default set of policies and resources limits that are applied to components of the {product-title} control plane. -* Mutating admission plugins: These plugins dynamically extend the admission chain. They call out to a webhook server and can both authenticate a request and modify the selected resource. +* Mutating admission plugins: These plugins dynamically extend the admission chain. They callout to a webhook server and can both authenticate a request and modify the selected resource. * Validating admission plugins: These validate requests for a selected resource and can both validate the request and ensure that the resource does not change again. @@ -34,12 +35,10 @@ If you have the required permissions, you can adjust the default SCC policies to [id="security-service-account_{context}"] == Granting roles to service accounts -You can assign roles to service accounts, in the same way that users are assigned role-based access. -There are three default service accounts created for each project. A service account: +You can assign roles to service accounts, in the same way that users are assigned role-based access. There are three default service accounts created for each project. A service account: * is limited in scope to a particular project * derives its name from its project -* is automatically assigned an API token and credentials to access the -OpenShift Container Registry +* is automatically assigned an API token and credentials to access the OpenShift Container Registry Service accounts associated with platform components automatically have their keys rotated. diff --git a/modules/security-platform-authentication.adoc b/modules/security-platform-authentication.adoc index 00157cdb36d8..661fddacfb08 100644 --- a/modules/security-platform-authentication.adoc +++ b/modules/security-platform-authentication.adoc @@ -2,61 +2,36 @@ // // * security/container_security/security-platform.adoc -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: CONCEPT [id="security-platform-authentication_{context}"] = Authentication and authorization [id="security-platform-auth-controlling-access_{context}"] == Controlling access using OAuth -You can use API access control via authentication and authorization for securing -your container platform. The {product-title} master includes a built-in OAuth -server. Users can obtain OAuth access tokens to authenticate themselves to the -API. +[role="_abstract"] +You can use API access control via authentication and authorization for securing your container platform. The {product-title} master includes a built-in OAuth server. Users can obtain OAuth access tokens to authenticate themselves to the API. -As an administrator, you can configure OAuth to authenticate using an _identity -provider_, such as LDAP, GitHub, or Google. The -identity provider is used by default for new {product-title} deployments, but -you can configure this at initial installation time or postinstallation. +As an administrator, you can configure OAuth to authenticate using an _identity provider_, such as LDAP, GitHub, or Google. The identity provider is used by default for new {product-title} deployments, but you can configure this at initial installation time or postinstallation. [id="security-platform-api-access-control_{context}"] == API access control and management -Applications can have multiple, independent API services which have different -endpoints that require management. {product-title} includes a containerized -version of the 3scale API gateway so that you can manage your APIs and control -access. +Applications can have multiple, independent API services which have different endpoints that require management. {product-title} includes a containerized version of the 3scale API gateway so that you can manage your APIs and control access. -3scale gives you a variety of standard options for API authentication and -security, which can be used alone or in combination to issue credentials and -control access: standard API keys, application ID and key pair, and OAuth 2.0. +3scale gives you a variety of standard options for API authentication and security, which can be used alone or in combination to issue credentials and control access: standard API keys, application ID and key pair, and OAuth 2.0. -You can restrict access to specific endpoints, methods, and services and apply -access policy for groups of users. Application plans allow you to set rate -limits for API usage and control traffic flow for groups of developers. - -For a tutorial on using APIcast v2, the containerized 3scale API Gateway, see -link:https://access.redhat.com/documentation/en-us/red_hat_3scale_api_management/2.0/html/deployment_options/apicast-openshift[Running APIcast on Red Hat OpenShift] -in the 3scale documentation. +You can restrict access to specific endpoints, methods, and services and apply access policy for groups of users. Application plans allow you to set rate limits for API usage and control traffic flow for groups of developers. [id="security-platform-red-hat-sso_{context}"] == Red Hat Single Sign-On -The Red Hat Single Sign-On server enables you to secure your -applications by providing web single sign-on capabilities based on standards, including -SAML 2.0, OpenID Connect, and OAuth 2.0. The server can act as a SAML or OpenID -Connect–based identity provider (IdP), mediating with your enterprise user -directory or third-party identity provider for identity information and your -applications using standards-based tokens. You can integrate Red Hat Single Sign-On with -LDAP-based directory services including Microsoft Active Directory and Red Hat -Enterprise Linux Identity Management. +The Red Hat Single Sign-On server enables you to secure your applications by providing web single sign-on capabilities based on standards, including SAML 2.0, OpenID Connect, and OAuth 2.0. The server can act as a SAML or OpenID Connect–based identity provider (IdP), mediating with your enterprise user directory or third-party identity provider for identity information and your applications using standards-based tokens. You can integrate Red Hat Single Sign-On with LDAP-based directory services including Microsoft Active Directory and Red Hat Enterprise Linux Identity Management. [id="security-platform-auth-secure-self-service-web-console_{context}"] == Secure self-service web console -{product-title} provides a self-service web console to ensure that teams do not -access other environments without authorization. {product-title} ensures a -secure multitenant master by providing the following: +{product-title} provides a self-service web console to ensure that teams do not access other environments without authorization. {product-title} ensures a secure multitenant master by providing the following: - Access to the master uses Transport Layer Security (TLS) - Access to the API Server uses X.509 certificates or OAuth access tokens diff --git a/modules/security-platform-certificates.adoc b/modules/security-platform-certificates.adoc index 84d5f6f21cfa..6f1e5289085a 100644 --- a/modules/security-platform-certificates.adoc +++ b/modules/security-platform-certificates.adoc @@ -2,10 +2,11 @@ // // * security/container_security/security-platform.adoc -:_mod-docs-content-type: CONCEPT +:_mod-docs-content-type: CONCEPT [id="security-platform-certificates_{context}"] = Managing certificates for the platform +[role="_abstract"] {product-title} has multiple components within its framework that use REST-based HTTPS communication leveraging encryption via TLS certificates. {product-title}'s installer configures these certificates during installation. There are some primary components that generate this traffic: * masters (API server and controllers) diff --git a/modules/security-platform-multi-tenancy.adoc b/modules/security-platform-multi-tenancy.adoc index 4aedc0bebe21..2e9e7e0b2fab 100644 --- a/modules/security-platform-multi-tenancy.adoc +++ b/modules/security-platform-multi-tenancy.adoc @@ -6,9 +6,8 @@ [id="security-platform-multi-tenancy_{context}"] = Isolating containers with multitenancy -Multitenancy allows applications on an {product-title} cluster that are owned by multiple users, and run across multiple hosts and namespaces, -to remain isolated from each other and from outside attacks. You obtain multitenancy by applying role-based access control (RBAC) -to Kubernetes namespaces. +[role="_abstract"] +Multitenancy allows applications on an {product-title} cluster that are owned by multiple users, and run across multiple hosts and namespaces, to remain isolated from each other and from outside attacks. You obtain multitenancy by applying role-based access control (RBAC) to Kubernetes namespaces. In Kubernetes, _namespaces_ are areas where applications can run in ways that are separate from other applications. {product-title} uses and extends namespaces by adding extra annotations, including MCS labeling in SELinux, and identifying these extended namespaces as _projects_. Within the scope of a project, users can maintain their own cluster resources, including service accounts, policies, constraints, and various other objects. @@ -18,5 +17,4 @@ RBAC objects are assigned to projects to authorize selected users to have access * Roles are collections of rules that you can bind to selected users or groups. * Bindings define the association between users or groups and roles. -Local RBAC roles and bindings attach a user or group to a particular project. Cluster RBAC can attach cluster-wide roles and bindings -to all projects in a cluster. There are default cluster roles that can be assigned to provide `admin`, `basic-user`, `cluster-admin`, and `cluster-status` access. +Local RBAC roles and bindings attach a user or group to a particular project. Cluster RBAC can attach cluster-wide roles and bindings to all projects in a cluster. There are default cluster roles that can be assigned to provide `admin`, `basic-user`, `cluster-admin`, and `cluster-status` access. diff --git a/security/container_security/security-compliance.adoc b/security/container_security/security-compliance.adoc index c2361024b29a..27496fe95fbb 100644 --- a/security/container_security/security-compliance.adoc +++ b/security/container_security/security-compliance.adoc @@ -6,10 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -For many {product-title} customers, regulatory readiness, or compliance, on -some level is required before any systems can be put into production. -That regulatory readiness can be imposed by national standards, industry -standards or the organization's corporate governance framework. +[role="_abstract"] +For many {product-title} customers, regulatory readiness, or compliance, on some level is required before any systems can be put into production. That regulatory readiness can be imposed by national standards, industry standards or the organization's corporate governance framework. // Compliance and the NIST risk management model include::modules/security-compliance-nist.adoc[leveloffset=+1] diff --git a/security/container_security/security-hosts-vms.adoc b/security/container_security/security-hosts-vms.adoc index 49b697be10d5..69e4b388ebd0 100644 --- a/security/container_security/security-hosts-vms.adoc +++ b/security/container_security/security-hosts-vms.adoc @@ -6,11 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -Both containers and virtual machines provide ways of separating -applications running on a host from the operating system itself. -Understanding {op-system}, which is the operating system used by -{product-title}, will help you see how the host -systems protect containers and hosts from each other. +[role="_abstract"] +Both containers and virtual machines provide ways of separating applications running on a host from the operating system itself. Understanding {op-system}, which is the operating system used by {product-title}, will help you see how the host systems protect containers and hosts from each other. // How containers are secured on {op-system} diff --git a/security/container_security/security-platform.adoc b/security/container_security/security-platform.adoc index aa92f9613c58..5402808d4a1b 100644 --- a/security/container_security/security-platform.adoc +++ b/security/container_security/security-platform.adoc @@ -6,21 +6,18 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] {product-title} and Kubernetes APIs are key to automating container management at scale. APIs are used to: * Validate and configure the data for pods, services, and replication controllers. -* Perform project validation on incoming requests and invoke triggers on other -major system components. +* Perform project validation on incoming requests and invoke triggers on other major system components. Security-related features in {product-title} that are based on Kubernetes include: -* Multitenancy, which combines Role-Based Access Controls and network policies -to isolate containers at multiple levels. -* Admission plugins, which form boundaries between an API and those -making requests to the API. +* Multitenancy, which combines Role-Based Access Controls and network policies to isolate containers at multiple levels. +* Admission plugins, which form boundaries between an API and those making requests to the API. -{product-title} uses Operators to automate and simplify the management of -Kubernetes-level security features. +{product-title} uses Operators to automate and simplify the management of Kubernetes-level security features. // Multitenancy include::modules/security-platform-multi-tenancy.adoc[leveloffset=+1]