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