Allow passing of oidc provider block as Kubernetes Secret

[C0rn3rphr34k]

To be able to properly secure the client_id and client_secret of the oidc provider config block when committing the values.yaml to git, I'd like to suggest adding a feature that allows to pass in the whole config block, e.g. keycloak from a Kubernetes Secret (which in turn may be created with the help of sealed-secrets).

So instead of:

oidc:
  # -- Enable oidc authentication
  enable: true

  # -- Dictionary of oidc providers
  providers:
    keycloak:
      display_name: Keycloak
      provider_url: https://test-keycloak.example.com/auth
      redirect_url: https://semaphoreui.example.com/api/auth/oidc/keycloak/redirect
      client_id: ************ # redacted
      client_secret: ************ # redacted
      username_claim: username
      name_claim: name
      email_claim: email

something along the lines of:

oidc:
  # -- Enable oidc authentication
  enable: true

  # -- Dictionary of oidc providers
  providers:
    existingSecret: <secret-name-here>

Let me know if you have any questions and thank you for providing a helm chart for Semaphore UI

[leighwgordon]

I'm not a maintainer (just another end user) but are you aware of the client_id_file and client_secret_file parameters? These should allow secrets to be mounted into the paths referred to by these params.

https://docs.semaphoreui.com/administration-guide/openid/

For example, my work in progress config is somelike like the following in the chart values:

  extraVolumes:
    - name: prod-semaphoreui-oidc
      secret:
        secretName: prod-semaphoreui-oidc
  extraVolumeMounts:
    - name: prod-semaphoreui-oidc
      mountPath: /etc/prod-semaphoreui-oidc
      readOnly: true

And then using these *_file parameters in the OIDC YAML entry:

      client_id_file: /etc/prod-semaphoreui-oidc/client_id
      client_secret_file: /etc/prod-semaphoreui-oidc/client_secret

Note: this is untested pending this fix going back in #8 before I re-test OIDC but I think this is a somewhat standard pattern that I have used in other deployments rather than needing secrets with more complex schemas when 90% of the values are just config and not actually secrets.

[C0rn3rphr34k]

Thank you for your answer @leighwgordon
I actually wasn't aware of those parameters. They look promising and I'll see if I can use them right away.

I'll report back and update the issue as necessary.

[C0rn3rphr34k]

Thanks again @leighwgordon 🙇
Your hint was exactly what I needed to get my config working without committing the client_id or client_secret to git. Until the regression you mentioned is fixed, I've downloaded and manually edited the templates, just to get the test environment here up and running.

I'll close the Issue.