You can also use ec2-instance-connect[0] to enable users to generate ephemeral keys that are valid for a few minutes, authenticated with IAM. The benefit is that it's all native after you've pushed your keys using either aws-cli or mssh.
It has more or less the same benefits that SSM has, and you can use the same method with ProxyCommand to establish authentication before connecting. You can also chain it using ProxyJump to use a bastion host. Wrapped in a tool like aws-vault you can quite easily work with 2FA and such.
Does ec2-instance-connect use the generic system account or does each AIM user/role get it's own instance account? Asking from an auditing and logging perspective, as in is there a way to tie back a command which was run back to an individual human directly?
It has to use an existing system account, yes. You do lose a lot of auditing abilities this way, since you cannot capture the content. For me this is more about establishing a secure way to grant people access to instances, without something like LDAP or SSH CA.
LDAP sends passwords in cleartext over an encrypted channel, I don't like the idea of someone else on the host I'm connecting to being able to read my password. Naturally you can use key based authentication with it.
I know that some people are required by law or regulation to log all these things, but personally I don't see much benefit of such audit logs. All bets are off when someone has local access to a machine. And there's this whole debate about using MitM-proxies for logging and security and the potential security implications they pose.
All that said, step-ca[0] and vault[1] looks really promising to provide some kind of provider independent way to authenticate in a secure manner. You also have teleport[2] but I haven't looked much into it.
Thanks for the links, Teleport seems especially interesting.
Yeah, we are required by contractual obligations to log these things or at least sudo commands. Don't disagree that it's less than useful but only so many things you can argue about. The logging we can do with auditd but we need unique instance users for that to be useful.
No, but it requires you to either have some kind of peering, Client VPN Endpoint or a bastion host. I prefer a VPN or bastion host, since you add another layer of authentication in between. With Client VPN Endpoint you can also limit network access on a per-user basis to further lock down things.
Comments
You can also use ec2-instance-connect[0] to enable users to generate ephemeral keys that are valid for a few minutes, authenticated with IAM. The benefit is that it's all native after you've pushed your keys using either aws-cli or mssh.
It has more or less the same benefits that SSM has, and you can use the same method with ProxyCommand to establish authentication before connecting. You can also chain it using ProxyJump to use a bastion host. Wrapped in a tool like aws-vault you can quite easily work with 2FA and such.
[0] https://aws.amazon.com/about-aws/whats-new/2019/06/introduci...
Shameless plug for a tool I build for ec2-instance-connect: https://github.com/nodefortytwo/amz-ssh
I think the advantage of not having to have a public bastion is pretty nice though. I think i'd consider SSM over ec2-instance-connect
Does ec2-instance-connect use the generic system account or does each AIM user/role get it's own instance account? Asking from an auditing and logging perspective, as in is there a way to tie back a command which was run back to an individual human directly?
It has to use an existing system account, yes. You do lose a lot of auditing abilities this way, since you cannot capture the content. For me this is more about establishing a secure way to grant people access to instances, without something like LDAP or SSH CA.
LDAP sends passwords in cleartext over an encrypted channel, I don't like the idea of someone else on the host I'm connecting to being able to read my password. Naturally you can use key based authentication with it.
I know that some people are required by law or regulation to log all these things, but personally I don't see much benefit of such audit logs. All bets are off when someone has local access to a machine. And there's this whole debate about using MitM-proxies for logging and security and the potential security implications they pose.
All that said, step-ca[0] and vault[1] looks really promising to provide some kind of provider independent way to authenticate in a secure manner. You also have teleport[2] but I haven't looked much into it.
[0] https://smallstep.com/docs/cli/ssh/ [1] https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert... [2] https://gravitational.com/teleport/
Thanks for the links, Teleport seems especially interesting.
Yeah, we are required by contractual obligations to log these things or at least sudo commands. Don't disagree that it's less than useful but only so many things you can argue about. The logging we can do with auditd but we need unique instance users for that to be useful.
(disclaimer, I was a founder of ScaleFT - acquired by Okta)
This is exactly why many customers use Okta's Advanced Server Access: https://www.okta.com/products/advanced-server-access/
It does certificates as a credentialing mechanism, but also full separate accounts, lifecycle management of accounts and sudo files.
Doesn't that still require the instance to have a public IP? I think the original solution doesn't even need a public IP.
No, but it requires you to either have some kind of peering, Client VPN Endpoint or a bastion host. I prefer a VPN or bastion host, since you add another layer of authentication in between. With Client VPN Endpoint you can also limit network access on a per-user basis to further lock down things.