Search

Chapter 5. Configuring proxy support in Operator Lifecycle Manager

download PDF

If a global proxy is configured on the OpenShift Container Platform cluster, Operator Lifecycle Manager automatically configures Operators that it manages with the cluster-wide proxy. However, you can also configure installed Operators to override the global proxy or inject a custom CA certificate.

Additional resources

5.1. Overriding an Operator’s proxy settings

If a cluster-wide egress proxy is configured, applications created from Operators using the Operator Lifecycle Manager (OLM) inherit the cluster-wide proxy settings on their Deployments and Pods. Cluster administrators can also override these proxy settings by configuring the Operator’s Subscription.

Prerequisites

  • Access to an OpenShift Container Platform cluster using an account with cluster-admin permissions.

Procedure

  1. Navigate in the web console to the Operators OperatorHub page.
  2. Select the Operator and click Install.
  3. On the Create Operator Subscription page, modify the Subscription object’s YAML to include one or more of the following environment variables in the spec section:

    • HTTP_PROXY
    • HTTPS_PROXY
    • NO_PROXY

    For example:

    Subscription object with proxy setting overrides

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: etcd-config-test
      namespace: openshift-operators
    spec:
      config:
        env:
        - name: HTTP_PROXY
          value: test_http
        - name: HTTPS_PROXY
          value: test_https
        - name: NO_PROXY
          value: test
      channel: clusterwide-alpha
      installPlanApproval: Automatic
      name: etcd
      source: community-operators
      sourceNamespace: openshift-marketplace
      startingCSV: etcdoperator.v0.9.4-clusterwide

    OLM handles these environment variables as a unit; if at least one of them is set, all three are considered overridden and the cluster-wide defaults are not used for the subscribed Operator’s Deployments.

  4. Click Subscribe to make the Operator available to the selected namespaces.
  5. After the Operator’s CSV appears in the relevant namespace, you can verify that custom proxy environment variables are set in the Deployment. For example, using the CLI:

    $ oc get deployment -n openshift-operators etcd-operator -o yaml | grep -i "PROXY" -A 2
    
            - name: HTTP_PROXY
              value: test_http
            - name: HTTPS_PROXY
              value: test_https
            - name: NO_PROXY
              value: test
            image: quay.io/coreos/etcd-operator@sha256:66a37fd61a06a43969854ee6d3e21088a98b93838e284a6086b13917f96b0d9c
    ...

Additional resources

  • See the OpenShift Container Platform 4.3 Release Notes for details on known issue BZ#1751903 regarding unset environment variables when overriding an Operator’s proxy settings.

5.2. Injecting a custom CA certificate

When a cluster administrator adds a custom CA certificate to a cluster using a ConfigMap, the Cluster Network Operator merges the user-provided certificates and system CA certificates into a single bundle. You can inject this merged bundle into your Operator running on Operator Lifecycle Manager (OLM), which is useful if you have a man-in-the-middle HTTPS proxy.

Prerequisites

  • Access to an OpenShift Container Platform cluster using an account with cluster-admin permissions.
  • Custom CA certificate added to the cluster using a ConfigMap.
  • Desired Operator installed and running on OLM.

Procedure

  1. Create an empty ConfigMap in the namespace where your Operator’s Subscription exists and include the following label:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: trusted-ca 1
      labels:
        config.openshift.io/inject-trusted-cabundle: "true" 2
    1
    Name of the ConfigMap.
    2
    Requests the Cluster Network Operator to inject the merged bundle.

    After creating this ConfigMap, the ConfigMap is immediately populated with the certificate contents of the merged bundle.

  2. Update your Operator’s Subscription object to include a spec.config section that mounts the trusted-ca ConfigMap as a volume to each container within a Pod that requires a custom CA:

    kind: Subscription
    metadata:
      name: my-operator
    spec:
      package: etcd
      channel: alpha
      config: 1
      - selector:
          matchLabels:
            <labels_for_pods> 2
        volumes: 3
        - name: trusted-ca
          configMap:
            name: trusted-ca
            items:
              - key: ca-bundle.crt 4
                path: tls-ca-bundle.pem 5
        volumeMounts: 6
        - name: trusted-ca
          mountPath: /etc/pki/ca-trust/extracted/pem
          readOnly: true
    1
    Add a config section if it does not exist.
    2
    Specify labels to match Pods that are owned by the Operator.
    3
    Create a trusted-ca volume.
    4
    ca-bundle.crt is required as the ConfigMap key.
    5
    tls-ca-bundle.pem is required as the ConfigMap path.
    6
    Create a trusted-ca volume mount.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.