5 ms·

Summon – Get Your Secrets into Source Control

46 points by nikolay 11y ago

nodesocket 11y ago
Lots of cool projects around secrets lately: * Vault (by Hashicorp) [go] https://hashicorp.com/blog/vault.html https://hashicorp.com/blog/vault.html * Confidant (by Lyft) [Python] https://eng.lyft.com/announcing-confidant-an-open-source-secret-management-service-from-lyft-1e256fe628a3#.oc1x5ftls https://eng.lyft.com/announcing-confidant-an-open-source-sec... * Keywhiz (by Sqaure) [Java] https://square.github.io/keywhiz/ https://square.github.io/keywhiz/
- patio11 11y ago
  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.
  - neduma 11y ago
    More info/pointers pls. thx
- joslin01 11y ago
  Don't forget BlackBox by StackExchange: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox
amelius 11y ago
> ... 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?
- Skunkleton 11y ago
  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?
  - mschuster91 11y ago
    > 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
- msm23 11y ago
  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.
  - billhathaway 11y ago
    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.
  - jlgaddis 11y ago
    On FreeBSD, at least, the ability to see processes belonging to other {g,u}id's can be turned off via a sysctl.
rdancer 11y ago
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
- gingerlime 11y ago
  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.
- tedmiston 11y ago
  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).
jessaustin 11y ago
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.
- kgilpin 11y ago
  Summon puts secrets metadata into source control; not actual secrets.
  - jessaustin 11y ago
    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.
    - kgilpin 11y ago
      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.

46 points by nikolay 11y ago

Lots of cool projects around secrets lately: * Vault (by Hashicorp) [go] https://hashicorp.com/blog/vault.html https://hashicorp.com/blog/vault.html * Confidant (by Lyft) [Python] https://eng.lyft.com/announcing-confidant-an-open-source-secret-management-service-from-lyft-1e256fe628a3#.oc1x5ftls https://eng.lyft.com/announcing-confidant-an-open-source-sec... * Keywhiz (by Sqaure) [Java] https://square.github.io/keywhiz/ https://square.github.io/keywhiz/

patio11 11y ago
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.
- neduma 11y ago
  More info/pointers pls. thx
joslin01 11y ago
Don't forget BlackBox by StackExchange: https://github.com/StackExchange/blackbox https://github.com/StackExchange/blackbox

amelius 11y ago

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

Skunkleton 11y ago
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?
- mschuster91 11y ago
  > 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
msm23 11y ago
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.
- billhathaway 11y ago
  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.
- jlgaddis 11y ago
  On FreeBSD, at least, the ability to see processes belonging to other {g,u}id's can be turned off via a sysctl.

rdancer 11y ago

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

gingerlime 11y ago
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.
tedmiston 11y ago
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).

jessaustin 11y ago

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.

kgilpin 11y ago
Summon puts secrets metadata into source control; not actual secrets.
- jessaustin 11y ago
  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.
  - kgilpin 11y ago
    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.