search

defenseunicorns / uds-package-gitlab

🏭 UDS GitLab Zarf Package
Apache License 2.0
5 stars 3 forks source link

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

Open Racer159 opened 1 month ago

Racer159 commented 1 month ago

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

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 commented 1 month ago

@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 commented 4 weeks ago

Potential solution: https://github.com/defenseunicorns/uds-bundle-software-factory-nutanix/pull/122

Racer159 commented 4 weeks ago

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

Racer159 commented 4 weeks ago

Blocked on https://github.com/defenseunicorns/uds-core/issues/464

mjnagel commented 3 weeks ago

@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 commented 3 weeks ago

@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 commented 3 weeks ago

@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 commented 3 weeks ago

@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 commented 3 weeks ago

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 commented 3 weeks ago

@Racer159 thanks, so really https://github.com/defenseunicorns/uds-core/issues/465 is the need, not just https://github.com/defenseunicorns/uds-core/issues/464?

Racer159 commented 3 weeks ago

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.