A quick look at the repo and it doesn't shout simple and flexible...
Simple and flexible tool for managing secrets
21–30 of 34 posts
Re: Simple and flexible tool for managing secrets
#22If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates:
Client -> Proxy 1 -> Proxy 2 -> Proxy 3 -> Target -> Resolver
--Anyways, this is kinda sorta interesting, I guess, but honestly I'm more excited by and looking forward to the (hopefully!) eventual adoption and roll-out of "DNS SVCB and HTTPS RRs" [0] -- one of the other I-Ds (linked in the OP) on which ODoH is built -- and I suspect many other HN'ers will be as well (although I'd happily settle for SRV RR support in browsers).
--
[0]: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
Re: Simple and flexible tool for managing secrets
#23Re: Simple and flexible tool for managing secrets
#24The develop branch has merged support for age, too! https://github.com/mozilla/sops/tree/develop
Re: Simple and flexible tool for managing secrets
#25Even better, IMO, would be if all targets were also proxies and a client could choose -- at "query time" -- any combination of (proxy, target) that they prefer. If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates: Client -> Proxy 1 -> Proxy 2 -> Proxy 3 -> Target -> Resolver -- Anyways, this is kind…
Re: Simple and flexible tool for managing secrets
#26Re: Simple and flexible tool for managing secrets
#27This seems like a much easier-to-apply, automatic version of Ansible Vault's YAML variable encryption[0]. Personally I've never needed the extra per-YAML-entry control Ansible Vault gives you, so this seems a better approach. [0] https://docs.ansible.com/ansible/latest/user_guide/vault.htm...
Re: Simple and flexible tool for managing secrets
#28I didn't understand where keys are stored. Isn't that still an entry point?
Re: Simple and flexible tool for managing secrets
#29https://github.com/mozilla/sops#48showing-diffs-in-cleartext...
If you have many secrets you'll probably still end up breaking them out into different files to minimize conflicts between multiple in-progress branches. A good place to start is keeping a secrets file per environment+service:
- sops-dev-mywebapp.yml
- sops-dev-mydb.yml
- sops-prod-mywebapp.yml
- sops-prod-mydb.ymlRe: Simple and flexible tool for managing secrets
#30https://terragrunt.gruntwork.io/docs/reference/built-in-func...