1_Identity Access Management (IAM)

Question 1

IAM consists of the following:

• Users (provides one login with its own specified permission)
• Group (a way to group our users and apply policies to them collectively)
• Roles (a simple way to delegate groups of permissions to specific users or AWS services)
• Policy Documents (contains permissions which specify which actions an entity can perform and on which resources in JSON format)

Answer 1

IAM consists of the following:

• Users (provides one login with its own specified permission)
• Group (a way to group our users and apply policies to them collectively)
• Roles (a simple way to delegate groups of permissions to specific users or AWS services)
• Policy Documents (contains permissions which specify which actions an entity can perform and on which resources in JSON format)

Question 2

IAM

• IAM is universal. It does not apply to regions at this time
• The “root account” is simply the account created when first setup your AWS account. It has complete Admin access.
• New Users have NO permissions when first created
• New Users are assigned Access Key ID & Secret Access Key when first created
• There are not the same as a password, and you cannot use the Access Key ID & Secret Access Key to login in to the console. You can use this to access AWS via the APIs and Command Line however
• You only get to view these once. If you lose them, you have to regenerate them. So save them in a secure location

Answer 2

IAM

• IAM is universal. It does not apply to regions at this time
• The “root account” is simply the account created when first setup your AWS account. It has complete Admin access.
• New Users have NO permissions when first created
• New Users are assigned Access Key ID & Secret Access Key when first created
• There are not the same as a password, and you cannot use the Access Key ID & Secret Access Key to login in to the console. You can use this to access AWS via the APIs and Command Line however
• You only get to view these once. If you lose them, you have to regenerate them. So save them in a secure location

Question 3

IAM - Best practices

• Remove all access/secret keys from your root account
  
  • Do not use your root account for anything other than billing related activities
  • Create individual IAM accounts with Admin privileges, mapped to actual persons, for any other work.
• Always setup Multifactor Authentification on your root account
• Grant least privilege
• Configure a strong IAM password policy for IAM users
• Use policy conditions for increased granularity
• Use CloudTrail to keep a history of activity
• Enforce a strong IAM password policy for IAM users
• Remove all unused users and credentials

Answer 3

IAM - Best practices

• Remove all access/secret keys from your root account
  
  • Do not use your root account for anything other than billing related activities
  • Create individual IAM accounts with Admin privileges, mapped to actual persons, for any other work.
• Always setup Multifactor Authentification on your root account
• Grant least privilege
• Configure a strong IAM password policy for IAM users
• Use policy conditions for increased granularity
• Use CloudTrail to keep a history of activity
• Enforce a strong IAM password policy for IAM users
• Remove all unused users and credentials

Question 4

IAM - Best Practices

• Use IAM roles for applications that run on Amazon EC2 instances
• Delegate by using roles instead of by sharing credentials

To grant applications on an Amazon EC2 instance access to AWS resources, developers might distribute their credentials to each instance. Applications can then use those credentials to access resources such as Amazon S3 buckets or Amazon DynamoDB data. However, distributing long-term credentials to each instance is challenging to manage and a potential security risk. You can create a role with appropriate access for AWS resources and assign the role to the Amazon EC2 instance to solve this issue.

Answer 4

IAM - Best Practices

• Use IAM roles for applications that run on Amazon EC2 instances
• Delegate by using roles instead of by sharing credentials

To grant applications on an Amazon EC2 instance access to AWS resources, developers might distribute their credentials to each instance. Applications can then use those credentials to access resources such as Amazon S3 buckets or Amazon DynamoDB data. However, distributing long-term credentials to each instance is challenging to manage and a potential security risk. You can create a role with appropriate access for AWS resources and assign the role to the Amazon EC2 instance to solve this issue.

Question 5

IAM Policies

• JSON format
• Most restrictive policy wins
• All permissions are implicitly denied by default
• If something is explicitly denied, it can never be allowed
• IAM permission hierarchy:
  
  1. Explicit Deny
  2. Explicit Allow
  3. Implicit Deny

Answer 5

IAM Policies

• JSON format
• Most restrictive policy wins
• All permissions are implicitly denied by default
• If something is explicitly denied, it can never be allowed
• IAM permission hierarchy:
  
  1. Explicit Deny
  2. Explicit Allow
  3. Implicit Deny

Question 6

How do I access to AWS?

Answer 6

How do I access to AWS?

Question 7

IAM Role scenarios

• Service access for e.g. EC2 to access S3 or DynamoDB
• Cross Account access for users
  
  • with user within the same account
  • with user within an AWS account owned by the same owner
  • with user from a Third Party AWS account with External ID for enhanced security
• Identity Providers & Federation
  
  • Web Identity Federation, where the user can be authenticated using external authentication Identity providers like Amazon, Google or any OpenId IdP using AssumeRoleWithWebIdentity
  • Identity Provider using SAML 2.0, where the user can be authenticated using on premises Active Directory, Open Ldap or any SAML 2.0 compliant IdP using AssumeRoleWithSAML
  • For other Identity Providers, use Identity Broker to authenticate and provide temporary Credentials using AssumeRole (recommended) or GetFederationToken

Answer 7

IAM Role scenarios

• Service access for e.g. EC2 to access S3 or DynamoDB
• Cross Account access for users
  
  • with user within the same account
  • with user within an AWS account owned the same owner
  • with user from a Third Party AWS account with External ID for enhanced security
• Identity Providers & Federation
  
  • Web Identity Federation, where the user can be authenticated using external authentication Identity providers like Amazon, Google or any OpenId IdP using AssumeRoleWithWebIdentity
  • Identity Provider using SAML 2.0, where the user can be authenticated using on premises Active Directory, Open Ldap or any SAML 2.0 compliant IdP using AssumeRoleWithSAML
  • For other Identity Providers, use Identity Broker to authenticate and provide temporary Credentials using AssumeRole (recommended) or GetFederationToken