mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-07 00:48:01 +01:00
59 lines
2.6 KiB
Plaintext
59 lines
2.6 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * security/container_security/security-hardening.adoc
|
|
|
|
[id="security-hardening-how_{context}"]
|
|
|
|
= Choosing how to harden {op-system}
|
|
|
|
Direct modification of {op-system} systems in {product-title} is discouraged.
|
|
Instead, you should think of modifying systems in pools of nodes, such
|
|
as worker nodes and 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 {op-system} image plus the
|
|
modifications you created earlier.
|
|
|
|
There are opportunities for modifying {op-system} before installation,
|
|
during installation, and after the cluster is up and running.
|
|
|
|
[id="security-harden-before-installation_{context}"]
|
|
== Hardening before installation
|
|
|
|
For bare metal installations, you can add hardening features to
|
|
{op-system} before beginning the {product-title} installation. For example,
|
|
you can add kernel options when you boot the {op-system} installer
|
|
to turn security features on or off, such as SELinux or various
|
|
low-level settings, such as symmetric multithreading.
|
|
|
|
Although bare metal {op-system} installations are more difficult,
|
|
they offer the opportunity of getting operating system
|
|
changes in place before starting the {product-title} 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.
|
|
|
|
[id="security-harden-during-installation_{context}"]
|
|
== 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 {op-system} 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.
|
|
|
|
[id="security-harden-after-installation_{context}"]
|
|
== Hardening after the cluster is running
|
|
After the {product-title} cluster is up and running, there are
|
|
several ways to apply hardening features to {op-system}:
|
|
|
|
* Daemon set: If you need a service to run on every node, you can add
|
|
that service with a
|
|
link:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[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 {product-title}
|
|
product documentation.
|