Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security of Infrastructure Secrets

journal.paul.querna.org

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Security of Infrastructure Secrets

#11

Post by jlgaddis »

proksoup wrote: post #3

The attack vectors that surprised me but should not have: - MongoHQ support person has access to data in customer database. - CircleCI stores everything in the MongoHQ database, that is used to deploy/control customer servers. - CircleCI's Customers' CircleCI controlled environments mixed with production environments. I am guessing everyone just expects most companies, especially those with maybe just Series A financ…

I think we (those of us using "cloud services") put entirely too much trust in the providers that we use.

We all just pretty much assume that they're doing the right thing(TM) with regard to security even after we've seen, time and again, that this is certainly not the case.

Re: Security of Infrastructure Secrets

#12

Post by gohrt »

proksoup wrote: post #3

The attack vectors that surprised me but should not have: - MongoHQ support person has access to data in customer database. - CircleCI stores everything in the MongoHQ database, that is used to deploy/control customer servers. - CircleCI's Customers' CircleCI controlled environments mixed with production environments. I am guessing everyone just expects most companies, especially those with maybe just Series A financ…

> everyone just expects most companies ... to employ this level of security paranoia?

The established enterprise hosting companies have security-infrastructure teams that are larger than the entire staff of most startups. Draw your own conclusions about how thorough those startups are with regard to security.

Re: Security of Infrastructure Secrets

#13

Post by gaadd33 »

kgilpin wrote: post #6

Disclaimer: infrastructure secrets management is my profession. This is a lot harder problem than people realize. If you have a fixed set of machines that need secrets, then encrypting a bag of secrets with each machine's private key works ok. But in auto scaling / automated / ephemeral scenarios, it doesn't work. You need an RBAC scheme for machines that builds layers of trust; each machine is placed into a role by…

Has Conjur been audited by a third party or is the source open at all? Otherwise we just have to trust that the thing that we store all of our secrets in is secure right?

Re: Security of Infrastructure Secrets

#14

Post by jessaustin »

kgilpin wrote: post #6

Disclaimer: infrastructure secrets management is my profession. This is a lot harder problem than people realize. If you have a fixed set of machines that need secrets, then encrypting a bag of secrets with each machine's private key works ok. But in auto scaling / automated / ephemeral scenarios, it doesn't work. You need an RBAC scheme for machines that builds layers of trust; each machine is placed into a role by…

I stored the user’s Chef private key that I downloaded from the Hosted Chef UI as a Conjur variable.

Wouldn't it be better to generate the key in the same place it will be used? Transferring private keys over the network smells bad to me. Is there some requirement for a user to have only one key pair active at a time? If so that is bad. Each "client" environment you use should be able to upload a public key whenever it's convenient.

Re: Security of Infrastructure Secrets

#15

Post by jessaustin »

jlgaddis wrote: post #10
kgilpin wrote: post #8

Earlier quoted context omitted.

Most people we have worked with don't take ssh key passwords seriously, because they can be stripped out. We advocated for the idea that password-protected ssh keys are a form of 2-factor auth, but nobody bought into that. Organizations that want 2-factor auth are typically setting up bastion / jump hosts that require a second factor like a phone-delivered one-time password. This can be configured through the PAM sta…

> Once on the bastion, the user can get to other machines within the accessible network using their passwordless ssh key. I really really hope that bastion host never gets compromised.

Well, sure, but that's inherent in the "perimeter" concept referenced above. The design assumes there is an advantage to relaxing the hardening requirements of hosts connected only to the subnet. These could include: only having to keep ssh whitelists current on the bastion, instead of on all hosts. Being able to completely reorganize reverse proxies without having to update all the app servers. In general, it can be valuable for any particular host to trust that any particular incoming connection is not related to a DDOS. If a host connects to the public internet, that's not possible.

Re: Security of Infrastructure Secrets

#16

Post by dustinrcollins »

jessaustin wrote: post #14
kgilpin wrote: post #6

Disclaimer: infrastructure secrets management is my profession. This is a lot harder problem than people realize. If you have a fixed set of machines that need secrets, then encrypting a bag of secrets with each machine's private key works ok. But in auto scaling / automated / ephemeral scenarios, it doesn't work. You need an RBAC scheme for machines that builds layers of trust; each machine is placed into a role by…

I stored the user’s Chef private key that I downloaded from the Hosted Chef UI as a Conjur variable. Wouldn't it be better to generate the key in the same place it will be used? Transferring private keys over the network smells bad to me. Is there some requirement for a user to have only one key pair active at a time? If so that is bad. Each "client" environment you use should be able to upload a public key whenever…

When using Hosted Chef you can't generate a private key and upload it. You create a user, their system generates your key pair and displays the private key one-time-only for you to store somewhere. A user in Chef can only have one keypair at a time. This is just a limitation of their system we have to work with.

It's important to note that the 'user' here in Hosted Chef is not a person, it is an identity in the Chef server that is allowed to upload cookbooks. Its scope is limited to only that.

Rotating the deploy user's key when using HostedChef is a 1 step process, using knife and Conjur together

``` knife user reregister "conjurbot" | conjur variable values add hostedchef/conjurbot/private_key ```

The stdout of `knife user reregister` is the private key so you can update the variable in Conjur without even seeing the value. You could run this in a cron job if you wanted. Your CI system responsible for uploading cookbooks will pull the new private key next time it runs.

Again, not ideal that Hosted Chef only allows you one keypair per user but we can minimize the threat by rotating the key frequently.

Re: Security of Infrastructure Secrets

#17

Post by dustinrcollins »

gaadd33 wrote: post #13
kgilpin wrote: post #6

Disclaimer: infrastructure secrets management is my profession. This is a lot harder problem than people realize. If you have a fixed set of machines that need secrets, then encrypting a bag of secrets with each machine's private key works ok. But in auto scaling / automated / ephemeral scenarios, it doesn't work. You need an RBAC scheme for machines that builds layers of trust; each machine is placed into a role by…

Has Conjur been audited by a third party or is the source open at all? Otherwise we just have to trust that the thing that we store all of our secrets in is secure right?

We have been audited by a 3rd party and incorporated all of their suggestions in the latest 4.4 release.

http://blog.conjur.net/conjur-4-4-released

One of their stipulations for the audit was that we don't use it for promotional purposes so I guess a NDA is required to discuss details.

The tech we use for encryption of secrets is definitely open source here: https://github.com/conjurinc/slosilo

Conjur isn't built on in-house cryptographic software - it uses trusted open-source tools - OpenSSL, PAM and so on.

Most of our work is open-source https://github.com/conjurinc https://github.com/conjur-cookbooks

Re: Security of Infrastructure Secrets

#18

Post by fweespeech »

jlgaddis wrote: post #10
kgilpin wrote: post #8

Earlier quoted context omitted.

Most people we have worked with don't take ssh key passwords seriously, because they can be stripped out. We advocated for the idea that password-protected ssh keys are a form of 2-factor auth, but nobody bought into that. Organizations that want 2-factor auth are typically setting up bastion / jump hosts that require a second factor like a phone-delivered one-time password. This can be configured through the PAM sta…

> Once on the bastion, the user can get to other machines within the accessible network using their passwordless ssh key. I really really hope that bastion host never gets compromised.

Well, if its a pure bastion, the only services to compromise is SSH and the package management [e.g. apt].

If either of those get compromised, you are hosed anyway.

Post reply on HN