I'm not sure how much BLESS really improves the overall situation. It just shifts the problem from securing SSH secrets to securing AWS/IAM secrets, which seems pretty much the same to me.
The AWS/IAM secrets wouldn't be passed around, except on initial creation.. Not sure what you mean?
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.
Author of the blog post here. You totally nailed it about the problems with SSH keys.
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.
For a layer of security, when using the client you could do IAM role assumption in your local machine. You have your static creds and an MFA device, then use those to export temporary credentials to actually run the bless client. http://docs.aws.amazon.com/STS/latest/APIReference/API_Assum...
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.