Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 29. Configuring a custom PKI


Some platform components, such as the web console, use Routes for communication and must trust other components' certificates to interact with them. If you are using a custom public key infrastructure (PKI), you must configure it so its privately signed CA certificates are recognized across the cluster.

You can leverage the Proxy API to add cluster-wide trusted CA certificates. You must do this either during installation or at runtime.

  • During installation, configure the cluster-wide proxy. You must define your privately signed CA certificates in the

    install-config.yaml
    file’s
    additionalTrustBundle
    setting.

    The installation program generates a ConfigMap that is named

    user-ca-bundle
    that contains the additional CA certificates you defined. The Cluster Network Operator then creates a
    trusted-ca-bundle
    ConfigMap that merges these CA certificates with the Red Hat Enterprise Linux CoreOS (RHCOS) trust bundle; this ConfigMap is referenced in the Proxy object’s
    trustedCA
    field.

  • At runtime, modify the default Proxy object to include your privately signed CA certificates (part of cluster’s proxy enablement workflow). This involves creating a ConfigMap that contains the privately signed CA certificates that should be trusted by the cluster, and then modifying the proxy resource with the
    trustedCA
    referencing the privately signed certificates' ConfigMap.
Note

The installer configuration’s

additionalTrustBundle
field and the proxy resource’s
trustedCA
field are used to manage the cluster-wide trust bundle;
additionalTrustBundle
is used at install time and the proxy’s
trustedCA
is used at runtime.

The

trustedCA
field is a reference to a
ConfigMap
containing the custom certificate and key pair used by the cluster component.

29.1. Configuring the cluster-wide proxy during installation

Production environments can deny direct access to the internet and instead have an HTTP or HTTPS proxy available. You can configure a new OpenShift Container Platform cluster to use a proxy by configuring the proxy settings in the

install-config.yaml
file.

Prerequisites

  • You have an existing
    install-config.yaml
    file.
  • You reviewed the sites that your cluster requires access to and determined whether any of them need to bypass the proxy. By default, all cluster egress traffic is proxied, including calls to hosting cloud provider APIs. You added sites to the

    Proxy
    object’s
    spec.noProxy
    field to bypass the proxy if necessary.

    Note

    The

    Proxy
    object
    status.noProxy
    field is populated with the values of the
    networking.machineNetwork[].cidr
    ,
    networking.clusterNetwork[].cidr
    , and
    networking.serviceNetwork[]
    fields from your installation configuration.

    For installations on Amazon Web Services (AWS), Google Cloud, Microsoft Azure, and Red Hat OpenStack Platform (RHOSP), the

    Proxy
    object
    status.noProxy
    field is also populated with the instance metadata endpoint (
    169.254.169.254
    ).

Procedure

  1. Edit your

    install-config.yaml
    file and add the proxy settings. For example:

    apiVersion: v1
    baseDomain: my.domain.com
    proxy:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 
    1
    
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 
    2
    
      noProxy: ec2.<aws_region>.amazonaws.com,elasticloadbalancing.<aws_region>.amazonaws.com,s3.<aws_region>.amazonaws.com 
    3
    
    additionalTrustBundle: | 
    4
    
        -----BEGIN CERTIFICATE-----
        <MY_TRUSTED_CA_CERT>
        -----END CERTIFICATE-----
    additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 
    5
    1
    A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be http.
    2
    A proxy URL to use for creating HTTPS connections outside the cluster.
    3
    A comma-separated list of destination domain names, IP addresses, or other network CIDRs to exclude from proxying. Preface a domain with . to match subdomains only. For example, .y.com matches x.y.com, but not y.com. Use * to bypass the proxy for all destinations. If you have added the Amazon EC2,Elastic Load Balancing, and S3 VPC endpoints to your VPC, you must add these endpoints to the noProxy field.
    4
    If provided, the installation program generates a config map that is named user-ca-bundle in the openshift-config namespace that contains one or more additional CA certificates that are required for proxying HTTPS connections. The Cluster Network Operator then creates a trusted-ca-bundle config map that merges these contents with the Red Hat Enterprise Linux CoreOS (RHCOS) trust bundle, and this config map is referenced in the trustedCA field of the Proxy object. The additionalTrustBundle field is required unless the proxy’s identity certificate is signed by an authority from the RHCOS trust bundle.
    5
    Optional: The policy to determine the configuration of the Proxy object to reference the user-ca-bundle config map in the trustedCA field. The allowed values are Proxyonly and Always. Use Proxyonly to reference the user-ca-bundle config map only when http/https proxy is configured. Use Always to always reference the user-ca-bundle config map. The default value is Proxyonly.
    Note

    The installation program does not support the proxy

    readinessEndpoints
    field.

    Note

    If the installer times out, restart and then complete the deployment by using the

    wait-for
    command of the installer. For example:

    $ ./openshift-install wait-for install-complete --log-level debug
  2. Save the file and reference it when installing OpenShift Container Platform.

The installation program creates a cluster-wide proxy that is named

cluster
that uses the proxy settings in the provided
install-config.yaml
file. If no proxy settings are provided, a
cluster
Proxy
object is still created, but it will have a nil
spec
.

Note

Only the

Proxy
object named
cluster
is supported, and no additional proxies can be created.

29.2. Enabling the cluster-wide proxy

The

Proxy
object is used to manage the cluster-wide egress proxy. When a cluster is installed or upgraded without the proxy configured, a
Proxy
object is still generated but it will have a nil
spec
. For example:

apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
  name: cluster
spec:
  trustedCA:
    name: ""
status:

A cluster administrator can configure the proxy for OpenShift Container Platform by modifying this

cluster
Proxy
object.

Note

Only the

Proxy
object named
cluster
is supported, and no additional proxies can be created.

