In our fourth post on how to federate your Microsoft Active Directory or LDAP user store to AWS we talk about the difference between AWS IAM and managing server users (read Part 1, Part 2, and Part 3).
A common confusion point for AWS administrators is the use of AWS Identity and Access Management (IAM) and the actual management of privileged accounts on the server instances themselves.
The core of the confusion is the belief that creating users on IAM gets you server users! In fact, creating users on IAM gets you control over AWS.
IAM largely controls access to your AWS admin console. You can easily federate access with your existing LDAP or AD user data store with AWS IAM to ensure that the right people have the right levels of access for IAM. IAM helps control who can create servers, manage resources on AWS, and access the AWS console.
IAM does not manage access to individual server instances. That is something that IT admins need to control. IAM can allow users to leverage the generic ec2user, but you’ll want to create individual users on each server to address individual access requests. This helps tighten control / access to server instances. It’s easy to confuse IAM and server user access, but they are actually complementary – you can use IAM for granting access to the AWS admin console and then provision server access for those who need direct server access.
IAM is a key part of AWS’ success in making it easier for organizations to integrate cloud infrastructure into their network. AWS has enabled SAML integration so that any corporate directory that supports SAML v2.0 can also provide users to IAM.
A Directory-as-a-Service™ solution that supports SAML could also be used to provide users to AWS IAM. As IAM provides fine grain control over AWS, DaaS would provide support and management of the actual server users (in face, check out our blog on how to manage users on AWS servers).