-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base kmsauth token on bastion_user instead of remote_usernames #58
base kmsauth token on bastion_user instead of remote_usernames #58
Conversation
tagging @Stype just to make sure he agrees that Blessclient would still work and that he agrees with the spirit of this PR |
This would put us in an awkward situation since the certificate is based off of the remote_username. So with this patch I think user1 can monkey with with version of blessclient and get a certificate to login as user2, by setting different remote/bastion usernames. Since there isn't a way to enforce that in the Lambda currently.
I could probably get to 1 this week if needed (or happy to work with you on something like that). Unless Russell has strong feelings on it. |
Ooooh option #2 is a very interesting idea, I may take a stab at that. How it currently works, KMS just will crap out, since you're signing with The one thing I don't love about 1 is I lose that awesome ability to set the encryption context in the IAM that |
@djcrabhat I don't think what @Stype was proposing for option 1 would require the change in IAM policy you were describing. The way I'm reading that, you would still do the kmsauth token check against On that whitelist, if you allowed prefixes, you could still implement per-instance certs (e.g. ubuntu-i-1234567890abcdef0 instead of just ubuntu) if you had your instances set up scoped AuthorizedPrincipals. I should add that I'm not sure if either of y'all would want to go down the per-instance cert route, given that your bastionless ssh route. But if you did, you'd also need to generate keypairs for each ssh session, due to limits of how ssh finds/uses certificates associated with a given keypair. |
Yep, more like this. I wasn't thinking I would enforce which other names the user was approved to use in the kmsauth token. I would just make it a whitelist of other names that anyone with a valid kmsauth token could assume. If you want to enforce with IAM policy that a group of users can login as a particular username there are probably ways you could do that, but I'm not sure if that's what you're looking for. |
Ooooh I gotcha guys now. So I agree, that 1 is a very nice solution. And I see why my proposed solution would fix my problem, but also open the door to people logging in as anyone they wanted, as long as they signing the bastion_user as themselves. So that's a great idea, some sorta logic in the bless lambda, that if you're doing this kmsauth verification 1) ensure the remote and bastion users are the same or 2) if not the same, check the config for some sorta whitelist of allowed remote users. I'll take a stab at that approach on this branch this week. Thank you both so much for being so responsive on this PR, you guys came up with a much better solution. |
…to allow different remote_usernames
added positive test mocking kmsauth sucessfully decrypting a token
Alright, so I've added a config value for (Also added some tests to get coverage I mistakenly overlooked) |
Tagging @Stype and @russell-lewis . |
I didn't test it, but it looks like that should work for us. +1 from me. |
The iconic bless client from the team that made kmsauth in the first place, https://github.com/lyft/python-blessclient, uses the same value for
bastion_user
andremote_usernames
. Their clever use of IAM policy (https://github.com/lyft/python-blessclient#setup-a-kmsauth-key--policy-in-your-aws-account) to make sure a user can only generate certs for themselves works great if you use the samebastion_user
andremote_usernames
. They also try to pull the IAM username of the current credentials and default that for thebastion_user
.But my situation is a little different. I want to use BLESS in a similar way to this suggestion from Facebook, where my users will be logging on to root or some other sort of shared, privileged account. So I'll have a
bastion_user
that maps 1:1 to an AWS user, but the signed cert will now be good for a privileged local user on the BLESS-CA-trusting server I'm trying to login to.For example, imagine a payload like this
I could then send a
kmsauth_token
with an encryption context ofdjcrabhat
, which directly links me to my IAM user, instead of having the encryption context ofubuntu
.(PS: and this shouldn't be disruptive to python-blessclient, as they'll still end up sending the same value for
bastion_user
andremote_usernames
.)