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

• Summary
• Contents:

IAM Role - Key Concepts

• 🔧 IAM identity with short-term credentials
  • Intended to be used by multiple Principals (exact number can be unknown!) → In contrast: IAM users are intended to be used by ONE single Principal
    • 💡 e.g. multiple IAM users in the AWS account, IAM users from another AWS account, AWS-external identities, or even apps/services (internal or external)… all of them can assume one single role to obtain temporary permissions
    • Check next lecture for common use cases of IAM roles: Use Cases for IAM Roles

• IAM roles are ASSUMED → short-term usage, borrow permissions for a short time
  • A Principal becomes that role temporarily, then stops being that role when credentials expire
  • 💡 You can think about this as “putting on a hat” → today you're the usher and get the keys to open the theater and welcome guests in. But at the end of the event, you return the keys to the manager, and next week maybe a different colleague will be the usher instead!
• ‼️ An IAM role does NOT represent a Principal!!
  • It represents a level of access inside an AWS account!

IAM Roles - Architecture

• IAM Roles are “true” IAM identities
  • Have credentials to log in to AWS (short-term, expire quickly)
  • Can have identity policies attached to them (permissions policies)
  • Can be referenced as a Principal within resource policies

• Two types of policies can be attached to a role:
  1. Permissions policy (identity policy) → defines what actions the Principal that assumes the role is authorized to do
     • Same type of policy that can be attached to IAM users & groups
  2. Trust policy → defines which identities can assume that role
     • Allows/denies identities and/or services in the AWS account, identities/services in other AWS accounts, external/federated identities like Facebook, Google users… even anonymous usage!
• Process to access an AWS resource/action with an IAM role:
  1. Principal attempts to authenticate as a role to IAM
  2. IAM checks trust policy of the role, makes sure that the Principal is allowed to assume the role (if not, request is denied)
  3. The Principal asks the AWS Security Token Service (STS) to generate temporary credentials via the sts:AssumeRole operation
  4. If request is not denied, STS generates credentials and the Principal assumes the role, becoming an authenticated identity for a short period of time
  5. If credentials expire, Principal needs to reassume the role → new credentials are generated
     • Many AWS services can handle auto-renewal natively, but if using STS externally (e.g. in your mobile app), you will need to configure auto-renewal if desired