[NEW] Ability to get secrets via environment variables support

[naveedahd]

We would like to have support for SHIELD to read secrets from environment variables instead of a file on disk.

Is your feature request related to a problem? Please describe. Please describe the problem you are trying to solve.

Trying to enable Github OAuth with SHIELD at the initiation of the core.

Describe the solution you'd like

Github OAuth should work out of the box after deploying SHIELD.

Describe alternatives you've considered Please describe alternative solutions or features you have considered.

[jhunt]

To elaborate on this feature request, @naveedahd was attempting to configure GitHub-based OAuth authentication for our production SHIELD instance, using the SHIELD Helm chart (https://github.com/shieldproject/helm) and ran into a few snags.

Primarily, the shieldd core requires that the authentication bits exist in the YAML configuration file. In Kubernetes-land, that means we have to put them in the ConfigMap that supplies our specific configuration.

This is problematic in part because the Helm chart provides no way of inserting additional configuration into the ConfigMap when it is created. That can be worked-around with a small patch to the Helm chart, and without modifying SHIELD core.

The larger issue is that SHIELD's insistence on reading every bit of the GitHub OAuth configuration out of the configuration file means we must put credentials in a plaintext ConfigMap under k8s. This is bad.

Ideally, I could store the secrets in a bona fide Kubernetes Secret object, and then mount them into the SHIELD core container via the environment. However, for that to work, shieldd needs to be able to handle part of the OAuth configuration residing on disk, and some other part residing in the environment.

A rough sketch of how that might work:

auth:
  - identifier: github
    name:       Github
    backend:    github
    properties:
      client_id:      $SOME_ENV_VAR_NAME
      client_secret:  $SOME_OTHER_ENV_VAR_NAME

Then, the bits of shieldd that read configuration from disk could just look for $SOME_ENV_VAR_NAME and $SOME_OTHER_ENV_VAR_NAME in the executing environment and resolve those before handing the Config object back to the caller.

Another option would be to dynamically construct the environment variable names based on the OAuth identifier, according to the template: $SHIELD_AUTH_((ID))_GITHUB_CLIENT_ID and $SHIELD_AUTH_((ID))_GITHUB_CLIENT_SECRET, where ((ID)) is replaced with the uppercased value of the id attribute in the YAML file. This is less flexible but more predictable.