Skip to content

AWS Identity And Access Management (IAM)

Basics

  • Globally is resilient service
  • The IAM in each account is seperate from IAM in any other account
  • Your account only trusts IAM from your account
  • IAM supports 3 types of identities
  • Users
  • Roles - Granting access to an uncertain number of users either on permanent or on temporary basis. Also used to grant access to services
  • Groups - Collection of related users
  • IAM policy/policy documents are used to grant access to IAM identities
  • IAM also performs Authentication & Authorization
  • IAM is free service
  • IAM can only control access for identities within the account. It can not directly control external identities

Access Keys

  • Access Keys are long term credentials
  • IAM user can have 0 to 2 access keys. They can be created, deleted, made inactive and active
  • Access keys consist of Access Key ID which is the public part & Secret Access Key which is the private part of the key
  • Secret Access Key can only be downloaded once when the access key is created
  • Access keys are used to access aws from command line or through applications
  • IAM users are the only identity that uses access key

IAM Policies

  • Set of security statements
  • Grands or denies access to AWS products and features to any identity that uses the policy
  • Identity policies are json documents
  • Identity Policies cosist of statements
  • An identity proves its credentials to aws & becomes an authenticated identity
  • Each statement has following elements
  • Sid - A user defined identifier
  • Effect - Allow or Deny
  • Action - List of actions on which this policy has effect. wildcard * means all
  • Resource - Resource to which this policy impacts. It can be invidiual resources, list of resources or wildcard
  • If there are multiple statements that apply to a resource, all such statements are collected and evaluated together. The overall effect of all the statements is evaluated based on following priority rules
  • The priority order of applying overlappin policies is
  • Priority 1 - Explicit Deny
  • Priority 2 - Explicit Allow
  • Priority 3 - Implicit Deny
  • Policies can be defined inline or policies could be managed policies. Managed policies can be reused & applied to any number of identities

IAM Users

  • A Principal is any entity which wants access to an AWS resource or service
  • A Principal can be a person or an application
  • Authentication is a process whereby a Principal proves to IAM that it is what it claims to be
  • Authenticaton can be done using UserName + Password or Access Keys. These are long term credentials
  • Once a principal proves its identity it becomes Authenticated Identity
  • IAM gives applicable policies to the Authenticated Identity
  • Authorization is process of IAM granting or denying access based on the policy statements applicable to the Authenticated Identity & the target resource
  • Resources in AWS are identified uniquely using Amazon Resource Name (ARN)
  • ARN naming formats look like fllows
  • arn:partition:service:region:account-id:resource-id
  • arn:partition:service:region:account-id:resource-type/resource-id
  • arn:partition:service:region:account-id:resource-type:resource-id
  • arn:aws:s3:::bucket-name <-- Points to S3 bucket
  • arn:aws:s3:::bucket-name/* <-- Points to objects inside bucket
  • Any AWS account have maximum 5000 IAM Users
  • Any IAM User can belong to maximum 10 Groups

IAM Groups

  • Groups are containers used to organize or manage large number of IAM Users
  • Groups are not Real Identities
  • One can't login to IAM Groups & they don't have any credentials
  • Policies can be attaced to Groups
  • Groups have no limit on count of users
  • Groups can not be nested
  • IAM Groups can not be referenced as a Principal in a resource policy
  • There is no default Group that has all users in an acccount. If required such a group needs to be created manually and all users need to be added to it manually

IAM Roles

  • Whenever access is required to be given to a large number of prior unknown Principals, IAM Roles are used
  • Roles are usually used for Temporary Access
  • 2 types of Policies i.e. Trust Policy & Permissions Policy can be attached to an IAM Role
  • Trust Policy governs which identities are trusted to assume the role provided they are authenticated appropriately
  • Permissions Policy defines what access a Trusted Identity gets
  • When an Identity allowed by a trust policy assumes a role, temporary security credentials are geenerated
  • The temporary credentials can then access whatever that is permitted by Permissions Policy
  • The temporary credentials are provided by Secure Token Servic i.e. STS. This is done by executing sts:AssumeRole operation
  • Roles can be referenced in a Resource Policy
  • AWS Roles are useful to give permissions to anything that is not an AWS identity e.g. Service, Application or Script.
  • The service performs sts:AssumeRole operation & gets temporary credentials as well as corresponding permissions
  • Role can be used to reuse external identities to give AWS access

Service Linked Role

  • IAM Roles linked to a specific AWS service
  • Provide set of permissions pre defined by a service
  • These roles can be created by service itself or might allow the user to create them during setup or they might be crated within IAM
  • Service linked roles can not be deleted unless they are no longer required
  • Role seperation can be achieved by giving certain group of users(administrators) permission to create service linked role while other group permission to use the role
  • A user needs ListRole & PassRole permission to assign it to a service
  • A user needs CreateServiceLinkedRole permission to create it