This is a cache of https://docs.openshift.com/container-platform/4.17/edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.html. It is a snapshot of the page at 2025-02-26T07:54:18.516+0000.
Host security - Day 2 operations for telco core CNF clusters | Edge computing | OpenShift Container Platform 4.17
    Starting on March 12, 2025, OpenShift docs will only be available at docs.redhat.com. From that time on, docs.openshift.com links will automatically redirect to their locations on docs.redhat.com.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Host security

Red Hat Enterprise Linux CoreOS (RHCOS)

Red Hat Enterprise Linux CoreOS (RHCOS) is different from Red Hat Enterprise Linux (RHEL) in key areas. For more information, see "About RHCOS".

From a telco perspective, a major distinction is the control of rpm-ostree, which is updated through the Machine Config Operator.

RHCOS follows the same immutable design used for pods in OpenShift Container Platform. This ensures that the operating system remains consistent across the cluster. For information about RHCOS architecture, see "Red Hat Enterprise Linux CoreOS (RHCOS)".

To manage hosts effectively while maintaining security, avoid direct access whenever possible. Instead, you can use the following methods for host management:

  • Debug pod

  • Direct SSHs

  • Console access

Review the following RHCOS secruity mechanisms that are integral to maintaining host security:

Linux namespaces

Provide isolation for processes and resources. Each container keeps its processes and files within its own namespace. If a user escapes from the container namespace, they could gain access to the host operating system, potentially compromising security.

Security-Enhanced Linux (SELinux)

Enforces mandatory access controls to restrict access to files and directories by processes. It adds an extra layer of security by preventing unauthorized access to files if a process tries to break its confinement.

SELinux follows the security policy of denying everything unless explicitly allowed. If a process attempts to modify or access a file without permission, SELinux denies access. For more information, see Introduction to SELinux.

Linux capabilities

Assign specific privileges to processes at a granular level, minimizing the need for full root permissions. For more information, see "Linux capabilities".

Control groups (cgroups)

Allocate and manage system resources, such as CPU and memory for processes and containers, ensuring efficient usage. As of OpenShift Container Platform 4.16, there are two versions of cgroups. cgroup v2 is now configured by default.

CRI-O

Serves as a lightweight container runtime that enforces security boundaries and manages container workloads.

Additional resources

Command-line host access

Direct access to a host must be restricted to avoid modifying the host or accessing pods that should not be accessed. For users who need direct access to a host, it is recommended to use an external authenticator, like SSSD with LDAP, to manage access. This helps maintain consistency across the cluster through the Machine Config Operator.

Do not configure direct access to the root ID on any OpenShift Container Platform cluster server.

You can connect to a node in the cluster using the following methods:

Using debug pod

This is the recommended method to access a node. To debug or connect to a node, run the following command:

$ oc debug node/<worker_node_name>

After connecting to the node, run the following command to get access to the root file system:

# chroot /host

This gives you root access within a debug pod on the node. For more information, see "Starting debug pods with root access".

Direct SSH

Avoid using the root user. Instead, use the core user ID (or your own ID). To connect to the node using SSH, run the following command:

$ ssh core@<worker_node_name>

The core user ID is initially given sudo privileges within the cluster.

If you cannot connect to a node using SSH, see How to connect to OpenShift Container Platform 4.x Cluster nodes using SSH bastion pod to add your SSH key to the core user.

After connecting to the node using SSH, run the following command to get access to the root shell:

$ sudo -i
Console Access

Ensure that consoles are secure. Do not allow direct login with the root ID, instead use individual IDs.

Follow the best practices of your organization for securing console access.
Additional resources

Linux capabilities

Linux capabilities define the actions a process can perform on the host system. By default, pods are granted several capabilities unless security measures are applied. These default capabilities are as follows:

  • CHOWN

  • DAC_OVERRIDE

  • FSETID

  • FOWNER

  • SETGID

  • SETUID

  • SETPCAP

  • NET_BIND_SERVICE

  • KILL

You can modify which capabilities that a pod can receive by configuring Security Context Constraints (sccs).

You must not assign the following capabilities to a pod:

  • SYS_ADMIN: A powerful capability that grants elevated privileges. Allowing this capability can break security boundaries and pose a significant security risk.

  • NET_ADMIN: Allows control over networking, like SR-IOV ports, but can be replaced with alternative solutions in modern setups.

For more information about Linux capabilities, see Linux capabilities man page.