Complete IAM Beginner Guide/Notes: What is IAM in AWS?
Complete IAM Introduction
IAM stands for "Identity and Access Management" which offers a centralized hub of control within AWS and integrates with all other AWS Services.
IAM is the GateKeeper or Security Guard of all the AWS resources.
IAM comes with MFA(Multi-factor Authentication) support and allows you to set up a custom password rotation policy across your entire organization.
You can grant other people permission to administer and use resources in your AWS account without having to share your password or access key.
You can grant different permissions to different people for different resources.
For example, you might allow some users complete access to Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift, and other AWS services.
For other users, you can allow read-only access to just some S3 buckets, or permission to administer just some EC2 instances or to access your billing information but nothing else.
Secure access to AWS resources for applications that run on Amazon EC2 You can use IAM features to securely provide credentials for applications that run on EC2 instances.
These credentials provide permissions for your application to access other AWS resources. Examples include S3 buckets and DynamoDB tables.
You can add two-factor authentication to your account and to individual users for extra security.
With MFA you or your users must provide not only a password or access key to work with your account but also a code from a specially configured device.
IAM Entities
Users - Any individual end user such as an employee, system architect, CTO, etc.
Groups - Any collection of similar people with shared permissions such as system administrators, HR employees, finance teams, etc. Each user within their specified group will inherit the permissions set for the group.
Roles - Any software service that needs to be granted permissions to do its job, e.g- AWS Lambda needs write permissions to S3 or a fleet of EC2 instances needing read permissions from an RDS MySQL database.
Policies - The documented rule sets that are applied to grant or limit access. In order for users, groups, or roles to properly set permissions, they use policies. Policies are written in JSON and you can either use custom policies for your specific needs or use the default policies set by AWS.
IAM Policies are separated from the other entities above because they are not an IAM Identity.
Instead, they are attached to IAM Identities so that the IAM Identity in question can perform its necessary function.
IAM Policies
With IAM policies you can manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources.
A policy is an object in AWS that, when associated with an identity or resource, defines its permissions.
AWS evaluates these policies when an IAM principal (user or role) makes a request.
Most policies are stored in AWS as JSON documents. It is not necessary for you to understand the JSON syntax.
You can use the visual editor in the AWS Management Console to create and edit customer-managed policies without ever using JSON.
To create IAM policies, you have to create a JSON document. See the JSON document structure below:
Version
Specify the version of the policy language that you want to use. As a best practice, use the latest "2012-10-17" version. IAM also supports version "2008-10-17". This is an old version of policy, it is recommended to use latest version("2012-10-17") for policy creation.
Statement
The Statement element is the main element for a policy. This element is required. The Statement element can contain a single statement or an array of individual statements.
Each individual statement block must be enclosed in curly braces { }. For multiple statements, the array must be enclosed in square brackets [ ].
"Statement": [{...},{...},{...}]
Sid
You can provide Sid (statement ID) as an optional identifier for the policy statement.
You can assign a Sid value to each statement in a statement array. You can use the Sid value as a description for the policy statement.
"Sid": "1
Effect
The Effect element is required and specifies whether the statement results in an allow or an explicit deny.
Valid values for Effect are Allow and Deny. The Effect value is case-sensitive.
"Effect":"Allow"
"Effect":"Deny"
Principal
Use the Principal element in a resource-based JSON policy to specify the principal that is allowed or denied access to a resource.
You must use the Principal element in resource-based-policies.
Several services support resource-based policies, including IAM. The IAM resource-based policy type is a role trust policy.
You cannot use the Principal element in an identity-based policy.
Identity-based policies are permissions policies that you attach to IAM identities (users, groups, or roles).
In those cases, the principal is implicitly the identity where the policy is attached.
For example, given an account ID of 123456789012, you can use either of the following methods to specify that account in the Principal element:
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
"Principal": { "AWS": "123456789012" }
Action
The Action element describes the specific action or actions that will be allowed or denied. Statements must include either an Action or NotAction element.
Each AWS service has its own set of actions that describe tasks that you can perform with that service.
You specify a value using a service namespace as an action prefix (iam, ec2, sqs, sns, s3, etc.) followed by the name of the action to allow or deny.
#Amazon EC2 action
"Action": "ec2:StartInstances"
#IAM action
"Action": "iam:ChangePassword"
#Amazon S3 action
"Action": "s3:GetObject"
#You can specify multiple values for the Action element.
"Action": [ "sqs:SendMessage", "sqs:ReceiveMessage", "ec2:StartInstances", "iam:ChangePassword", "s3:GetObject" ]
Resource
If you create an IAM permissions policy, you must specify a list of resources to which the actions apply.
The Resource element specifies the object or objects that the statement covers. Statements must include either a Resource or a NotResource element. You specify a resource using an ARN.
#The following example refers to the IAM user named Bob in an AWS account.
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/Bob"
Condition
Use condition operators in the Condition element to match the condition key and value in the policy against values in the request context.
The following example uses the StringLike condition operator to perform string matching with a policy variable to create a policy that lets an IAM user use the Amazon S3 console to manage his or her own "home directory" in an Amazon S3 bucket.
The policy allows the specified actions on an S3 bucket as long as the s3:prefix matches any one of the specified patterns.
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::BUCKET-NAME",
"Condition": {"StringLike": {"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]}}
}
Example of an IAM policy:-
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::confidential-data",
"arn:aws:s3:::confidential-data/*"
],
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
]
}
The following example shows a JSON policy that allows the user to perform all Amazon DynamoDB actions (dynamodb:*) on the Books table in the 123456789012 account within the us-east-2 Region.
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
}
}
Policy Types
The following policy types, listed in order from most frequently used to less frequently used, are available for use in AWS.
Identity-based policies – Attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity.
Resource-based policies – Attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies.
Resource-based policies grant permissions to the principal that is specified in the policy. Principals can be in the same account as the resource or in other accounts.
Permissions boundaries – Use a managed policy as the permissions boundary for an IAM entity (user or role).
That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions.
Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity.
Organizations SCPs – Use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU).
SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions.
Access control lists (ACLs) – Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached.
ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure.
ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.
Session policies – Pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user.
Session policies limit the permissions that the role or user's identity-based policies grant to the session.
Session policies limit permissions for a created session, but do not grant permissions.
Priority Levels in IAM
Explicit Deny: Denies access to a particular resource and this ruling cannot be overruled.
AWS checks each policy that applies to the context of your request. If a single permissions policy includes a denied action, AWS denies the entire request and stops evaluating. This is called an explicit deny.
Explicit Allow: Allows access to a particular resource so long as there is not an associated Explicit Deny.
Default Deny (or Implicit Deny): IAM identities start off with no resource access. Access instead must be granted.
The evaluation logic for a request within a single account follows these general rules:
By default, all requests are denied. (In general, requests made using the AWS account root user credentials for resources in the account are always allowed.)
An explicit allow in any permissions policy (identity-based or resource-based) overrides this default.
The existence of an Organizations SCP, IAM permissions boundary, or a session policy overrides the allow.
If one or more of these policy types exists, they must all allow the request. Otherwise, it is implicitly denied.
An explicit deny in any policy overrides any allows.
Note:- Only service control policies (SCPs) in organizations can restrict the permissions that are granted to the root user.
Summary
IAM is a global AWS services that is not limited by regions. Any user, group, role or policy is accessible globally.
The root account with complete admin access is the account used to sign up for AWS. Therefore, the email address used to create the AWS account for use should probably be the official company email address.
New users have no permissions when their accounts are first created. This is a secure way of delegating access as permissions must be intentionally granted.
When joining the AWS ecosystem for the first time, new users are supplied an access key ID and a secret access key ID when you grant them programmatic access.
These are created just once specifically for the new user to join, so if they are lost simply generate a new access key ID and a new secret access key ID.
Access keys are only used for the AWS CLI and SDK so you cannot use them to access the console.
When creating your AWS account, you may have an existing identity provider internal to your company that offers Single Sign On (SSO).
If this is the case, it is useful, efficient, and entirely possible to reuse your existing identities on AWS. To do this, you let an IAM role be assumed by one of the Active Directories.
This is because the IAM ID Federation feature allows an external service to have the ability to assume an IAM role.
IAM Roles can be assigned to a service, such as an EC2 instance, prior to its first use/creation or after its been in used/created.
You can change permissions as many times as you need. This can all be done by using both the AWS console and the AWS command line tools.
You cannot nest IAM Groups. Individual IAM users can belong to multiple groups, but creating subgroups so that one IAM Group is embedded inside of another IAM Group is not possible.
With IAM Policies, you can easily add tags that help define which resources are accessible by whom.
These tags are then used to control access via a particular IAM policy. For example, production and development EC2 instances might be tagged as such.
This would ensure that people who should only be able to access development instances cannot access production instances.
IAM users are not separate accounts; they are users within your account. Each user can have its own password for access to the AWS Management Console.
You can also create an individual access key for each user so that the user can make programmatic requests to work with resources in your account.
If your corporate directory is compatible with Security Assertion Markup Language 2.0 (SAML 2.0), you can configure your corporate directory to provide single-sign on (SSO) access to the AWS Management Console for your users.
Assume that you have three projects, named Heart, Sun, and Lightning, on which your employees work. You create an IAM role for each project.
You then attach policies to each IAM role to define the resources that anyone allowed to assume the role can access.
If an employee changes jobs within your company, you assign them to a different IAM role.
People or programs can be assigned to more than one role. However, the Sun project might require additional resources, such as a new Amazon S3 bucket.
In that case, you must update the policy attached to the Sun role to specify the new bucket resource. Otherwise, Sun project members are not allowed to access the new bucket.
I hope you like the article, please comment your thoughts below.