When the cluster-proxy is configured to include a custom certificate, the git-clone task should automatically include that certificate

Goals

Customers using a self-hosted git-provider should not need to specify their custom certs when they are already configured on the cluster. These customers add their self-signed certificate to the cluster proxy configuration and operators can automatically use the certificate. However right now they have to provide the certs again to the git-clone task by mounting the already-mounted CA-bundle configmap as the ssl-ca-directory workspace on the task. This is a seemingly unnecessary extra step and unecessary complexity to pipeline-author users who should not need to care about the hosting infrastructure of their organization's git provider.

Requirements

Out of scope

Dependencies

Background, and strategic fit

The config-trusted-cabundle configmap contains the combination of all default CA-certs and any custom certificates configured by the user. It for a RHEL-based image, it should be mounted at /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem.

This decreases the complexity of authoring pipelines by removing infrastructure details which is at a lower abstraction level than pipelines-authors (developers) are often working.

Assumptions

• The git-clone task is running on a RHEL-based image. If the task's base-image is not RHEL-based the mount location may be different.

  Customer Considerations

• customers who are already providing custom certificates (which are not in the cluster proxy) to the git-clone task should not have any disruption.
• Customers who are already using the config-trusted-cabundle as the ssl-ca-dir workspace may like to know if that added complexity is no longer necessary
•  

Documentation Considerations

Documentation will need to be updated to mention that the cluster proxy certs are respected. Documentation on using the git-clone task should include the current ssl-ca-dir setting but also link to how to setup the cluster proxy ca-bundle.

What does success look like?

QE Contact

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

• Openshift docs on mounting the configmap as the system ca bundle: https://github.com/openshift/openshift-docs/blob/a8269cf65696fbd08647c8f3b5d065d53a8a1f52/modules/certificate-injection-using-operators.adoc
• Git-clone docs: https://github.com/openshift-pipelines/tektoncd-git-clone/tree/main/task/git-clone

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment