You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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_authenticatortype: oauth2_introspectionconfig:
introspection_endpoint:
url: http://hydra:4445/oauth2/introspectauth:
type: basic_authconfig:
user: ${INTROSPECT_EP_USER} # taken from envpassword: 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
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
The text was updated successfully, but these errors were encountered:
Preflight checklist
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:Pros:
Cons:
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 likeAnd the usage in the config file would then be
Pros:
Cons:
secrets.yaml
file)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
The text was updated successfully, but these errors were encountered: