Live data from Hacker News

Simple and flexible tool for managing secrets

github.com

21–30 of 34 posts

Re: Simple and flexible tool for managing secrets

#22
Even 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 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

#23
Throwing another tiny open-source option into the arena: Envwarden[0] is a simple wrapper for managing server secrets with the Bitwarden[1] password manager. Not affiliated with Bitwarden in any way.

[0] https://github.com/envwarden/envwarden

[1] https://bitwarden.com/

Re: Simple and flexible tool for managing secrets

#24

The develop branch has merged support for age, too! https://github.com/mozilla/sops/tree/develop

Would really, really love to get an official release of sops with age support. Thanks for the tool--compared to GPG age is a complete breath of fresh air.

Re: Simple and flexible tool for managing secrets

#25

Even 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…

Did you comment on the wrong post? This seems unrelated to sops.

Re: Simple and flexible tool for managing secrets

#27
post #5

This 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...

Yes, and you can easily start using SOPS for Ansible secrets via the community.sops collection:

https://github.com/ansible-collections/community.sops

Re: Simple and flexible tool for managing secrets

#28

I didn't understand where keys are stored. Isn't that still an entry point?

Keys are stored in a PGP keyring and/or cloud Key Management Service (KMS). This is mentioned in the opening statement of the readme, and usage is detailed in section 2 of the docs:

https://github.com/mozilla/sops#usage

Re: Simple and flexible tool for managing secrets

#29
Anyone saving encrypted secrets in git will probably find it helpful to enable cleartext diffs:

https://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.yml
Post reply on HN