Demystifying AWS IAM (a little, anyway)

Identity Access Management (IAM) from Amazon Web Services (AWS) provides the tools necessary for AWS customers to create identities and manage the interplay between identities and resources.

IAM is different than the traditional permissions based model. Users usually do not have permissions directly assigned to them. Instead, the common model is to require a user to assume a role before permissions are assigned to them. Policies are attached to roles which determine who can assume a role and the role itself defines who (or what) can assume it under specific conditions. For instance, if you look at this particular role:

You can see that the role itself defines a principal, an action and a condition in its attached policy document. The principal in this case is who’s allowed to assume this particular role… we can see that the root user for account 987654321098 is allowed to assume this role provided that user has two factor authentication enabled.

Each of the roles will have a policy attached that defines things like the resources it operates on, the things that are allowed, etc. and those roles are then assumed by various users. Each resource, then, will have a policy attached that requires a specific role before it can be accessed. In some cases, multiple role chains must be assumed (assume a role, which can then assume another role). The mapping is generally not a straightforward “this user maps to this permission set”.

There’s quite a bit more to IAM, of course, but this in a nutshell is the root of how it works. From this point, you’d create a policy and attach that policy to a resource (such as an EC2 instance or an S3 bucket). This policy would define what role is allowed to access it and what that role can do with the resource.

Users are not really the identity here, roles are the identity. A user assumes an identity (role) and that identity can do very specific and granular things to a resource. This is sort of a reversal of the traditional RBAC policy where you define a user and then give that user specific rights (either directly or inherited from a group).

There’s no way I can condense all of IAM into a short blog post, but this should be enough to pique your interest and hopefully demystify it a little bit. Comments, as always, are welcome.

This article was originally published on LinkedIn.