It has this kind of functionality (via plugins) but also does a lot more. Validation, coercion, type-safety, composability, sharing config across monorepos, leak detection…
We don’t have all of these providers as plugins yet, but they are super easy to write.
Would love to have you collaborate with us - it’s open source.
My take on why this doesn't exists to larger extent is that if you are going to go through the effort of automating, you may as well take one more step and use short-lived personal tokens instead. In a cloud, this will already be there for you, usually through OIDC. Shared secrets is a dangerous concept to begin with.
Have thought about creating this exact type of thing. I will be checking this out next week, and seeing what else might be out there though. One service I see that’s missing is parameter store, but if I actually needed it I’m guessing it would be pretty easy to add unless there’s a reason for not also including it.
Parameter store should be straightforward, I wasn't actually even aware of it existing.. And yes, the more the merrier! Just make up some non-interfering URI scheme (I would probably use awspm://) that won't be reasonably used as an environment variable as is.
As for as a general reason to use it over SSM is that it’s free for like under 10k values but it’s not secure by default since it also allows non-encrypted values to be stored. AFAIK you can use basic encrypted values with it the same as SSM, but for more advanced uses there are differences.
It has this kind of functionality (via plugins) but also does a lot more. Validation, coercion, type-safety, composability, sharing config across monorepos, leak detection…
We don’t have all of these providers as plugins yet, but they are super easy to write.
Would love to have you collaborate with us - it’s open source.
Fun fact: SSM is also an acronym for parameter store, it used to be known as EC2 Simple Systems Manager: https://d0.awsstatic.com/whitepapers/whitepaper-ec2-ssm.pdf