Client Certificates at Netflix(scaleft.com) |
Client Certificates at Netflix(scaleft.com) |
https://github.com/Netflix/bless/blob/master/bless_client/bl...
If successful, I imagine it signs the pub key "id_rsa-cert.pub" which you then can use to SSH as you please (until the cert expires).
But that just brings up more questions. Generally you want as little as possible running on the bastion; it really is just that choke point. So I presume the SSO front end is also not running on the bastion, but in another subnet, then pokes the key back out...somehow?
That's a great slidedeck, looks great and I can actually learn something from it just reading the slides.
The problem they are fighting is host-level SSH authentication. Developers tend to have SSH keys stored all over the place, and it's near impossible to know if they protected their private keys with a password, or if they ever accidentally published them (how many private keys can you find on github these days?
Using client certificates instead, the developers have to ask for a certificate (presumably with some BLESS client), and after authenticating (with their credentials + 2FA) get issued a SHORT-LIVED certificate (5 mins) signed by your own internal trusted CA, to use for SSHing into bastion host or whatever.
So now, there is no key material handed to developer which will be trusted for more than a few minutes. Even if their password/secret were leaked, you still need 2FA and network access to get a client certificate. If you leak the client certificate, unless someone snatches it up within it's validity period, still no worries.
I think what zokier is referring to is that the BLESS client uses an AWS IAM role to authenticate users, so if you wanted to invoke it directly from an end-user machine they would need their AWS credentials on disk there. Instead BLESS seems to be intended to be invoked from a jump host which has a machine role giving it access to the Lambda function - which gives you a nice choke point for auditing, but obviously has some other limitations.
I get the impression from the slides that Netflix might have some additional internal tooling for authenticating users against SSO. I'm just excited to see client certificates taking off as a form of ephemeral access token. I see too many organizations that require MFA to access the corporate wiki but let users authenticate to production with a private key from 3 jobs and countless laptops ago.
Some tools to make the process easier: https://github.com/remind101/assume-role https://github.com/trek10inc/awsume
I wasn't at the talk, but had the same question.
BLESS, as released, appears to be intended to drop onto an AWS bastion host and recommends an AWS IAM role to authenticate the bastion to the Lambda function that acts as the CA. Like you mention, there are a lot of limitations to that, but its still a neat demonstration of using ephemeral client certificates without having to spin up a bunch of infrastructure.
At ScaleFT we're building a solution on the same principles that offers some of what you're talking about out of the box:
1. Authenticating users against a variety of SSO systems
2. Treating bastions as nothing more than an untrusted TCP proxy