Summon – Get Your Secrets into Source Control | Hacker News Reader

Summon – Get Your Secrets into Source Control

conjurinc.github.io

46 pointsnikolay17 comments

Open articleView on HN

Lots of cool projects around secrets lately:

* Vault (by Hashicorp) [go] https://hashicorp.com/blog/vault.html

* Confidant (by Lyft) [Python] https://eng.lyft.com/announcing-confidant-an-open-source-sec...

* Keywhiz (by Sqaure) [Java] https://square.github.io/keywhiz/

Don't forget BlackBox by StackExchange: https://github.com/StackExchange/blackbox

We use Vault so that our Rails et al passwords can get written by Ansible scripts without any repo having all the keys to our kingdom in plain text. Ease of use decently high, particularly once you standardize on a way to communicate secrets to arbitrary systems. (Ours is "Assume you pervasively have access to secrets via environment variables. The sole source of truth for them is in the Ansible repo.")

Edit to add: it occurs to me, not for the first time, that I assumed Ansible Vault was Vault by Hashicorp simply because so much of our Devops stack is from Hashicorp.

More info/pointers pls. thx

Is this a very roundabout way to do a wrapper shell script (the target audience being people who cannot write shell scripts)?

    $ cat > secrets && chmod 600 secrets
    export SECRET_1='Jerry is a mushroom'
    export SECRET_2='Jessica'\''s a chicken!'
    
    $ cat > wrapper && chmod +x wrapper
    #!/bin/sh
    set -e
    . ./secrets
    exec "$@"

    $ env -i ./wrapper env
    SECRET_1=Jerry is a mushroom
    SECRET_2=Jessica's a chicken!
    PWD=/home/rdancer

I do appreciate the simplicity (and effectiveness) of this wrapper, and I would definitely recommend this much simpler approach over a more robust tool in many situations.

I think the added value (and increased complexity) from tools like this is that allow you to store your secrets not only on the filesystem, but also in various (typically external) vaults. Some also provide more granular access control to only a subset of secrets, revocation and so on.

That works until you have a multi-person dev team that wants to securely exchange and retrieve secrets without storing them in the repo.

For example, S3 credentials, or the API secret to an external service (that may have been rotated since the last time you pulled).

> ... reads a file in secrets.yml format and injects secrets as environment variables into any process

Meaning that every child process will subsequently have access to the secrets?

Also, /proc/<pid>/environ. There are rules on who owns this file (root, or the executing user) based on the suid bit. Regardless, you are now depending on linux permissions to protect your secrets, which begs the question: Why not just trust the filesystem? Even if /proc/<pid>/environ didn't exist, you could go through /proc/<pid>/mem to find secrets.

It seems that this is designed to protect you from untrusted execution environments, which I don't see as feasible. What am I missing?

> It seems that this is designed to protect you from untrusted execution environments, which I don't see as feasible. What am I missing?

Shared web hosting where you share a physical machine with other users. Not everyone is into the VM craze these days, thank god

Running

  ps auxwwe

on Linux, Mac OS X, and other Unix-en will show all processes for all users with their complete environment.

Environment variables should not be used to share secrets.

Testing on Linux, if ran as root it does, but if you are running ps auxwwe as normal user, it is only showing env variables for that user.

On FreeBSD, at least, the ability to see processes belonging to other {g,u}id's can be turned off via a sysctl.

ISTM secrets should mostly be generated where they're needed and should not leave that location. If two locations need to interact then use asymmetric keys so that the public key may be shared. Of course such a system must be bootstrapped, but suitable arrangements will make that a relatively rare manual process.

Of course exceptions might be made for any number of operational reasons but I think it helps to at least aim for the right thing even if it isn't always possible. Secrets in VCS seems to be a shot in exactly the opposite direction.

Summon puts secrets metadata into source control; not actual secrets.

Haha it seems the motto should instead be "get some pointers to your secrets into source control". This makes the tool much less vulnerable to the abuse I was envisioning, but also pushes it into "so what?" territory for me. I can already save pointers to secrets in my code; this is another layer of configuration for dubious benefit.

Summon also fetches the secrets out of the backend in a provider neutral way; it's well documented; and it ensures that secrets stay off persistent disks. So those are the reasons to use it. It's better for the world if there are a smaller number of doing the same things.

Reply on news.ycombinator.com