IAM Intro - RhysC/AwsCertificationNotes GitHub Wiki

About IAM

AWS Identity Access Managment (IAM) is a service to centrialise the means to control access to the reosurces in your AWS account. It is composed of several components

  • Access Management (Users, Roles, Policies, STS)
  • Identity Federation
  • Multifactor authentication (MFA)

Users

A User represents a physical person that would access AWS resources. This user can have a user name and password to access the AWS console (ie the web application) and or access tokens/secret to access AWS progrmatically. These are not interchangeable in their usage and each can be option for the user (you cant use your access token and secret to log in to thw web site for example). Users can individually set themselves up for MFA access to allow for more secure authentication.

Groups

Groups are a collection of users. Groups are provided to more easily manage permission at a more coarse grained level, that assign permission to groups and then add the user to the group to inheirt those permissions. Groups are not Identiies and can not be identified as a Principle. They are solely to provided a better administration experience.

Roles

Roles allow for assigning permissions to "entities" such as

  • AWS Services
  • Application code running on EC2
  • IAM users in another account (role switching)
  • Federated users authenticating with SAML This is the prefered way of managing access between services, you should not (if possible) use credentials directly to manage interactions bewtween services. Policies can be inlined or attached to roles to provide permission to other resources.

Policies

Policies are (JSON) documents that define one or more permissions to act of AWS resources. Policies can be inlined to the consumer (eg a role can have an inline policy) can be named and referenced. Policies can be attached to User, Groups or Roles. There are predefined policies that can be used or you can create your own custom policies.

SUMMARY

Policies are a means of defining permissions. Policies can be attached to users, Groups and roles. Groups are are means to group users to apply permissions at a more coarse grained level. Users are the aws users (and sometime services) that want to act on AWS resources. Roles are other entities that want to act on aws services, most commonly instances of AWS services Eg a lambda can have a role that allows it to access a specifc dynamodb table.


Features:

  • MFA
  • Password rotation
  • Federated identity
  • PCI DSS Compialnce
  • STS allows for tempory access to resources (e.g via web or mobile application allow a user to access a spscific s3 object)

Best practices

  • Address the security best practice in the main page on your IAM page (Delete root acess keys, MFA, individual IAM users, use groups for applying permissions, apply a password policy)
  • The root account is cretaed when you create the account. You should not use this by default, instead create another user with appropriate permissions

Notes

Sign in URL has your AWS account ID as the subdomain. You can customise this to use a new alias (e.g. you account name)

⚠️ **GitHub.com Fallback** ⚠️