heimdall icon indicating copy to clipboard operation
heimdall copied to clipboard

Loading of secrets from files

Open dadrus opened this issue 1 year ago • 0 comments

Preflight checklist

  • [X] I agree to follow this project's Code of Conduct.
  • [X] I have read and am following this repository's Contribution Guidelines."
  • [X] I have discussed this feature request with the community.

Describe the background of your feature request

As of today the loading of keys for TLS and Signer (to issue JWTs) happens from files. Unlike this, in all other places, like configuration of api keys, etc in mechanisms the loading of secrets/sensitive data happens either from the config file or from env variables. Both is actually far away from being an optimal approach - in both cases the values of these secrets could potentially leak. For that reason, loading of secrets from files should be supported as well in such places.

Describe your idea

There are basically two approaches known and also discussed in https://discord.com/channels/1100447190796742698/1131484813258391665/1131484813258391665.

Alternative 1

Making use of a file scheme to reference a locally available file with the corresponding file containing the secret. Here an example:

mechanisms:
  authenticators:
  - id: hydra_authenticator
    type: oauth2_introspection
    config:
      introspection_endpoint:
        url: http://hydra:4445/oauth2/introspect
        auth:
          type: basic_auth
          config:
            user: ${INTROSPECT_EP_USER} # taken from env
            password: file://path_to_file_with_password # taken from file

Pros:

  • This is most probably the most simple approach
  • Easy to apply in kubernetes since you can just mount all keys of a secret as individual files in some pod dir. Same is actually true for non k8s deployments.
  • Easy to integrate with secret management systems

Cons:

  • Fragmentation of secrets - these are scattered across multiple files.

Alternative 2

Making use of a special secrets.yaml file, which would hold the corresponding values in a structured way. By reusing the example from 1, the contents of that file could look like

secrets:
  hydra:
    user: admin
    pass: hunter2

And the usage in the config file would then be

mechanisms:
  authenticators:
  - id: hydra_authenticator
    type: oauth2_introspection
    config:
      introspection_endpoint:
        url: http://hydra:4445/oauth2/introspect
        auth:
          type: basic_auth
          config:
            user: ${{ secrets.hydra.user }} # or secrets://hydra.user
            password: ${{ secrets.hydra.pass }} # or secrets://hydra.pass

Pros:

  • Also easy to use

Cons:

  • Integration with secret management systems is problematic
  • There is a need to move all secrets to a single place (the above shown secrets.yaml file)
  • Based on that the management of secrets becomes harder compared to 1 and
  • Application in kubernetes environment becomes harder as well as the different secret would have to be merged into a single file with a specific structure.
  • Might tempt people to store that secrets.yaml file encrypted in git, which is actually a bad practice.

Are there any workarounds or alternatives?

All described above

Version

0.11.1-alpha

Additional Context

No response

dadrus avatar Nov 15 '23 10:11 dadrus