Warning

Enabling the cluster-wide proxy causes the Machine Config Operator (MCO) to trigger node reboot.

Prerequisites

  • You have cluster administrator permissions.
  • You installed the OpenShift Container Platform
    oc
    CLI tool.

Procedure

  1. Create a config map that contains any additional CA certificates required for proxying HTTPS connections.

    Note

    You can skip this step if the proxy’s identity certificate is signed by an authority from the RHCOS trust bundle.

    1. Create a file called

      user-ca-bundle.yaml
      with the following contents, and provide the values of your PEM-encoded certificates:

      apiVersion: v1
      data:
        ca-bundle.crt: | 
      1
      
          <MY_PEM_ENCODED_CERTS> 
      2
      
      kind: ConfigMap
      metadata:
        name: user-ca-bundle 
      3
      
        namespace: openshift-config 
      4
      1
      This data key must be named ca-bundle.crt.
      2
      One or more PEM-encoded X.509 certificates used to sign the proxy’s identity certificate.
      3
      The config map name that is referenced from the Proxy object.
      4
      The config map must exist in the openshift-config namespace.
    2. Create the config map from the

      user-ca-bundle.yaml
      file by entering the following command:

      $ oc create -f user-ca-bundle.yaml
  2. Use the

    oc edit
    command to modify the
    Proxy
    object:

    $ oc edit proxy/cluster
  3. Configure the necessary fields for the proxy:

    apiVersion: config.openshift.io/v1
    kind: Proxy
    metadata:
      name: cluster
    spec:
      httpProxy: http://<username>:<pswd>@<ip>:<port> 
    1
    
      httpsProxy: https://<username>:<pswd>@<ip>:<port> 
    2
    
      noProxy: example.com 
    3
    
      readinessEndpoints:
      - http://www.google.com 
    4
    
      - https://www.google.com
      trustedCA:
        name: user-ca-bundle 
    5
    1
    A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be http.
    2
    A proxy URL to use for creating HTTPS connections outside the cluster. The URL scheme must be either http or https. Specify a URL for the proxy that supports the URL scheme. For example, most proxies will report an error if they are configured to use https but they only support http. This failure message may not propagate to the logs and can appear to be a network connection failure instead. If using a proxy that listens for https connections from the cluster, you may need to configure the cluster to accept the CAs and certificates that the proxy uses.
    3
    A comma-separated list of destination domain names, domains, IP addresses (or other network CIDRs), and port numbers to exclude proxying.
    Note

    Port numbers are only supported when configuring IPv6 addresses. Port numbers are not supported when configuring IPv4 addresses.

    Preface a domain with

    .
    to match subdomains only. For example,
    .y.com
    matches
    x.y.com
    , but not
    y.com
    . Use
    *
    to bypass proxy for all destinations. If you scale up workers that are not included in the network defined by the
    networking.machineNetwork[].cidr
    field from the installation configuration, you must add them to this list to prevent connection issues.

    This field is ignored if neither the

    httpProxy
    or
    httpsProxy
    fields are set.

    4
    One or more URLs external to the cluster to use to perform a readiness check before writing the httpProxy and httpsProxy values to status.
    5
    A reference to the config map in the openshift-config namespace that contains additional CA certificates required for proxying HTTPS connections. Note that the config map must already exist before referencing it here. This field is required unless the proxy’s identity certificate is signed by an authority from the RHCOS trust bundle.
  4. Save the file to apply the changes.

29.3. Certificate injection using Operators

Once your custom CA certificate is added to the cluster via ConfigMap, the Cluster Network Operator merges the user-provided and system CA certificates into a single bundle and injects the merged bundle into the Operator requesting the trust bundle injection.

Important

After adding a

config.openshift.io/inject-trusted-cabundle="true"
label to the config map, existing data in it is deleted. The Cluster Network Operator takes ownership of a config map and only accepts
ca-bundle
as data. You must use a separate config map to store
service-ca.crt
by using the
service.beta.openshift.io/inject-cabundle=true
annotation or a similar configuration. Adding a
config.openshift.io/inject-trusted-cabundle="true"
label and
service.beta.openshift.io/inject-cabundle=true
annotation on the same config map can cause issues.

Operators request this injection by creating an empty ConfigMap with the following label:

config.openshift.io/inject-trusted-cabundle="true"

An example of the empty ConfigMap:

apiVersion: v1
data: {}
kind: ConfigMap
metadata:
  labels:
    config.openshift.io/inject-trusted-cabundle: "true"
  name: ca-inject 
1

  namespace: apache
1
Specifies the empty ConfigMap name.

The Operator mounts this ConfigMap into the container’s local trust store.

Note

Adding a trusted CA certificate is only needed if the certificate is not included in the Red Hat Enterprise Linux CoreOS (RHCOS) trust bundle.

Certificate injection is not limited to Operators. The Cluster Network Operator injects certificates across any namespace when an empty ConfigMap is created with the

config.openshift.io/inject-trusted-cabundle=true
label.

The ConfigMap can reside in any namespace, but the ConfigMap must be mounted as a volume to each container within a pod that requires a custom CA. For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-example-custom-ca-deployment
  namespace: my-example-custom-ca-ns
spec:
  ...
    spec:
      ...
      containers:
        - name: my-container-that-needs-custom-ca
          volumeMounts:
          - name: trusted-ca
            mountPath: /etc/pki/ca-trust/extracted/pem
            readOnly: true
      volumes:
      - name: trusted-ca
        configMap:
          name: ca-inject
          items:
            - key: ca-bundle.crt 
1

              path: tls-ca-bundle.pem 
2
1
ca-bundle.crt is required as the ConfigMap key.
2
tls-ca-bundle.pem is required as the ConfigMap path.
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red Hat
Nach oben