Question: How to implement an auth provider?

[Glenn Eggen]

We are looking into using this helm chart to dry run backstage to see wether we like it or not. The chart itself is running fine however it's not behind some kind of login page which isn't desirable.

I would like to be able to manipulate the app-config.yaml through the values file to insert information related to the auth provider but at this moment that's impossible.

See: https://github.com/redhat-developer/helm-backstage/blob/1bcfb8a66d87a5165597fbea5be5d50802668683/charts/backstage/templates/app-config.yaml#L79

[Tom Coufal]

We can easily solve this by allowing an additional config file being inlined by the user. Backstage can consume multiple config files where the last applied gets higher priority.

https://backstage.io/docs/conf/writing#configuration-files

Compound keys within the config are deep merged.

For instance we can have a value in values.yaml

customConfig: |
	<inline yaml config goes in here>

then render it into a Secret (since Backstage allows inlined credentials) and optionally mount and apply on the Deployment:

https://github.com/redhat-developer/helm-backstage/blob/main/charts/backstage/templates/deployment.yaml#L31

command:
  - node
  - packages/backend
  - '--config'
  - /config/app-config.yaml
  - '--config'
  - /config/custom-config.yaml   

I'll get you a PoC PR.

[Tom Coufal]

/assign

[Tom Coufal]

@Glaaj with PR #16 you can get this working with:

# values.yaml
...
additionalConfig:
  auth:
    environment: development
    providers:
      github:
        development:
          clientId: FOO
          clientSecret: BAR

additionalConfig accepts any key that you are used to from a regular Backstage config file. Nested properties are merged, primitives are overwritten and have priority over defaults rendered by the chart. It generates a new config property in the Secret used for app-config.yaml, so secrets can be also inlined. IMO we need a better way to inject secrets into the deployment, but that's a different story.