IAM or Identity and Access Management is the AWS global system for managing users and user group accounts.
It’s a way of managing permissions granted to users for accessing your cloud resources.
These permissions are assigned to entities. Entities are things to which you can assign permissions.
IAM is free to use. There is no additional charge for IAM security. There is no additional charge for creating additional IAM users, groups or policies.
Overview of IAM
There are 3 possible entities in IAM:
Users
Groups
Roles
A user is a person or service on AWS.
A group is a collection of IAM users.
A role is similar to a user, namely an identity with permission policies to determine what the identity is permitted to do in AWS.
However, a role doesn’t have any password or access keys unlike a user. It isn’t associated with one specific person, rather a role can be temporarily granted to any user who needs it.
You assign permissions to entities through directives known as policies.
Policies come in two basic types:
Managed policies
Inline policies – (which can be regarded as unmanaged policies)
Managed policies are stand alone policies, not associated with any specific entity, and they then can be attached to multiple entities.
Inline policies (or unmanaged policies) on the other hand are policies associated with a single IAM identity (a user, group, or role). They are policies that you create that are embedded directly into a single entity (user, group or role). The inline policy is an inherent part of the identity and cannot be assigned to any other entities. 1n other words, they are a specific attribute of an entity.
Managed policies are usually recommended in preference to Inline policies as they are easier to manage. They enable you to have eg several hundred users all with the same managed policy. This means that you can make just one change in the policy and the change transmits to all those users simultaneously.
Whereas if you were to have an inline policy defined for each user, then you would have to modify several hundred different policies individually, which is clearly an unrealistic overhead.
Managed Policies are recommended over Inline Policy as managed policies are reusable. Managed policies can also be implemented as versions.
Deletion of the entity or resource also results in the deletion of inline policy.
Remember that all policy permissions are implicitly denied by default. The most restrictive policy is applied.
There is another important distinction regarding IAM managed policies.
Managed policies can be divided into two types:
Managed policies (you can think of these as AWS Managed policies)
Customer Managed policies (set and managed by yourself the customer)
Managed policies are defined and managed by AWS. They are standard policies created by AWS to best suit the majority of use cases for AWS customers and you cannot modify these, they are set by AWS.
Customer Managed policies by contrast are IAM policies created and managed by AWS customers. You can define your own customer managed policies according to your own specific requirements. In this way you can create a policy and embed it in identity, this can be when you create the identity or later on. There is a strict one-on-one relationship between the entity and the policy.
Identity-based policies and Resource-based policies – what’s the difference?
Identities are things or “entities” to which you can assign Identity-based policies. These are assigned to Users, Groups and Roles.
But there is also another type of policy known as resource-based policy. As the name suggests, these can only be assigned to resources, in other words, things like services (EC2 instances, S3 buckets, SQS message queues, etc). This enables you to assign permissions to resources that need specific access rights to perform a task.
Note that you can grant permissions to resources in two ways. Firstly by granting permissions through resource-based policies (known as “directly attached”) as well as through granting identity-based policies through roles. This is because roles can be assigned to anyone or anything which requires access to carry out a task.This also includes EC2 instances and AWS services.
A managed policy however is a standalone policy that can be attached to multiple entities. Managed policies apply only to entities and not to resources. They have their own ARN (Amazon Resource Number).
So, to summarize the basics of IAM:
User: an account having associated credentials and attached permissions.
Group: a collection of IAM users.
Policy : a definition of AWS resource rights to control access. Determines who can access it, user actions, user access to which AWS resource.
Role: a set of permissions specifying an entity’s actions (allow or deny).
IAM Users go in groups, no groups in groups are permitted, ie groups only contain users.
Users can belong to multiple groups (or even no groups at all – but this is not best practice).
NOTE:
Instead of accessing and using AWS with your root account, you should set up a separate admin group with the awsadmin policy included, and put a separate newly created admin user in this group to be your admin. And from then on only usually login to AWS using this account, not your AWS root account.
You can assign an AWS-managed policy, a customer-managed policy, or an inline policy.
IAM users and groups are assigned permissions for resources and actions via JSON document declarations called “policies”. Policies are inherited from groups.
IAM Users
An IAM user is an entity that represents a person or service within your AWS account.
An IAM user can be assigned in two ways:
1. via an access key ID and secret access key for access to the AWS API, CLI, SDK, and other development tools.
2. via a password for access to the management console.
You can have a maximum of 5000 IAM users per AWS account.
Each user account has a human-readable name plus an ARN (Amazon Resource Name) which uniquely identifies the user within AWS.
A unique ID is also created which is returned only when you create the user by using the API, Tools for Windows PowerShell or the AWS CLI.
You can define a password policy to enforce password length, password complexity etc which will apply to all users.
You can allow or disallow the ability to change passwords using an IAM policy.
AWS Root User
Your AWS account root user credentials are the email address used to create the account together with a root password.
Note that the root account has full administrative rights in your account and these cannot be restricted!
Therefore, the best practice for root accounts is:
As a general rule avoid using the root user credentials.
Do not ever share the root user credentials.
Instead, create an IAM admin user and assign administrative permissions to this user as required.
Also – Enable MFA!
As a general rule it is advisable to only use the root account for billing tasks and nothing else.
IAM Groups
IAM Groups are collections of users who have IAM policies attached to them.
A group is not an identity and cannot be identified as a principal in an IAM policy.
You should use groups to assign permissions to users.
Always use the principle of least privilege when assigning permissions. Note that you cannot nest groups (groups within groups).
Best practice for using a group is to assign assign privileges to the group and then add your organization users to the relevant group.
Features Of IAM Policy
Free Service: IAM is a free service with no costs for creating accounts, groups, or policies.
Password Policy: IAM authentication policy which allows for such actions are password reset or rotation.
Granular Permissions: allows for more tightly defined permissions and access for users.
Multi-Factor Authentication: supports MFA, device authentication together with username and password.
Shared Access: permits creation of multiple usernames and passwords.
Identity Federation: allows access to users who have already authenticated via trusted third-parties such as Google or Facebook.
PCI DSS Compliance: Payment Card Industry Data Security Standard for secure implementation of payment gateways. IAM is PCI-DSS compliant.
Three Ways To Attach Policies To A User
- attach to groups and then place the user in the group
- attach directly to the user
- via inline policies
IAM Policy document structure – JSON Format
Version policy language version
Id: an optional text tag identifier
then the Statement section, which consists of
Sid: optional statement identifier
Effect: whether statement is Allow or Deny for access level
Principal: the account, user or role to which this policy applies
Action: list of actions this policy allows or denies
Resource: list of resources to which the actions apply
you can also have
Condition: this defines when the policy is in effect, but this is optional
IAM Password Policy
Password Policy and MFA Multi-Factor Authentication is essential for AWS – set this in IAM for root account and all IAM-users.
MFA
Virtual MFA-Device eg Google Authenticator or Authy
Authy allows multiple device use.
Universal Second Factor Security Key (U2F)
These are third-party hardware devices, not provided by AWS, eg YubiKey
Other options:
Hardware Key Fob MFA Devices eg Gemalto
IAM Roles
An IAM role is a temporary identity which a user or service that requires access to your account resources can request.
For example, IAM users need to be able to reboot EC2 instances after an update.
To avoid accidental shutdowns, you only want to give them temporary permission to do this. It is a similar power to assigning a specific sudo command only for as long as required.
Or you might want to temporarily give IAM users from another AWS account – or users signing in from a federated authentication service access to resources on this account. An IAM role (which by default expires after 12 hours) can often be the best way to do this.
You create a new role by defining the trusted entity you want given access.
There are four categories of trusted entity:
an AWS service
another AWS account (identified by its account ID)
a web identity authenticated using a login with Amazon, Amazon Cognito, Facebook, or Google
Security Assertion Markup Language (SAML) 2.0 federation with a SAML provider you define separately.
Once your trusted entity is defined, you assign it permissions by creating and attaching your own policy document or assigning one or more preset IAM policies. AWS then issues it a time-limited security token using the AWS Security Token Service (STS).
Mostly you’ll want to create a role of type AWS Service – and this will be either for an EC2-Instance or a Lambda function. But roles can also be created for many different services in AWS.
IAM Key Details
IAM is a global AWS service 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 Credentials Report
reports at account-level, lists all your account’s users and the state of their credentials
generated in csv-format to import into a spreadsheet.
IAM Access Advisor
reports at user-level and shows service permissions granted to a user and when service was last accessed.
you need to select a specific user and then click on Access Advisor
IAM Roles and Policies
you can attach IAM policies to an IAM role
most of these are preset policies,
but you can also create your own IAM policies
you can also add “inline” policies, these are added on top just for a specific role – not usually recommended, it is better to stick to global policies.
you can click on policy summary or JSON document in the IAM dashboard to display the policy statement permissions
note Resource “*” means everything!
and /* means all items in the bucket,
whereas / just refers to the bucket itself, not the objects within it!
IAM Trust Relationships
When IAM roles are created, they also have a feature called trust relationships.
A trust relation specifies who can assume that role by using a directive called the assume role policy.
An assume role policy in a JSON policy file looks something like this:
“AssumeRolePolicyDocument”: {
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “ec2.amazonaws.com”
},
“Action”: “sts:AssumeRole”
}
]
}
You can manually query the assume role policy associated with a specific role by using the CLI command:
aws –profile “test” iam get-role –role-name “test-role”
IAM Policy Simulator
IAM Policy Simulator is an online tool accessible via web, to test and assess your policies
EC2 Instance Metadata
is a powerful tool for developers
allows EC2 instances to “learn about themselves” without having to have an iam role.
url: http://169.254.169.254/latest/meta-data/
this is an internal aws ip -it only works from within your ec2 instances – it is NOT a public ip!
you can retrieve the iam role name from the metadata – but not the iam policy itself
metadata = info about the ec2 instance
userdata = the launch script for the ec2 instance
how to use:
from the ec2 instance shell cli:
curl http://169.254.169.254/latest/
always add the last slash!
you get
dynamic
meta-data
you can then retrieve from here –
eg
meta-data:
http://169.254.169.254/latest/meta-data/
this returns a list of items
you can then examine the values of these items in the list
we havent used an iam role for this, any ec2 can access this via this url!
the items with / at the end are directories with more items within them.
you can then curl these items in turn as well
this gives you info about your ec2 instance config
AWS SDK
this enables your apps to perform aws actions directly without having to go through the cli…
there are sdks for many languages
– the aws cli actually runs using python sdk called boto3.
exam question; when to use an sdk!
if you don’t specify a default region then us-east-1 will be used for your sdk – know this for the exam!
Example Exam Questions about IAM
An application hosted on an EC2 instance wants to upload objects to an S3 bucket using the PutObject API call, but it lacks the required permissions. What should you do?
answer:
ask an admin to attach an IAM policy to the IAM role on your ec2 instance, to authorize it to carry out the necessary API call.
yes, correct: IAM Roles are the right way to provide credentials and permissions to an EC2 instance.
You and your colleague are working on an application that’s interacting with some AWS services through making API calls. Your colleague can run the application on his machine without issues, while you get API Authorization Exceptions. What should you do?
answer:
compare both your IAM policy and his IAM policy using the AWS policy simulator to locate the differences and find out what exactly is preventing you from authorizing
correct.
Your administrator launched a Linux EC2 instance and gives you the EC2 Key Pair so you can SSH into it. After getting into the EC2 instance, you want to get the EC2 instance ID. What is the best way to do this?
answer:
query the metadata using
curl http://169.254.169.254/latest/meta-data/
External Users of AWS
From the point of view of authentication with AWS, these come from three main sources:
1. Federated-users (usually Active Directory defined users)
these are created using SAML 2.0.4
They are granted temporary access based on the user’s Active Directory credentials and so do not need to be IAM users.
The Single sign-on allows users to log in to the AWS console without being assigned IAM credentials.
2. Federation with Mobile Apps
These federated-users use Facebook/Amazon/Google or other OpenID providers for login.
3. Cross Account Access
Cross-account access allows users from one AWS account to access resources in another AWS account.
To make a request to access a different account the resource in that account must have an attached resource-based policy that already has the permissions you require.
Alternatively, you must assume an IAM role (identity-based policy) within that account with the permissions you require.
IAM Best Practices
The following is a list of the main IAM best practices. These are important to know for the examination!
Lock away the AWS root user access keys.
Create individual IAM users.
Use AWS-defined policies to assign permissions whenever possible.
Use groups to assign permissions to IAM users.
Grant least privilege.
Use access levels to review IAM permissions.
Configure a strong password policy for users.
Enable MFA.
Use roles for applications that run on AWS EC2 instances.
Delegate by using roles instead of sharing credentials.
Rotate credentials regularly.
Remove unnecessary credentials.
Use policy conditions for extra security.
Monitor activity in your AWS account.
IAM Roles vs Resource Based Policies
Cross account
you attach a resource-based policy to a resource eg S3 bucket policy
Or use the role as a proxy
ALWAYS remember:
when you assume a role – user, app or service, you give up your original permissions and take over the permissions assigned to that role
BUT – when you use a resource-based policy, you dont have to give up your own permissions to use the policy.
more and more aws services and resources support resource-based policies, better to use these when you can
esp for EventBridge you use resource based rules
Remember the rule:
Resource-based are: Lambda, SNS, SQS, Cloudwatch logs, api gaeway
IAM role based are: Kinesis stream, systems manager run command, ecs task
IAM Permission Boundaries
are supported for users and roles BUT NOT FOR GROUPS
they allow you to use a managed policy to set the max permissions an IAM entity can get – a way of limiting what permissions can be granted