Closed myoung34 closed 7 years ago
Any updates on this?
@pecigonzalo it works but I dont think there are plans to merge it upstream as it violates restricting/auditing users - you can impersonate anyone.
I dont use this anymore, instead I have a script baked into my AMIs that runs per boot (/var/lib/cloud/scripts/per-boot/crawl_iam.sh
) that crawls IAM for users in a group and adds them to the box:
for user in $(aws iam list-users | jq -r '.Users[].UserName'); do
[[ $(aws iam list-groups-for-user --user-name $user | jq -r '.Groups[] | select(.GroupName=="developers") | .GroupName' | wc -l) -gt 0 ]] && ( echo "adding user $user"; useradd -G wheel $user || : )
done
Yeah, im doing that as well, but I think it adds flexibility. It can be blocked anyway on the BLESS side, so it only adds additional options.
# By default, kmsauth requires that requested bastion_user must be the same as the requested remote_usernames. If you
# want Bless to sign a certificate for a different remote_usernames (like root, or a shared admin account), you must
# specify those allowed names here. * will allow signing for all remote_usernames
# kmsauth_remote_usernames_allowed = ubuntu,root,ec2-user
Hey, sorry for the slow response-- I think it's a good idea, and wanted to test it in a few situations before merging it. Testing for use here at Lyft all checks out, so I'm going to merge it. Thanks!
Right now I dont have a way to specify a remote username to SSH as (such as
ec2-user
). This allows that and falls back safely to the current default, the IAM user requesting the certificate to be signed.