[FEATURE] Support self-signed certificates in builds

[diksha1999]

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

Shipwright builds are failing due to the issues while executing the first "source-default" step of ShipWright when a self-signed custom CA bundle is being used for a Git server.
Scenarios:

1. Cloning source code from a private git server
2. Pulling container images from a private container registry
3. Pulling dependencies from a private repository (ex: Artifactory).

Describe the solution that you would like.

Support for self-signed enterprise certificates in shipwright builds.

In enterprise environments, TLS certificates are often issued by a "corporate" certificate authority that is not globally trusted by RHEL. Actions that use HTTPS as transport (ex: cloning git source, pulling container images, downloading dependencies) need to be able to find and utilize the correct certificate authority.

Describe alternatives you have considered.

No response

Anything else?

Related Openshift Builds epic link:
https://issues.redhat.com/browse/BUILD-1152

[diksha1999]

Related Openshift Builds epic link:
https://issues.redhat.com/browse/BUILD-1152

[SaschaSchwarze0]

Sounds like an optional secret reference in the Git Source where there referenced secret contains a ca.crt. Is that what you are looking for @diksha1999 ?

[adambkaplan]

From refinement: we need a SHIP to work through the details and propose new API changes.

My personal preference is that whatever path we take, it complements workflows that utilize cert-manager, and it's newer trust-manager component in particular.

[bitgully]

@adambkaplan I was the one initially requesting this feature. An optional secret reference that @SaschaSchwarze0 mentioned would be sufficient. The integration with cert-manager might be nice to have but I would prefer not to create a mandatory dependency to another controller here.

[adambkaplan]

Obtaining trust CAs for git servers is one use case, but it isn't the only one. OKD's Build system (which was the inspiration for Shipwright) has a lot of overlapping configuration on this front that I frankly find confusing:

1. Certificate authorities for container registries.
2. CA's for accessing proxies in builds - there are separate settings for general internet proxies, and ones specific for git servers. Ouch.
3. OKD has its own notion of a "cluster proxy" that can be used (abused?) to inject trust bundles into workloads: https://docs.okd.io/latest/rest_api/config_apis/proxy-config-openshift-io-v1.html#spec-trustedca.

I'm wondering if we start with the most general use case of adding a global TLS trust bundle to a build, so that it can be used for all network traffic?

[bitgully]

Having only one (global) trusted CA setting for the entire build sounds good to me. But it might make sense to still allow just adding additional certificates whilst keeping a default set of well-known public CAs.