Ref: https://learn.cantrill.io/courses/1820301/lectures/41301368

• Summary
• Contents:

1. Grant AWS Services Permissions to Perform Actions

• For AWS services or resources to operate on your behalf and perform certain actions, they need certain access rights → they use IAM roles

• Example: A Lambda function needs an IAM role (called its Lambda Execution Role)
  • 💡 A Lambda function is not an identity, by default has no permissions
  • This role trusts Lambda to perform actions. It can be assumed by the Lambda function to get temporary credentials and permissions to perform its task (e.g. write permissions needed to update an object in S3)
  • Unknown number of Principals → Multiple identical Lambda functions can assume the same role and operate simultaneously
  • ‼️ It’s highly impractical to hard code long-term credentials/access keys in Lambda!
    • Security risk (keys are exposed within the code)
    • Rotating keys is inflexible (you need to go into the code to update them)
    • Another identical Lambda function can't operate simultaneously, since the long-term keys are in use by the first Lambda function

2. Grant Additional Permissions in Extraordinary Situations

• “Break glass for key”-style of situations → you only assume role in emergencies
  • Usage of this emergency role is logged → viewable/auditable by everyone → identities know to use role only in emergencies (otherwise serious accountability to be done)
  • 💡 Just like a normal “break glass for key” situations in a physical warehouse, everyone can see if the glass was broken

• Example: A help-desk group normally only has read-only access to help customers. But in emergency situations (e.g. Sunday at 3 a.m. when admins are unavailable) they can assume an emergency role with write permissions to put out a fire.

3. Adding AWS Access to an Existing Corporation Environment

• Many corporations have big user directories (databases with users, identities, printers, servers…) with lots of existing identities
  • Typical case: Microsoft Active Directory (MS AD) is very popular in big corporations
  • External users/identities can't access AWS directly, but they can via IAM roles that use identity federation

• Identity Federation → IAM role used to grant access to the identities in a corporate user directory like MS AD
  • Only way if MS AD has >5000 users already
  • Also allows corporation to use a unified Single-Sign On (SSO) interface for users to sign in and access AWS resources
  • Users use their MS AD credentials to log in via the SSO, then under the hood they assume the IAM role (become federated identities) and get access to AWS resources
  • All MS AD users can assume the same role simultaneously → normally user name/ID from the MS AD also logged to know who exactly assumed the role

4. Designing an App with Many Users (e.g. a Mobile App)