Support custom SSL root CAs for internal GitLab instances

[ktdreyer]

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Problem

The backend makes outbound HTTPS requests to user-configured GitLab instances during token validation and API calls. All HTTP clients use Go's default TLS configuration, which only trusts the system CA bundle baked into the container image (ubi9/ubi-minimal).

This means connections to internal instances that use certificates signed by a corporate CA (e.g. gitlab.cee.redhat.com) fail with:

tls: failed to verify certificate: x509: certificate signed by unknown authority

There is currently no way to provide additional trusted root CAs.

Affected components

All outbound HTTP clients in the backend that connect to user-configured hosts:

• components/backend/handlers/integration_validation.go — ValidateGitLabToken, ValidateGitHubToken, ValidateGoogleToken
• components/backend/gitlab/client.go — NewClient / doRequest
• components/backend/handlers/gitlab_auth.go — validateGitLabConnectivity

The runner (components/runners/ambient-runner/) may also need custom CAs when cloning from internal Git hosts, but that is a separate concern (handled by Git's own CA config).

Suggested approach

Option A: OpenShift trusted CA bundle injection (recommended for OpenShift deployments)

On OpenShift, a ConfigMap labeled with config.openshift.io/inject-trusted-cabundle: "true" is automatically populated with the cluster-wide proxy/CA bundle. Mount this into the backend pod and set SSL_CERT_DIR or load it into a custom tls.Config RootCAs pool.

Option B: Explicit ConfigMap/Secret mount

Allow operators to create a ConfigMap (e.g. ambient-custom-ca) containing PEM-encoded CA certificates. Mount it into the backend pod and configure the HTTP clients to include these CAs in their trust pool.

Implementation notes

• Go respects SSL_CERT_FILE and SSL_CERT_DIR environment variables for the default TLS config, so the simplest approach may be to mount the CA bundle and set the env var — no code changes needed for existing http.Client{} usage.
• If a shared http.Client or http.Transport is introduced, it should be used consistently across all outbound HTTP calls (GitLab, GitHub, Jira, Google OAuth).
• The LDAP client already has custom TLS handling (LDAP_SKIP_TLS_VERIFY) which should not serve as a reference, so that we do not spread InsecureSkipVerify hacks throughout the codebase.

[ktdreyer]

See https://redhat.atlassian.net/browse/RHOAIENG-56373 for a very similar issue I had to resolve with ArgoCD. We can use the same solution here.

[ktdreyer]

I've tested this internally. The config.openshift.io/inject-trusted-cabundle: "true" solution works when I mount that ConfigMap over the root cert store /etc/pki/tls/certs/ca-bundle.crt.

I had to create a tiny app in ArgoCD with this ConfigMap, which is not ideal. But it worked.

[ktdreyer]

Needs #1247