AWS IAM

IAM in AWS

Rohit Singh
Identity Access Management (IAM)

IAM Simplified:

IAM offers a centralized hub of control within AWS and integrates with all other AWS
Services. IAM comes with the ability to share access at various levels of permission
and it supports the ability to use identity federation (the process of delegating
authentication to a trusted external party like Facebook or Google) for temporary or
limited access. IAM comes with MFA support and allows you to set up custom
password rotation policy across your entire organization. It is also PCI DSS compliant
i.e. payment card industry data security standard. (passes government mandated
credit card security regulations).

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 needing write permissions to S3 or a fleet of EC2 instances needing
read permissions from a 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 Key Details:

 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.

Priority Levels in IAM:

 Explicit Deny: Denies access to a particular resource and this ruling cannot be
overruled.
  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.

IAM Security Tools:

IAM Access Advisor(user level)

 Access advisor shows service permissions granted to a user and when those
services were last accessed.
 You can use this information to revise your policies.

IAM Credentials Report(account level)

 a report that lists all of your account users and the status of their various
credentials.

Short notes:

 AWS Identity and Access Management (IAM) is a web service that helps you
securely control access to AWS services and resources for your users. IAM
enables you to manage permissions and access control for your AWS account
in a granular and scalable manner. Here’s a comprehensive overview of IAM:

Key Features

1. Granular Permissions: Define specific permissions for users, groups, and roles
to control access to AWS resources.
2. User Management: Create and manage individual IAM users and their access
credentials.
3. Groups: Use groups to assign permissions to multiple users simultaneously.
4. Roles: Create IAM roles with specific permissions that can be assumed by
trusted entities, including other AWS services, applications, or users from
another AWS account.
5. Policies: Use JSON-based policies to specify permissions. Policies can be
attached to users, groups, and roles.
6. Multi-Factor Authentication (MFA): Enhance security by requiring MFA for
users to access AWS resources.
7. Federated Access: Allow users from external systems (like corporate directories
or web identity providers) to access AWS resources without creating IAM
users.
 8. Temporary Security Credentials: Generate temporary security credentials
using IAM roles for applications and services.

Key Components

1. Users: Represents an individual with a specific set of permissions. Users can be

employees, applications, or services.
2. Groups: Collections of IAM users. Permissions assigned to a group are
inherited by all group members.
3. Roles: Defines a set of permissions that can be assumed by users, services, or
applications. Useful for granting temporary access or enabling cross-account
access.
4. Policies: Documents defining permissions. They can be inline (directly attached
to a user, group, or role) or managed (created and managed separately).

Common Use Cases

1. Fine-Grained Access Control: Specify precise permissions to limit access to

specific resources or actions.
2. Secure Access Management: Use MFA, roles, and policies to enforce secure
access controls.
3. Temporary Access: Grant temporary access to AWS resources for applications,
services, or external users.
4. Automated Resource Management: Use IAM roles with AWS services (like EC2,
Lambda) to manage resources without embedding credentials.
5. Federated Access: Integrate with identity providers to enable single sign-on
(SSO) for AWS Management Console access or AWS API calls.

Best Practices

1. Least Privilege Principle: Grant only the permissions necessary for users to
perform their tasks.
2. Use Roles Instead of Long-Term Access Keys: Avoid embedding long-term
access keys in applications. Use IAM roles for secure and temporary access.
3. Enable MFA: Enhance security by requiring MFA for users with high-level
privileges.
4. Regularly Review Permissions: Periodically audit and adjust permissions to
ensure they are still appropriate.
5. Use Managed Policies: Prefer AWS managed policies for common permissions
and create custom managed policies for specific needs.