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 2025-06-07T18:20:04.513+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:

  1. A self-signed CA, the machine-config-server-ca config map (MCS CA)

  2. A derived certificate, the machine-config-server-tls secret (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 following objects are stored in the openshift-machine-config-operator namespace:

  • The MCS CA bundle is stored as the machine-config-server-ca config map. The MCS CA bundle stores all valid CAs for the MachineConfigServer TLS certificate.

  • The MCS CA signing key is stored as the machine-config-server-ca secret. The MCS CA signing key is used to sign the MachineConfigServer TLS certificate.

  • The MCS cert is stored as the machine-config-server-tls secret, which contains the MachineConfigServer TLS certificate and key.

The machine-config-server-ca config map is used in the following ways:

  • The certificate controller updates the *-user-data secrets in the openshift-machine-api namespace any time the machine-config-server-ca configmap is updated.

  • The Machine Config Operator renders the master-user-data-managed and worker-user-data-managed secrets from the machine-config-server-ca configmap.

Management

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

Expiration

The MCS CA and MCS cert are valid for 10 years and are automatically rotated by the MCO at 8 years.

The issued serving certificates are valid for 10 years.

Customization

You cannot customize the Machine Config Operator certificates.