Identity and Access Management is the primary service that handles authentication and authorization within AWS environments. System architecture is incomplete without being able to control access in a granular way.

IAM controls access to AWS services via policies that can be attached to users, groups, and roles. Users are given long-term credentials to access AWS resources (username/password or access keys (command line)). Roles allow for short-term access to resources when assumed, using temporary access credentials.

ARN: Each user has a unique ARN (Amazon Resource Name). ARN always begin with :

arn:partition:service:region:account-id:

partition = aws or aws-cn (for China)

Service = the AWS service: s3, ec2, rds, dynamodb etc

region = region code: us-east-1, ap-souteast-2 etc

And depending on service, finish with :

resource

resourcetype/resource

resourcetype/resource/qualifier

Example ARNs:

arn:aws:iam::123456789012:user/user1

arn:aws:s3:::pics/truffs.jpeg

All IAM users upon creation have an implicit deny to all AWS resources.

IAM Policy:

An IAM policy (policy document) is known as an identity policy when attached to an identity or a resource policy when attached to a resource. They have no effect until they are attached to something. A policy document is a list of statements:

{

       "Version": "2012-10-17",

       "Statement": [{...},{...},{...}]

}

Each statement matches a request to AWS. Requests are matched based on their Action (or actions), which are the API calls or operations being attempted and the Resource (or resources) the request is against. A given statement results in an Allow or Deny for the request.

• If a request is not explicitly allowed, it is implicitly (by default) denied.
• If a request is explicitly denied, it overrides everything else.
• If a request is explicitly allowed, it is allowed unless denied by an explicit deny.
• Remember: DENY-->ALLOW-->DENY
• Only attached policies have any impact.
• When evaluating policies, all applicable policies are merged:
  • All identity (user, group, role) and any resource policies
• Managed policies allow the same policy to impact many identities.
• Inline policies allow exceptions to be applied to identities.
• AWS-managed policies are low overhead but lack flexibility.
• Customer managed policies are flexible but require administration.
• Both Inline and managed policies can apply to users, groups and roles.

IAM Users:

IAM users are a type of IAM identity suitable for long-term access for a known entity (human, service, application). Principals authenticate to IAM users either with a username and password or using access keys.

AWS software development kits (SDKs) and CLI use access keys during authentication. Authenticated identities are authorized for resource access based on any line or attached policies. Console access authentication is achieved using username, password, and optional MFA.

• Hard limit of 5000 IAM users per account - this is important as it can impact architecture
• 10 group memberships per IAM user
• Default maximum of 10 managed policies per user
• No inline limit, but we cannot exceed 2048 characters for all inline policies on a IAM user
• 1 MFA per user
• 2 access keys per user

IAM Group is a collection of IAM users. Groups allow easier administration over sets of IAM users. Inline and managed policies can be applied to groups that flow on to members (users) of that group. Groups are not true identity - they cannot be the principal in a policy, so they cannot be used in resource policies.

• Groups are an admin feature to group IAM users.
• Groups can contain many IAM users, and users can be in many groups.
• IAM inline policies can be added to IAM groups - and these flow on to IAM users who are members.
• Managed IAM policies can be attached and flow on to IAM users who are members.
• Groups are not true identities, and they cannot be referenced from resource policies.
• Groups have no credentials.

Access Keys are a pair of values used by applications, SDKs or the AWS command line to authenticate to AWS. Access keys consist of two parts; the access key ID and secret access key. The access key ID is the public part of the key and is stored by AWS once generated. Secret access key is the sensitive and private part of the access key, available only once when the access key is initially generated. It's stored only by the owner and should never be revealed.

An IAM user is the only identity that uses access keys. Each IAM user is allowed two sets of access keys. These sets can be created, deleted, enabled and disabled. These cannot be used to log in to the console, and these do not expire. If anyone finds a set of access keys, they have access to the permissions of the IAM user to which they belong.

AWS Command Line Interface Tool

• Install AWS CLI on your machine.
• Run AWS CLI

aws configure

