3 ms·

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 perspecti

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?

vegardx 7y ago
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/ https://smallstep.com/docs/cli/ssh/ [1] https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates/ https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert... [2] https://gravitational.com/teleport/ https://gravitational.com/teleport/
- marcinzm 7y ago
  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.
  - pquerna 7y ago
    (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/ 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.

vegardx 7y ago

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/ https://smallstep.com/docs/cli/ssh/ [1] https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-certificates/ https://www.vaultproject.io/docs/secrets/ssh/signed-ssh-cert... [2] https://gravitational.com/teleport/ https://gravitational.com/teleport/

marcinzm 7y ago
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.
- pquerna 7y ago
  (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/ 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.