A Tale of Two AWS IAM Roles (in Springfield)

As a long-time fan of classic The Simpsons, when I need an analogy to help a colleague or myself to comprehend a subject, I find it natural to make use of characters and situations from the show. In this article, I’d like to share one on a topic that at first I found confusing, IAM Roles in AWS and the way users assume them.

A little context: any developer of infrastructure for software in the cloud will, early in that effort, need to figure out how users (both human and machine) are going to be able to access various resources. A best practice is to use multiple accounts to ensure separation among a development environment, a production environment, a management account, and possibly many others. You probably wouldn’t want an IAM user for a given person defined in every one of those accounts; managing permissions for every user in your organization would be terribly repetitive. Also, in most organizations there exist a number of different business functions, and a user who may access Redshift and Kinesis data streams should not necessarily be able to mess around with network infrastructure and backend services.

That’s where role-based access control comes in, and AWS offers two essential strategies for implementing it. One is federation, which involves either Single Sign-On with a directory server or third-party authentication using a web identity provider like Google. A user logs into one of these services to obtain temporary credentials for an IAM user with user-specific policies assigned by the authentication server. The other strategy is delegation, and in this approach, IAM users defined in only one account are allowed to assume certain roles (in that account or in others) that have certain policies. This article will address the latter.

In case you’re wondering which one would be better for your situation, the SSO approach scales better and is practically a necessity for a larger and more mature organization that uses many third-party services and possibly multiple cloud providers. Delegation is less messy and may be easier to manage for a smaller user base, especially if it doesn’t have a dedicated systems/security administrator. One advantage of delegation is that all things IAM (even users) can be defined entirely in code using a tool like Terraform. The two approaches may be combined to obtain the advantages of both.

The Analogy

Bart Simpson attends Springfield Elementary from time to time and when he does, we can say that he is assuming the role of student at the school. That role is assumed on a temporary basis, and only by specific users (school-aged children who live east of the railroad tracks).

In IAM terms, the Simpsons home and Springfield Elementary could be aliases for two accounts. user/bart is defined in the “Simpsons home.” Bart is part of an IAM Group, school-aged-children, and it’s Bart’s membership in that Group that gives him the ability to assume roles. Although Marge Simpson probably doesn’t think of her three children in terms of user groups, having Policies attached directly to Users in a organization larger than the Simpsons family brings problems with manageability and consistency, and so, it’s best practice to assign Users to Groups with group-level Policies.

The ability of Bart to assume the role of student entails a bidirectional relationship with Springfield Elementary. Marge has enrolled Bart in school, conferring upon him (attaching to his IAM Group) a Policy such as:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<school account ID>:role/student"
  }
}

And in turn, Springfield Elementary also allows Bart to assume the role of student there, forming (begrudgingly) a trust relationship with him. A Policy is attached to or defined on role/student:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::<Simpsons home account ID>:root"
    },
    "Action": "sts:AssumeRole",
  }
}

It would be ideal in this case to use the Group school-aged-children as the Principal, but IAM Groups cannot be used as Principals. The Policy must reference either the specific user— e.g., “arn:aws:iam::<Simpsons home account ID>:user/bart” — or the entire Account as defined above.

Extending the Analogy

Occasionally the school sends students on field trips. Due to budget cuts, a frequent destination of them is the Cracker Factory.

Consider that a child generally does not go straight from home to a field trip destination — Marge has no impetus to allow Bart to travel to the cracker factory on his own. He’s able to assume role/field-trip-attendant only as a student, so we attach a Policy like this to the student role (yes, roles may assume other roles):

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<Cracker Factory>:role/field-trip-attendant"
  }
}

And, just as Springfield Elementary allows Bart to attend school, the cracker factory allows Springfield Elementary students to tour their facilities.

Further, Marge provides Bart with a permission slip —user/bart has a Policy attached— that allows him to visit the cracker factory only within certain hours. user/bart is already able to assume role/field-trip-attendant by assuming it indirectly through role/student; this policy effectively introduces additional constraints by taking advantage of IAM policy evaluation logic.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<Cracker Factory>:role/field-trip-attendant",
    "Condition": {
      "DateGreaterThan": {
        "aws:CurrentTime": "2020-03-01T17:00:00Z"
      },
      "DateLessThan": {
        "aws:CurrentTime": "2020-03-01T18:59:59Z"
      }
    }
  }
}

At this point I should mention that this implementation is an oversimplification of the analogy case. Of course, Springfield Elementary won’t just allow any student to leave for a tour of the cracker factory at any time, as much as the children may yearn to do so. The student role could be given a Policy that at all times, mirrors the permissions granted to the students by the parents on an individual basis.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<Cracker Factory>:role/field-trip-attendant",
    "Condition": {
      "StringLike": {
        "aws:userid": [
          "arn:aws:iam::<Simpsons home>:user/bart",
          "arn:aws:iam::<Van Houten home>:user/milhouse",
          ...
        ]
      },
      "DateGreaterThan": ...,
      "DateLessThan": ...
    }
  }
}

However, an actual AWS scenario would have all accounts managed by one team, not by disparate groups (parents, school, cracker factory manager) that aren’t necessarily synced with each other, so one might consider these additional role constraints overly defensive.

Some Practical Notes

• The permission “sts:AssumeRole” may be allowed for Users, Roles, Services, and a few other principal types.
• In the AWS Console, a role may be assumed by going into the account dropdown in the upper right and selecting Switch Role. The CLI command is aws sts assume-role --role-arn <arn>.
• Permissions boundaries are a perfectly cromulent way to define user permissions in broad strokes. A role-level boundary could allow “ec2:*”, while a user group that can assume that role could have a more restrictive policy that denies, say, “ec2:AuthorizeSecurityGroupIngress”.
• Note that assumed role sessions (time-limitation entities created upon assuming a role) have a maximum duration of twelve hours (more than enough for Bart’s school day, not including detention). An exception to this is a role session obtained by assuming a role from another role, which is limited to one hour. When that’s not enough, the role must be assumed directly by the user.

Summary

My goal for this was to share a simple analogy for IAM roles and role assumptions. It’s my sincere hope that this writing has embiggened your spirit. I welcome your feedback and thank you for reading.