Identity and Access Management (IAM) manages Amazon Web Services (AWS) users and their access to AWS accounts and services. It controls the level of access a user can have over an AWS account & set users, grant permission, and allows a user to use different features of an AWS account. Identity and access management is mainly used to manage users, groups, roles, and Access policies The account we created to sign in to Amazon web services is known as the root account and it holds all the administrative rights and has access to all parts of the account. The new user created an AWS account, by default they have no access to any services in the account & it is done with the help of IAM that the root account holder can implement access policies and grant permission to the user to access certain services.
How IAM Works?
IAM verifies that a user or service has the necessary authorization to access a particular service in the AWS cloud. We can also use IAM to grant the right level of access to specific users, groups, or services. For example, we can use IAM to enable an EC2 instance to access S3 buckets by requesting fine-grained permissions.
IAM Identities assists us in controlling which users can access which services and resources in the AWS Console and also we can assign policies to the users, groups, and roles. The IAM Identities can be created by using the Root user
IAM Identities Classified As
The root user will automatically be created and granted unrestricted rights. We can create an admin user with fewer powers to control the entire Amazon account.
We can utilize IAM users to access the AWS Console and their administrative permissions differ from those of the Root user and if we can keep track of their login information.
With the aid of IAM users, we can accomplish our goal of giving a specific person access to every service available in the Amazon dashboard with only a limited set of permissions, such as read-only access. Let’s say user-1 is a user that I want to have read-only access to the EC2 instance and no additional permissions, such as create, delete, or update. By creating an IAM user and attaching user-1 to that IAM user, we may allow the user access to the EC2 instance with the required permissions.
A group is a collection of users, and a single person can be a member of several groups. With the aid of groups, we can manage permissions for many users quickly and efficiently.
Consider two users named user-1 and user-2. If we want to grant user-1 specific permissions, such as the ability to delete, create, and update the auto-calling group only, and if we want to grant user-2 all the necessary permissions to maintain the auto-scaling group as well as the ability to maintain EC2, we can create groups and add this user to them. If a new user is added, we can add that user to the required group with the necessary permissions.
While policies cannot be directly given to any of the services accessible through the Amazon dashboard, IAM roles are similar to IAM users in that they may be assumed by anybody who requires them. By using roles, we can provide AWS Services access rights to other AWS Services.
Consider Amazon EKS. In order to maintain an autoscaling group, AWS eks needs access to EC2 instances. Since we can’t attach policies directly to the eks in this situation, we must build a role and then attach the necessary policies to that specific role and attach that particular role to EKS.
IAM Policies can manage access for AWS by attaching them to the IAM Identities or resources IAM policies defines permissions of AWS identities and AWS resources when a user or any resource makes a request to AWS will validate these policies and confirms whether the request to be allowed or to be denied. AWS policies are stored in the form of Jason format the number of policies to be attached to particular IAM identities depends upon no.of permissions required for one IAM identity. IAM identity can have multiple policies attached to them.
Shared Access to your Account: A team working on a project can easily share resources with the help of the shared access feature.
Free of cost: IAM feature of the Aws account is free to use & charges are added only when you access other Amazon web services using IAM users.
Have Centralized control over your Aws account: Any new creation of users, groups, or any form of cancellation that takes place in the Aws account is controlled by you, and you have control over what & how data can be accessed by the user.
Grant permission to the user: As the root account holds administrative rights, the user will be granted permission to access certain services by IAM.
Multifactor Authentication: Additional layer of security is implemented on your account by a third party, a six-digit number that you have to put along with your password when you log into your accounts.
Whether you're preparing for your first job interview or aiming to upskill in this ever-evolving tech landscape, GeeksforGeeks Courses are your key to success. We provide top-quality content at affordable prices, all geared towards accelerating your growth in a time-bound manner. Join the millions we've already empowered, and we're here to do the same for you. Don't miss
Real Time Scenario example
IAM Role Analogy:
Real-Life Scenario: Job Function
- Think of an IAM role as a specific job function or role within an organization.
- This job function may come with certain responsibilities and permissions . Example:
Imagine an employee named Alex who works as a project manager. The project manager role has specific responsibilities, such as creating project plans, assigning tasks, and reviewing progress.
In AWS, an IAM role could be analogous to the project manager role. It defines a set of permissions and responsibilities that can be assumed by different entities (users or services) as needed.
IAM roles are not tied to specific individuals but rather define a set of permissions for a particular function or task.
Different people (or services) can assume the same role at different times.
IAM Policy Analogy:
Real-Life Scenario: Company Policy
IAM policies are like company policies or rules that govern what individuals or roles are allowed to do.
- In our organization, there is a company policy that outlines who can access certain sensitive information. The policy might state that only managers and executives have permission to access financial reports.
In AWS, an IAM policy would be similar. It explicitly defines the actions (permissions) that are allowed or denied on AWS resources
IAM policies are attached to IAM roles, users, or groups and dictate what actions are permitted or denied.
Policies are specific sets of rules that control access to resources
Bringing It Together:
In our analogy, the IAM role is like a job function (project manager), and the IAM policy is like the company policy that outlines what actions can be performed within that job function.
Different job functions (IAM roles) may have different policies attached to them. For example, a developer role may have a policy allowing access to create and modify code repositories, while a finance role may have a policy allowing access to financial data.
Roles provide a way to group and define permissions for a particular function, while policies specify the rules and permissions associated with that function
In AWS (Amazon Web Services), IAM (Identity and Access Management) roles are a way to grant permissions to entities so that they can access AWS resources. IAM roles are not associated with a specific user or group; instead, they can be assumed by AWS services, users, or resources within or outside of your AWS account. IAM roles are widely used for various purposes, including granting temporary permissions and enabling cross-account access. Here are some common use cases for IAM roles in AWS:
IAM roles are often used to grant permissions across AWS accounts. For example, you might have one AWS account with resources and another account that needs to access those resources. By creating an IAM role in the first account and allowing the second account to assume that role, you enable cross-account access.
IAM roles can be used for federated access, allowing users from external identity providers (such as Active Directory) to assume roles in AWS. This is achieved through identity federation and the use of temporary security credentials.
AWS Service Permissions:
Many AWS services use IAM roles to obtain temporary security credentials and access resources on behalf of the service. For example, EC2 instances can assume roles to access S3 buckets, and Lambda functions can assume roles to interact with other AWS services.
IAM roles can provide temporary permissions. Users or services can assume a role and obtain temporary security credentials with a limited lifespan. This is useful for scenarios where you want to grant permissions for a specific task and have those permissions automatically expire.
Access from Amazon EC2 Instances:
IAM roles are commonly used with Amazon EC2 instances. Instead of storing access keys on the instances, you can associate an IAM role with an EC2 instance. The instance can then automatically assume the role and obtain temporary credentials for accessing AWS resources.
AWS Lambda Function Execution:
Lambda functions can assume IAM roles to execute actions on other AWS services. This allows you to control what resources the Lambda function can access and what actions it can perform during its execution.
IAM roles are created and managed in the AWS Management Console, AWS CLI, or using SDKs/APIs. When defining a role, you attach policies to it to specify the permissions it should have. The policies associated with a role determine what actions can be performed and on which resources. Roles provide a flexible and secure way to manage access control in AWS.
In AWS Identity and Access Management (IAM), roles and policies are two key concepts used to control access to AWS resources. Let's explore the differences between IAM roles and IAM policies, along with examples for better understanding:
An IAM role is a set of permissions that define what actions a user, service, or resource can perform.
Roles are not associated with a specific user or group. Instead, they are assumed by entities like AWS services, EC2 instances, or users within or outside of your AWS account.
- Assigning temporary permissions to AWS services.
- Allowing cross-account access.
- Granting permissions to EC2 instances . Example:
Assume you have an EC2 instance that needs to access an S3 bucket. Instead of storing access keys on the instance, you can create an IAM role with the necessary S3 permissions and attach it to the EC2 instance. The instance then assumes the role and gets temporary credentials to access S3.
An IAM policy is a JSON document that explicitly defines permissions. It specifies what actions are allowed or denied on what resources for which entities.
Policies can be attached to IAM users, groups, or roles.
- Defining fine-grained permissions for users or groups.
- Specifying permissions for AWS resources.
- Controlling access to specific API actions . Example:
Consider an IAM policy that grants read-only access to an S3 bucket. The policy might look like this:
This policy allows the s3:GetObject action on objects within the "example-bucket."
Roles can have Policies:
When you create an IAM role, you can attach policies to it. These policies define what the role can and cannot do.
Users/Groups can have Policies:
Similarly, IAM users or groups can have policies attached to them to define their permissions.
In summary, IAM roles are often used for temporary access, cross-account access, and AWS service permissions. IAM policies, on the other hand, are used to define fine-grained permissions for users, groups, or roles. They work together to provide a flexible and granular access control mechanism in AWS.