This is a cache of https://docs.okd.io/latest/security/certificate_types_descriptions/machine-config-operator-certificates.html. It is a snapshot of the page at 2024-11-23T18:19:33.945+0000.
Machine Config Operator <strong>certificate</strong>s - <strong>certificate</strong> types and descriptions | Security and compliance | OKD 4
  1. Documentation
×

Machine Config Operator certificates

Purpose

This certificate authority is used to secure connections from nodes to Machine Config Server (MCS) during initial provisioning.

There are two certificates: . A self-signed CA, the MCS CA . A derived certificate, the MCS cert

Provisioning details

OKD installations that use Fedora CoreOS (FCOS) are installed by using Ignition. This process is split into two parts:

  1. An Ignition config is created that references a URL for the full configuration served by the MCS.

  2. For user-provisioned infrastucture installation methods, the Ignition config manifests as a worker.ign file created by the openshift-install command. For installer-provisioned infrastructure installation methods that use the Machine API Operator, this configuration appears as the worker-user-data secret.

Currently, there is no supported way to block or restrict the machine config server endpoint. The machine config server must be exposed to the network so that newly-provisioned machines, which have no existing configuration or state, are able to fetch their configuration. In this model, the root of trust is the certificate signing requests (CSR) endpoint, which is where the kubelet sends its certificate signing request for approval to join the cluster. Because of this, machine configs should not be used to distribute sensitive information, such as secrets and certificates.

To ensure that the machine config server endpoints, ports 22623 and 22624, are secured in bare metal scenarios, customers must configure proper network policies.
Additional resources

Provisioning chain of trust

The MCS CA is injected into the Ignition configuration under the security.tls.certificateAuthorities configuration field. The MCS then provides the complete configuration using the MCS cert presented by the web server.

The client validates that the MCS cert presented by the server has a chain of trust to an authority it recognizes. In this case, the MCS CA is that authority, and it signs the MCS cert. This ensures that the client is accessing the correct server. The client in this case is Ignition running on a machine in the initramfs.

Key material inside a cluster

The MCS CA appears in the cluster as a config map in the kube-system namespace, root-ca object, with ca.crt key. The private key is not stored in the cluster and is discarded after the installation completes.

The MCS cert appears in the cluster as a secret in the openshift-machine-config-operator namespace and machine-config-server-tls object with the tls.crt and tls.key keys.

Management

At this time, directly modifying either of these certificates is not supported.

Expiration

The MCS CA is valid for 10 years.

The issued serving certificates are valid for 10 years.

Customization

You cannot customize the Machine Config Operator certificates.