Open pkarw opened 3 years ago
@pkarw
Topic 1. Read.
Let's clarify how the secrets could be read and how they couldn't:
If NO for 4. is OK, I can see an easy way to implement it. Secrets would just be a kind of values that can be accessed only by the AskVM. What we could even do is to instruct AskVM using AskScript how to set the secrets, e.g.: read file secrets.pwd, parse it and store the secrets under key 'my-secrets' in secrets, but won't be able to read them at all.
Let me know what you think.
Topic 2. Write (set)
A separate topic is where and how the secrets would be set. Would we store them all in a file? (Plaintext or encrypted). Would we set them programmatically from the code? Would we use ENV variables?
What's your suggestion?
Hey Łukasz, great study - thank you for your effort. I completely agree. So we could implement the 3rd
option for reading the secrets.
In regards to setting the secrets out I suppose we should have kind of async
provider overriding the default ENV
values. I mean, by default secrets are passed by ENV (+ .env
file) but then there's a wrapper around it and it's async function so anyone who'd like to get these from let's say API endpoint can easily extend the secrets provider or replace it with their own implementation
Is your feature request related to a problem? If yes, please describe the problem.
Related to #576.
It would be great to have a feature for passing the
ENV
kind of variables, but safe. It could be passed via thevm
context:I can imagine that in the AskScripts we could pass these variables as just:
secrets.awsCredentials
to subsequent resources and functions call, but wecan not
read these variables. Of course, the resource or function called can somehow return/display/log or another way discredit it. Well, it's a human factor we can't avoid.