Closed corang closed 6 months ago
Note you can specify a secret for the uds pkg CR. Also if we need to expand the operator to make this easier, just let us know. There are so many different ways to consume the values it became unwieldy.
@jeff-mccoy this key right? https://github.com/defenseunicorns/uds-core/blob/083ae0c45667e5b9064cbff781fbe4e5bc0d2991/src/pepr/operator/crd/generated/package-v1alpha1.ts#L462
I see that populated here but is that configurable? I don't see immediately where the clientID and secret could be included https://github.com/defenseunicorns/uds-core/blob/main/src/pepr/operator/controllers/keycloak/client-sync.ts#L122
Just realized naming conventions got to me and those are different
@jeff-mccoy thoughts on adding a config value to a package definition's sso
field that would let us template out a secret from the SSO config. At least for SWF, Gitlab, Mattermost, and SonarQube can all be configured from a secret that picks up keys within it (assuming we can set what those keys are)
This is being driven from delivery needing GitLab to have SSO soon.
Gitlab requires a secret specified in
gitlab.global.appConfig.omniauth.providers
to use SSO features. The repo1 gitlab chart doesn't provide a way to create this secret and just expects it to exist before deployment if you specify it. The secret contains a json file similar to below:Currently the way pepr works with the
sso
key in the package CRD is it registers a new client with keycloak and then creates a secret in k8s with the information about that client, namely the generated secret.Somehow there needs to be a way to consume the contents of the pepr created secret to create a secret for gitlab with the SSO client information in it, but also be optional in the case of not wanting to connect GitLab to an SSO (CI using uds-core-istio).