search

cloudtools / ssh-cert-authority

An implementation of an SSH certificate authority.
BSD 2-Clause "Simplified" License
723 stars 71 forks source link

Solving the 3am problem #6

Closed hany closed 8 years ago

hany commented 9 years ago

Hi there,

I stumbled on this project because I was searching for a solution whereby people or systems requiring access to other systems need authorization to do so. While reading the README of this project, this particular paragraph seemed to fit my requirements exactly:

You're now an SSH cert signer. The problem, however, is that you probably don't want to be the signer. Signing certificates is not fun. And it's really not fun at 3:00AM when someone on the team needs to access a host for a production outage and you were not that person. That person now has to wake you up to get a certificate signed. And you probably don't want that. And now you perhaps are ready to appreciate this project a bit more.

However, after reading the rest of the documentation, I'm not exactly sure how this project solves this problem. If someone on the team needs production access at 3am, would they not still need to wake you up to "sign" the request via this tool?

bobveznat commented 9 years ago

It depends on how you configure it and what your requirements are.

If everyone in the org is allowed to sign requests and only one signer is required everyone can self sign their 3am requests. That works today out of the box.

In the env I work in we have around 20 developers and around 7 signers. For production access 2 approvals are required as a matter of policy. This means 2 of the 7 signers must be around or woken up.

The value add is that none of those 7 signers need access to the CA; the actual secret. This allows us to spread out signing responsibilities without worrying that the more signers we have the higher the surface area for compromise.

I get the impression your requirements are different. It sounds like you want the property that individual developers or operations staff don't have access to any shared secrets but that otherwise have self service access to any machine in operation? And then you get the audit log properties of this project?

I don't think that's a huge departure from the original goal of this project. Maybe this mode of operation is a feature request? On Sep 12, 2015 8:43 AM, "Hany Fahim" notifications@github.com wrote:

Hi there,

I stumbled on this project because I was searching for a solution whereby people or systems requiring access to other systems need authorization to do so. While reading the README of this project, this particular paragraph seemed to fit my requirements exactly:

You're now an SSH cert signer. The problem, however, is that you probably don't want to be the signer. Signing certificates is not fun. And it's really not fun at 3:00AM when someone on the team needs to access a host for a production outage and you were not that person. That person now has to wake you up to get a certificate signed. And you probably don't want that. And now you perhaps are ready to appreciate this project a bit more.

However, after reading the rest of the documentation, I'm not exactly sure how this project solves this problem. If someone on the team needs production access at 3am, would they not still need to wake you up to "sign" the request via this tool?

— Reply to this email directly or view it on GitHub https://github.com/cloudtools/ssh-cert-authority/issues/6.

hany commented 9 years ago

@bobveznat yes, that's essentially the idea, however what will require access is mostly an automated system that has the ability to connect to others. Our primary concern is what would happen if this automated system were compromised and allowed an attacker to gain access to the other systems through this central point. I interpreted the description of this project as an automated solution to this problem without requiring human intervention. However, I may have misinterpreted.

hany commented 8 years ago

Closing this issue.

bobveznat commented 8 years ago

I'd like to leave this open. I haven't finished fixing it yet. There are two things coming:

In the config for an environment you'll be able to set NumberSignersRequired to 0. In that case requests will automatically be signed.

Slightly further down the pipe it seems useful to define that an environment is active during certain times of the day. For example, you could define that a "prod-autosign" environment is active from 9pm - 8am every day and that would allow people, in the middle of the night, to access production systems without requiring that someone else wake up too. But during the day the autosign env won't be active and people will be forced to use "prod" which won't autosign. At least I'm considering this.

hany commented 8 years ago

@bobveznat that's quite interesting. I like the NumberSignersRequired option, as that can be handy in specific circumstances. This also addresses the original intent of this issue.

Timed access is also an interesting idea. Looking forward to this.

bobveznat commented 8 years ago

Finally got this fixed up with commit 244d0fa5fdd. If you set NumberSignersRequired in an environment to -1 requests are automatically signed. Ideally the "request" command would see the 202 HTTP status code and automatically download the signed cert but I haven't done that yet.

Going to tag this as 1.2.0