1. Documentation
×

Host security

Fedora CoreOS (FCOS)

Fedora CoreOS (FCOS) is different from Fedora in key areas. For more information, see "About FCOS".

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

FCOS follows the same immutable design used for pods in OKD. This ensures that the operating system remains consistent across the cluster. For information about FCOS architecture, see "Fedora CoreOS (FCOS)".

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 FCOS 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 OKD 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 OKD 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 OKD 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.