(input AWS Access Key ID and Secret Access Key, region: us-east-1, output: json)

aws s3 ls

IAM Roles

IAM roles are assumed by another identity allowed in the trust policy - IAM user, AWS service, another AWS account, web identity or even an anonymous identity. When a role is assumed, the Security Token Service (STS) generates a time-limited set of access keys (temporary security credentials). These access keys have the permissions defined in the permission policy. IAM roles have no long-term credentials (access keys or username and password). Every role has two policies. Trust Policy and Permissions Policy. Permission Policy is an IAM policy that gives permission to a role for certain actions (e.g. AmazonS3ReadOnly Access). The Trust Policy specifies the service that can assume the role (e.g. EC2 service can assume the role to access S3 as per the permission policy of AmazonS3ReadOnly). Or a company B's AWS account is added to the Trust policy to assume the role in Company A's AWS account to access resources. Or there are 10 AWS accounts for Company C and 10 users need to access these 10 AWS accounts. Best way is to create one IAM user in one of the AWS account and create a Trust policy to let that IAM user access other 9 AWS accounts.

Roles cannot be used for Anti-Patterns scenarios. For example; Roles cannot be used for logins to an AWS account as roles do not have any usernames/passwords or access keys. However, a Role can be granted a super user kind of permission in emergency scenarios.

• IAM roles have no long term credentials.
• They are sts:AssumeRole by another identity:
  • IAM users
  • AWS services
  • External accounts
  • Web identities
• Temporary security credentials are generated by STS
• Trust policy controls which identities can assume the role
• Permission policy defines the permission provided
• Temporary credentials expire
• Example scenarios:
  • Company merger
  • AWS service access
  • Break glass style extra access
  • Cross account access
  • Web identity federation

AWS Organizations

AWS Organizations is useful for businesses that need to manage multiple accounts. It provides the following features:

• Consolidated billing
• Service control policies (SCPs)
• Account creation
• Simplified role switching

AWS Organizations is a service for managing multiple accounts within a single business. Rather than managing many accounts, with many isolated sets of logins and individual bills, Organizations allows consolidation.

All accounts within an AWS Organization can consolidate bills into a single account (master account) - one bill covering all business usage. Organizations can share bulk discounts and even easily manage accounts and permissions and limit account usage using service control policies. From the master account, we can create new accounts and using roles, we can switch to those accounts. In Root node, we can create multiple units (e.g. Dev, production etc) and we can then move our accounts into those units. We can leave the master account in the root node. By default, AWS Organization can have two AWS accounts. We need to open a service related ticket via the support center to increase the number of AWS accounts into the AWS Organization.

Service Control Policy: By default, FullAWSAccess policy is present in AWS Organization. In master account, goto Policy and look for the default policy name "FullAWSAccess". Copy the JSON code of that policy. Now click create policy. Name the policy s3only. Paste the JSON code in Policy and edit as per below.

"Action": "s3:*",

Click Create Policy. Now we will apply this policy to our Dev account. We will go to Root node and click enable Service Control Policies. Select the Dev Unit (OU) and select the dev account that resides there. Go to Service Control Policies, Detach the FullAWSAccess policy and attach the s3only policy. Now we can verify the changes by switching role to dev account and try to launch an EC2 instance. It should fail. Service Control policy does not effect master account. However, SCP can restrict root users of other AWS Accounts within same AWS Organizations.

Role Switching is a method of accessing one account from another using only one set of credentials. It is used both within AWS Organizations and between two unconnected accounts.

1. A role in Account B trusts Account A.
2. An identity in Account A can assume the role in Account B and using that role, it can operate inside Account B.

To switch role, we need to be login as an IAM role in our master account. We will then note down the account id of the AWS account that we want to switch into to use its resources. From AWS Organizations menu, account drop down select role switch. Click Switch Role. Fill in the Account ID, Role as "AWSOrganizationAccountAccessRole". Put Display name as the unit that account is in (e.g. Dev, production etc). Select a color for that account. Click Switch Role.

Next: Compute