[Installer]: change authProviders from raw data to a secret

[mrsimonemms]

Currently, the authProviders in the config.yaml is an array of objects with sensitive data in. THIS IS A BAD IDEA* and will probably raise concern with self-hosted users with additional security/compliance requirements.

Current - array of objects

authProviders:
  - id: Public-GitHub
    host: github.com
    type: GitHub
    oauth:
      clientId: xxx
      clientSecret: xxx
      callBackUrl: https://$DOMAIN/auth/github.com/callback
      settingsUrl: https://github.com/organizations/$ORG_ID/settings/applications/$APP_ID

Proposed - array of secrets

authProviders:
  - kind: secret
    name: auth-provider-github
  - kind: secret
    name: auth-provider-gitlab

Each secret would then have the data in an expected format similar to the current auth provider config.

One of the difficulties with this is that this is injected into server as a ConfigMap, so the object would need to be amended to accept a file location and then read the content from the file

[iQQBot]

I think all these things should be configurable in the Admin UI at a later stage, and you probably don't want to have to reinstall a global authProviders once

[mrsimonemms]

@iQQBot there is a section in the UI for this already - you can add and remove config once set

[iQQBot]

Did you mean "Integrations" on "Setting"?
This is not the same as what I'm talking about, I'm talking about the kind that can be configured in the Admin UI for all users and can appear on the login screen

[csweichel]

/team meta

This would affect meta and how that configuration is consumed.

[AlexTugarev]

@iQQBot, it's the Setup page which is meant here. It allows you to setup an Git Integration right after deployment when no auth provider is provided by configuration. That used to be our self-hosted path, as it allows to set up OAuth more user friendly.

👍🏻 for converting those to secrets.

[iQQBot]

Oh, I forgot it

[mrsimonemms]

Not sure if this would be applicable, but I did something very similar in content-service-api in #6777. I added an additional AccessKeyIdFile and SecretAccessKeyFile param to the config - if they're set, the constructor reads the contents from the specified file and sets to AccessKeyID and SecretAccessKey. I wonder if a similar approach could be followed here?

That way, it keeps the same functionality in the codebase except for the declaration of the secret.