Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
×

Hardening FCOS

FCOS was created and tuned to be deployed in OKD with few if any changes needed to FCOS nodes. Every organization adopting OKD has its own requirements for system hardening. As a Fedora system with OpenShift-specific modifications and features added (such as Ignition, ostree, and a read-only /usr to provide limited immutability), FCOS can be hardened just as you would any Fedora system. Differences lie in the ways you manage the hardening.

A key feature of OKD and its Kubernetes engine is to be able to quickly scale applications and infrastructure up and down as needed. Unless it is unavoidable, you do not want to make direct changes to FCOS by logging into a host and adding software or changing settings. You want to have the OKD installer and control plane manage changes to FCOS so new nodes can be spun up without manual intervention.

So, if you are setting out to harden FCOS nodes in OKD to meet your security needs, you should consider both what to harden and how to go about doing that hardening.

Choosing what to harden in FCOS

The Fedora Security Hardening guide describes how you should approach security for any Fedora system.

Use this guide to learn how to approach cryptography, evaluate vulnerabilities, and assess threats to various services. Likewise, you can learn how to scan for compliance standards, check file integrity, perform auditing, and encrypt storage devices.

With the knowledge of what features you want to harden, you can then decide how to harden them in FCOS.

Choosing how to harden FCOS

Direct modification of FCOS systems in OKD is discouraged. Instead, you should think of modifying systems in pools of nodes, such as worker nodes and control plane nodes (also known as the master nodes). When a new node is needed, in non-bare metal installs, you can request a new node of the type you want and it will be created from an FCOS image plus the modifications you created earlier.

There are opportunities for modifying FCOS before installation, during installation, and after the cluster is up and running.

Hardening before installation

For bare metal installations, you can add hardening features to FCOS before beginning the OKD installation. For example, you can add kernel options when you boot the FCOS installer to turn security features on or off, such as SELinux booleans or various low-level settings, such as symmetric multithreading.

Although bare metal FCOS installations are more difficult, they offer the opportunity of getting operating system changes in place before starting the OKD installation. This can be important when you need to ensure that certain features, such as disk encryption or special networking settings, be set up at the earliest possible moment.

Disabling SELinux on FCOS nodes is not supported.

Hardening during installation

You can interrupt the OpenShift installation process and change Ignition configs. Through Ignition configs, you can add your own files and systemd services to the FCOS nodes. You can also make some basic security-related changes to the install-config.yaml file used for installation. Contents added in this way are available at each node’s first boot.

Hardening after the cluster is running

After the OKD cluster is up and running, there are several ways to apply hardening features to FCOS:

  • Daemon set: If you need a service to run on every node, you can add that service with a Kubernetes DaemonSet object.

  • Machine config: MachineConfig objects contain a subset of Ignition configs in the same format. By applying machine configs to all worker or control plane nodes, you can ensure that the next node of the same type that is added to the cluster has the same changes applied.

All of the features noted here are described in the OKD product documentation.

Additional resources