Explore injecting the istio tenant gateway CA as a trusted certificate to GL

[Racer159]

Is your feature request related to a problem? Please describe.

Some users have reported issues with SSL errors when trying to connect GitLab to Keycloak - these requests currently go through the tenant gateway (sso.domain.tld) and need to process that trust chain. This CA is already in-cluster under the gateway-tls secret in the istio-tenant-gateway namespace, and the GitLab chart exposes custom CAs here:

https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/values.yaml?ref_type=heads#L792
https://repo1.dso.mil/big-bang/product/packages/gitlab/-/blob/main/chart/values.yaml#L811

Describe the solution you'd like

• Given I have a self-signed or custom CA installed
• When I login through GitLab SSO
• Then I am let in without needing to give GitLab additional configuration

Describe alternatives you've considered

We could just expose / document a way to add certificates to a package but this would be more work and may be difficult to implement in some envs.

Additional context

This is something some users have run into in their environments.

[oates]

@mjnagel @adam-defenseunicorns We don't think this is a good idea to trust what is likely an intermediate cert. Perhaps a better way would be for UDS Core to ask for the RootCA and then apps can pull/trust from there? Thoughts?

[Racer159]

Potential solution: defenseunicorns/uds-bundle-software-factory-nutanix#122

[Racer159]

https://cert-manager.io/docs/trust/trust-manager/

[Racer159]

Blocked on defenseunicorns/uds-core#464

[mjnagel]

@mjnagel @adam-defenseunicorns We don't think this is a good idea to trust what is likely an intermediate cert. Perhaps a better way would be for UDS Core to ask for the RootCA and then apps can pull/trust from there? Thoughts?

Definitely don't disagree here. Technically (today) uds-core doesn't have the root cert either most likely since end users are just passing either the single leaf cert or leaf cert + intermediates. We can continue convos on the uds-core issues, but I do think we'd likely end up needing a new root cert input from the end user or just have to trust whatever the "relative root" is of what the user provided for their cert already.

[oates]

@adam-defenseunicorns tagging you on this to see if this can move up the backlog. It's impacting @blancharda today. There is work to do on our side as well and will move forward on that. Its not a blocker for us yet, but will be.

[mjnagel]

@oates just to make sure I'm understanding the issue correctly - is adding the CA for GitLab via additional secret+values possible currently? Tracking that uds-core could provide better automation around this but want to understand if this is fully blocked functionally or just non-ideal (neither are great but one is worse obviously).

[Racer159]

@mjnagel not entirely - there are breakages with the registry due to a bug in the registry1 certificates image - we can attempt to mangle things with a kubectl patch but it would be a cleaner mangle if we had a consistent secret reference to reference (which we can establish in GL but would likely need to update when uds-core rolls things out)

[Racer159]

We aren't hard-blocked as @oates mentioned but it is a soft block to actually fix this in a more sane / consistent way

[mjnagel]

@Racer159 thanks, so really defenseunicorns/uds-core#465 is the need, not just defenseunicorns/uds-core#464?

[Racer159]

#465 would be really nice but we could make things work with #464 - I don't mind having complexity in the package but would like to obscure that complexity from the end user. Probably the cleanest way to do it without changes to uds core is asking for a CA bundle in the config chart and then telling the user to pass another helm value with a specific secret name to GitLab if they used that feature (since we don't have a ton of insight into the values between charts). If uds-core asked for the CA bundle and created a consistent secret we could count on we could hide all of that from the user.