mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
39 lines
4.0 KiB
Plaintext
39 lines
4.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * security/container_security/security-hosts-vms.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="security-hosts-vms-rhcos_{context}"]
|
|
= Securing containers on {op-system-first}
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
[WARNING]
|
|
====
|
|
Disabling SELinux on {op-system} is not supported.
|
|
====
|
|
|
|
* _CGroups_ (control groups) limit, account for, and isolate the resource usage (CPU, memory, disk I/O, network, etc.) of a collection of processes. CGroups are used to ensure that containers on the same host are not impacted by each other.
|
|
|
|
* _Secure computing mode (seccomp)_ profiles can be associated with a container to restrict available system calls. See page 94 of the link:https://www.redhat.com/en/resources/openshift-security-guide-ebook[Red Hat OpenShift security guide] for details about seccomp.
|
|
|
|
* 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.
|
|
|
|
{op-system} is a version of {op-system-base-full} that is specially configured to work as control plane (master) and worker nodes on {product-title} clusters. So {op-system} is tuned to efficiently run container workloads, along with Kubernetes and {product-title} services.
|
|
|
|
[NOTE]
|
|
====
|
|
To further protect {op-system} systems in {product-title} clusters, most containers, except those managing or monitoring the host system itself, should run as a non-root user. Dropping the privilege level or creating containers with the least amount of privileges possible is recommended best practice for protecting your own {product-title} clusters.
|
|
====
|