
Ask HN: How does your company manage secrets like API keys? - danenania
Fellow HNers,<p>I&#x27;m collecting data on how companies of various sizes handle sharing and deploying secrets like API keys, database credentials, etc. in both production and development.<p>If you have a minute, I would love to get your answers to this anonymous, 4 question, multiple choice survey:<p>https:&#x2F;&#x2F;goo.gl&#x2F;forms&#x2F;Mx97T9HD3s91DFLv1<p>In a couple days, I&#x27;ll aggregate and post the results along with some analysis and pretty graphs.<p>Full disclosure: I&#x27;m the founder of EnvKey[1], a secrets management service, which is why I&#x27;m especially interested in this topic.<p>1 - https:&#x2F;&#x2F;www.envkey.com
======
jamesmishra
We use Segment's chamber[1] as a frontend to AWS System Manager Parameter
Store[2].

I've found it pretty easy to set up, use, and not think about it. It's great
for integrating with AWS IAM and whatnot.

[1]:
[https://github.com/segmentio/chamber](https://github.com/segmentio/chamber)

[2]: [https://aws.amazon.com/blogs/mt/the-right-way-to-store-
secre...](https://aws.amazon.com/blogs/mt/the-right-way-to-store-secrets-
using-parameter-store/)

------
howToLearnSpark
[https://www.vaultproject.io](https://www.vaultproject.io) and so should you

~~~
insomniacity
Well, maybe not the founder of envkey... he might have colleagues depending on
him :)

~~~
danenania
I'm actually a big fan of Vault and greatly respect/look up to the Hashicorp
team :)

I think Vault can be great for teams that are sufficiently large and
sophisticated on the DevOps front. I felt there was a need for more of a
Heroku/1Password-style tool for teams that want a secure way to manage secrets
without undertaking a big project to setup/maintain their own secrets server.

------
nly
badly

------
gregopet
I started building a tool like this for internal use last year, but it was too
busy to actually get something noteworthy done, now I would have to get
motivated again.

The idea was to have a simple encrypted storage of markdown (or something
similar, I actually prefer Asciidoc myself) files, with possible binary
attachments. I wanted to build in a break-the-glass function: if something
goes wrong somebody authorized can click a button at which point all alarms
start ringing but the person can read the contents (perhaps after a certain
time delay during which opening can be prevented).

Would be great for secrets, emergencies, and also for non-tech uses.. wills
for example :)

(if someone decides to build this just let me know because I'd totally use it
:P )

------
fanf2
We aren’t quite sorted enough to use hashi vault everywhere, so a few of our
teams are using [https://dotat.at/prog/regpg/](https://dotat.at/prog/regpg/)
which is a wrapper around gpg that enormously simplifies key management, in a
way that works well with a version control system. It has hooks to work with
git and ansible, because that’s what we use, but the core functionality can
work with other tools equally well.

You might also consider
[https://github.com/StackExchange/blackbox](https://github.com/StackExchange/blackbox)
which does the same job in a similar way.

------
ojhughes
CredHub had been developed by folks at Pivotal to manage secret storage and
generation, in an arguably more opinionated way than Vault
[https://github.com/cloudfoundry-
incubator/credhub](https://github.com/cloudfoundry-incubator/credhub)

------
stabbles
pass [1] is great. The simple folder structure is great, it's built on git, it
works with multiple pgp keys, and different folders can have different keys.

[1] [https://www.passwordstore.org/](https://www.passwordstore.org/)

------
indescions_2018
Vault. AWS KMS. GCloud KMS & IAM.

More on "secrets at scale" from recent Real World Crypto 2018 talks:

[https://rwc.iacr.org/2018/](https://rwc.iacr.org/2018/)

------
nsaje
[https://github.com/Zemanta/go-secretcrypt](https://github.com/Zemanta/go-
secretcrypt)

------
AdamMills
[https://github.com/AGWA/git-crypt](https://github.com/AGWA/git-crypt)

------
panjaro
We print it in a paper, seal it in envelope and give it to company owner. He
then keeps it in his Safe.

------
diaz
Always keeping the best practices that were already in place... So obviously
not good :D

------
lmlsna
Paste into word doc.

------
johnnyballgame
No offense, but anyone who is serious about securing their keys is not going
to plop that information into a Google form.

~~~
jasonpeacock
Anyone who is serious about securing their keys is not going to rely on
security through obscurity.

Any good design should be able to withstand public scrutiny.

~~~
johnnyballgame
Who said anything about relying on it? But feel free to hand over your
specific security details to someone you don't even know. And make sure to
attach your email address as on the form. :)

~~~
hluska
From a risk management point of view (I'm over 40 so I can say that with a
straight face), relying on obscurity for key management is an unbelievable
shitshow. If you rely on nobody knowing how you store your keys to protect
your keys, you might find yourself obligated to change how you store your keys
every single time that someone quits.

Secret storage should really be solid enough that you could publish how you
manage your secrets on a billboard without any meaningful impact to your
probability of breach.

~~~
agnivade
So your only argument is that if someone quits, the secrets will spill out ?

I am a big fan of security by obscurity actually. I mean, by announcing to the
whole world how you store your secrets, you are telling all the hackers in the
world what protocols, what algorithms should they target against. Then one day
you suddenly have a 0-day vuln and boom, everything is gone.

Compare the risks of that to an employee leaving and leaking the secrets.

~~~
hluska
First, in practice, don't ever minimize the risks of an employee spilling
secrets. Employees are a massive source of leaks. Some good research suggests
that 60% of data breaches are caused by employees.

Maybe they're just being helpful, maybe they're outright malicious, or maybe
they have no idea what they're doing, but insiders are always a massive source
of breaches. Don't minimize that; accept it.

And second, I said "risk management". Risk management not only looks at
probability of breach but at the probability of a judicial or (worse) a
legislative response to the breach. If you rely upon security by obscurity,
you have to assume that someday, you'll be deposed by an attorney who will
want to find out how you protect those secrets.

That gets tough because protecting secrets is notoriously difficult, even for
government organizations with massive budgets for employee screening and
training. It's not impossible, but it's so difficult that you should assume
that the probability of a secret remaining secret is close to zero.

And, this is where obscurity by obscurity get complicated. It's very hard to
tell if a secret has leaked. So, when do you revoke a secret? There is always
an organizational cost to changing a secret, yet there is potentially a
massive organizational cost to holding onto a secret for too long. That looks
too much like a coin toss to me and I don't like playing odds like that.

Instead, I like playing the odds by using trusted algorithms and protocols to
protect secrets and backing those trusted algorithms and protocols up with
some hardcore monitoring, solid policy and well drilled process.

~~~
agnivade
Thanks. Good points.

I won't be rolling out my own crypto of course. I like to use existing known
parts. But add some slight improvements of my own. Customizations to my use-
case. It's a layered defense approach against attackers. The point is to make
them work hard.

------
drcongo
I wish KeyBase would take it on.

------
ppetty
I’m not telling …

Sorry, couldn’t resist.

------
nitely
AWS KMS

