IAM

Solution Architect Associate

Developer Associate

Security Specialty

  • IAM is universal. Creating an account creates it globally.
  • The root account is simply the account created when you first setup the AWS Account. Has complete admin access
  • New users have no permissions when first created (KNOW THIS FOR EXAM)
  • New users are assigned an Access Key ID and Secret Access key when first created if you enable programmatic access
  • Always setup MFA on root account
  • You can create and customize your own password rotation policies
  • IAM Consists of
    • Users
    • Groups
    • Roles (roles are global, likely on the exam!!)
    • Policies
  • You can only see your secret and access keys once. If you lose it, you can regenerate them.
  • Power User Access provides full access to AWS services and resources but not the management of roles and users.
  • Owner = email address tied to user who created the account
  • You can also set up Identity Providers for SSO with AWS. You establish a trust between AWS and the identity provider

Policies

  • Policy documents, written in JSON
  • Statements define permissions, mapping to AWS API requests
  • Statements have an Effect, an Action, a Resource and optionally a Condition
  • Typically you’d create policy documents and assign them to groups, roles or users (but this is not recommended)
  • Roles allow one service to access another service. Groups are used to assign permissions to people

Securing the Root Account

  • The root account is tied to an email address used to sign up for the account
  • This accound ALWAYS has full administrative access to the AWS account
  • Change the initial password
  • Activate MFA
  • Create an admin group for administrators
  • Create individual user accounts for all users, even administrators

Inline vs Managed Policies

  • There are 3 types of IAM policies
    • Managed Policies
      • An IAM policy which is created and administered by AWS
      • AWS provides Managed Policies for common use cases based upon job function
      • These policies allow you to assign appropriate permissions to your users, groups and roles without having to write the policies yourself
      • A single managed policy can be attached to multiple users, groups and roles within the same AWS account and across different accounts
      • You cannot change permissions defined in an AWS Managed Policy (know for exam!!)
    • Customer Managed Policies
      • A stand alone policy that you create and administer within your AWS account
      • You can attach this policy across multiple users, group and roles, but only within your own AWS Account
      • Recommended for use cases where AWS Managed policies don’t meet your needs
    • Inline Policies
      • An IAM policy which is embedded within a user, group or role which it applies
      • You cannot attach an inline policy to multiple groups, users or roles
      • When you delete the user/group/role with an inline policy attached, the policy is also deleted
      • In most cases, AWS recommends using Managed Policies or Customer Managed Policies

STS AssumeRoleWithWebIdentity

  • Security Token Service will return temporary security credentials for users authenticated by a mobile or web application using a web identity provider
  • Cognito is recommended for web and mobile
  • Regular web apps without Cognito can use the assume role with web identity service
  • In a response from this API, you will get the following:
    • In the AssumedRoleUser section, you will get the ARN to the temporary credentials, as well as the assumed role identifier
    • In the Credentials section, you will get a session token, secret access key, and accesskey id, as well as the expiration time stamp

Cross Account Access

  • Cross account access makes it easier for you to work within a multi-account AWS environment by switching roles within the AWS Console

Web Identity Federation

  • Lets you give your users access to AWS resources after they have successfully authenticated with a web-based provider like Google
  • Following successful auth, user receives an authentication code from Web ID provider which they can trade for temporary AWS credentials

Permission Boundaries

  • Used to delegate administration to other users
  • Prevents priviledge escalations or other un-necessary broad permissions
  • Controls the maximum permissions that an IAM policy can grant