OCPBUGS-44637: Mount proxy certificate to node-joiner pod

[rwsu]

When a proxy is configured with a self-signed certificate, the certificate needs to be made available to the node-joiner pod to allow it to communicate with the proxy.

It is assumed that the proxy certificate is configured in the cluster proxy spec as

spec:
  trustedCA:
    name: user-ca-bundle

The certificate is stored in a config map named "user-ca-bundle" in the "openshift-config" namespace in a file named ca-bundle.crt.

apiVersion: v1
data:
  ca-bundle.crt: |
    -----BEGIN CERTIFICATE-----
    ** redacted **
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  name: user-ca-bundle
  namespace: openshift-config

If the certificate is included in the additionalTrustBundle field in install-config.yaml prior to cluster installation, the proxy and user-ca-bundle is automatically configured as illustrated
above.

Previously, the certificate wasn't mounted to the node-joiner pod so that when the pod attempted to pull images through the proxy, it failed.

Now the user-ca-bundle config map is copied to the node-joiner pod's namespace and the certificate is mounted and made available as /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.

[openshift-ci-robot]

@rwsu: This pull request references Jira Issue OCPBUGS-44637, which is invalid:

• expected the bug to target the "4.19.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

When a proxy is configured with a self-signed certificate, the certificate needs to be made available to the node-joiner pod to allow it to communicate with the proxy.

Previously, the certificate wasn't mounted to the node-joiner pod so that when the pod attempted to pull images through the proxy, it failed.

Now the user-ca-bundle config map is copied to the node-joiner pod's namespace and the certificate is mounted and made available as /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rwsu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/cli/admin/nodeimage/OWNERS [rwsu]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rwsu]

/jira refresh

[openshift-ci-robot]

@rwsu: This pull request references Jira Issue OCPBUGS-44637, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.19.0) matches configured target version for branch (4.19.0)
• bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @mhanss

In response to this:

/jira refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

@rwsu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-ovn-serial	9b1bb8a	link	true	/test e2e-aws-ovn-serial

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[andfasano]

Given that it seems the reasonable motivation for the issue, there is one point not clear to me: why the oc command must be responsible for extracting a certificate, and injecting it into the node-joiner container?
Couldn't be something directly managed by the node-joiner tool itself?
Personally I'd prefer to avoid having additional logic in the oc wrapper layer - if not the one just required the proper execution of the container (for the rest, the node-joiner must be able to work also on its own)