This document provides an overview of Identity and Access Management (IAM) in AWS. IAM allows users to be created and assigned to groups with defined permissions to access AWS resources. Key concepts covered include IAM users, groups, policies, and roles. Users can be assigned individual permissions or inherit permissions from their group membership. Policies define permissions and can be identity-based and attached to users or groups, or resource-based and attached to resources. Roles allow sharing of access across accounts or with AWS services. Best practices for security are also discussed.
2. ● Introduction to IAM
● IAM Users and Groups
● IAM Policies
● IAM Roles
● Live demonstrations
Scope of this session
3. ● A web service that helps us securely control access to AWS
resources.
● Allows to create and manage AWS users and groups, and use
permissions to allow and deny their access to AWS resources.
● Control who is authenticated (signed in) and authorized (has
permissions) to use resources
● IAM is offered at no additional charge.
4. Features of IAM
● Centralized control of AWS account
● Shared access to other AWS account
● Granular permissions
● Identity Federation
● Multi-Factor Authentication
● Temporary access for users or applications
● Password Rotation Policy
5. Users
● An entity that we create in AWS to represent the person or
application that uses it to interact with AWS.
● Users can access AWS in different ways depending on
credentials.
○ Console Password
○ Access Keys
○ SSH keys for use with CodeCommit
6. Types of Users
● Root User: Email we use when creating an AWS account
● IAM User:
○ Instead of sharing root credentials, we create individual
IAM users.
○ Each user has their own password.
○ Users can have access keys for programmatic access.
● Federated User:
○ Allow users who already have passwords elsewhere
○ Identities from Corporate Directory or OpenID providers
7. Groups
● Collection of IAM users
● Groups let us specify permissions for multiple users
● We attach permission policies to the group
● Any user in a group automatically has the permissions that are assigned to
the group
● A group can contain many users, and a user can belong to multiple groups.
● Groups cannot be nested
8. Policies
● An entity that, when attached to an identity or resource, defines their
permissions.
● Policies are stored in AWS as JSON documents that defines the
permissions for specific identity (users) or resource (S3 Bucket).
● We can attach policies in users, groups or roles.
● AWS evaluates these policies when a principal entity (user or role)
makes a request.
● IAM’s Policy Evaluation Logic denies all requests by default, so
successful actions/operations have to be explicitly allowed by the admin
within the user and resource policies.
● An explicit allow in policy overrides the default deny but cannot
overrides explicit deny.
9. Types of policies
● Identity-based policies:
○ Attached to an IAM user, group, or role.
○ Types of identity-based policies:
■ AWS Managed Policies
● Standalone policy that is created and administered by AWS.
● Designed to provide permissions for many common use cases.
■ Customer Managed Policies
● Standalone policies that we administer in our own AWS account.
● We can edit customer managed policies unlike AWS managed
policies
10. Types of policies
■ Inline Policies
● Policy that’s embedded in a particular user, group or role
● Useful to maintain a strict one-to-one relationship between policy
and a particular entity.
● If an entity(which contains an inline policy) is deleted, then inline
policy is automatically deleted.
11. Types of policies
■ Job Function Policy
● AWS managed policies
● Designed to closely align to common job functions in the IT industry
● Consolidate permissions for many services into a single policy
● Job Functions like Database Administrator, Network Administrator,
System Administrator etc.
● Resource-based Policy
○ Resource-based policies are attached to a resource.
○ We can attach resource-based policies to Amazon S3 buckets or an IAM
Role trust policy.
○ Resource based policies are inline only, not managed.
14. Elements of Policy Document
● Version:
○ Specifies the version of the policy language
○ Mostly we use latest version: 2012-10-17.
● Statement
○ Main and required element for a policy
○ A list of multiple statements that define permissions.
○ Each individual statement includes:
■ Sid: Description of the statement
■ Effect: Specifies whether the statement results in an
allow or an explicit deny
■ Principal:
● Indicate the account/user/role to which we would
like to allow or deny access.
15. Elements of Policy Document
■ NotPrincipal:
● Specify an exception to a list of principals
● Use this element to deny access to all principals
except the one named in the NotPrincipal
element
■ Action:
● Include a list of actions that the policy allows or
denies.
● Each AWS service has its own set of actions that
describe tasks that we can perform with that
service.
16. Elements of Policy Document
■ NotAction
● Explicitly matches everything except the
specified list of actions
■ Resource:
● Specify a list of resources to which the action
apply
■ NotResource:
● Explicitly matches everything except the
specified list of resources
17. Elements of Policy Document
■ Condition:
● Specify the circumstances under which the policy
grants permission
● Use condition operators (equal, less than, etc.) to
match the condition in the policy against values
in the request
● "Condition" : { "StringEquals" : { "aws:username"
: "genese" }}
18. Elements of Policy Document
■ Condition:
● Some available conditions keys
○ aws:CurrentTime
○ aws:MultiFactorAuthPresent
○ aws:SourceIp
○ aws:SourceAccount
○ aws:SourceArn
○ aws:RequestedRegion
19. Elements of Policy Document
■ Condition:
● Some Condition Operators
○ StringEquals
○ StringNotEquals
○ NumericLessThan
○ NumericLessThanEquals
○ NumericGreaterThan
○ NumericGreaterThanEquals
○ IPAddress
○ NotIpAddress
20. Roles : Terms and Concepts
● Role
○ IAM identity that has specific set of permissions.
○ Similar to users
○ Intended to be assumable by anyone who needs it.
○ When you assume a role, it provides you with temporary
security credentials for your role session.
21. Roles: Common Scenarios
● Two ways to use a role:
○ Interactively in the IAM console
○ Programmatically with the AWS CLI or AWS API.
● Common scenarios for which we will use IAM Role
○ Providing Access to an AWS Service
○ Providing Access Across AWS Accounts
○ Providing Access to Third-Party AWS Accounts
○ Providing Access Through Identity Federation
22. Role: Trust Policy
● Policy document that defines who is
allowed to assume the role.
● The trusted entity is included in the
“Principal” element of policy
document.
23. Role for AWS Services
● Allows AWS Services to perform actions on our behalf.
● Also called service roles .
● Role that a service assumes to perform action on our behalf.
24. Role for Another account
● Allows entities in other accounts to perform actions in our
account.
● With these roles, we can establish a trust relationships
between our trusting account and other AWS trusted
accounts.
● The trusting account owns the resource to be accessed and
trusted account contains the users
25. Role for Identity Providers
● Use IAM identity providers instead of creating IAM users.
● Allows users federated by specified external web identity
(such as Facebook, Google) or OpenID Connect(OIDC)
compatible IdP or SAML 2.0 based IdP to assume the role.
● Useful to create a mobile app or web application that requires
access to AWS resources.
26. Using Roles
● Granting a User Permissions to Switch Roles: assume role
● Granting Permissions to Pass a Role to a Service: pass role
● Switching Role/Assuming a role
○ Console
○ AWS CLI
○ AWS SDK
27. IAM Best Practices
● Create Individual Users, avoid using root credentials
● Grant Minimum Privileges
● Manage Permissions with Groups
● Restrict Privileged access further with conditions
● Configure a strong password policy
● Rotate Security Credentials Regularly
● Enable MFA for privileged users
● Use IAM roles to share access
