1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/security-hosts-vms-openshift.adoc

47 lines
2.0 KiB
Plaintext

// Module included in the following assemblies:
//
// * security/container_security/security-hosts-vms.adoc
:_mod-docs-content-type: CONCEPT
[id="security-hosts-vms-openshift_{context}"]
= Securing {product-title}
When you deploy {product-title}, you have the choice of an
installer-provisioned infrastructure (there are several available platforms)
or your own user-provisioned infrastructure.
ifndef::openshift-origin[]
Some low-level security-related configuration, such as enabling FIPS
mode or adding kernel modules required at first boot, might
benefit from a user-provisioned infrastructure.
endif::[]
ifdef::openshift-origin[]
Some low-level security-related configuration, such as adding kernel modules required at first boot, might
benefit from a user-provisioned infrastructure.
endif::[]
Likewise, user-provisioned infrastructure is appropriate for disconnected {product-title} deployments.
Keep in mind that, when it comes to making security enhancements and other
configuration changes to {product-title}, the goals should include:
* Keeping the underlying nodes as generic as possible. You want to be able to
easily throw away and spin up similar nodes quickly and in prescriptive ways.
* Managing modifications to nodes through {product-title} as much as possible,
rather than making direct, one-off changes to the nodes.
In pursuit of those goals, most node changes should be done during installation through Ignition
or later using MachineConfigs that are applied to sets of nodes by the Machine Config Operator.
Examples of security-related configuration changes you can do in this way include:
* Adding kernel arguments
* Adding kernel modules
* Enabling support for FIPS cryptography
* Configuring disk encryption
* Configuring the chrony time service
Besides the Machine Config Operator, there are several other Operators available to configure {product-title} infrastructure that are managed by the Cluster Version Operator (CVO). The CVO is able to automate many aspects of
{product-title} cluster updates.