AWS IAM for Beginners: Master the Core Concepts in 10 Minutes (1/2) - Exploring IAM Components: Users, Groups, Roles, and Policies
Written by Hyojung Yoon
Hello everyone! It's been a while since I've written an AWS blog.
For those new to AWS, IAM might seem a bit complex at first. I remember it took me quite some time to fully grasp IAM myself.
However, IAM is a crucial service that forms the foundation of security and access control in the AWS environment. It's an essential service that you must understand to effectively manage your AWS resources.
In this blog post, I'll explain the basic concepts and importance of IAM in an easy-to-understand manner.
Context
IAM User Management
IAM Policies Deep Dive
Leveraging IAM Roles
What is AWS IAM?
AWS IAM (Identity and Access Management) is a service that allows you to securely control access to AWS services and resources. Simply put, it acts as the gatekeeper of your AWS environment, managing who can do what. With IAM, you can create and manage users, groups, and roles, and finely control access permissions to AWS resources.
Using IAM allows you to:
Prevent security incidents by granting only the minimum necessary permissions.
Easily create and manage access control policies for various scenarios.
Optimize costs by restricting unnecessary resource usage.
Simplify compliance with corporate security policies and regulatory requirements.
Key Features of IAM
Shared access to your AWS account: Grant others permission to manage AWS resources without sharing your credentials.
Granular permissions: Give different people different levels of access to specific resources.
Multi-factor authentication (MFA): Add an extra layer of security to prevent unauthorized access.
Identity Federation: Provide temporary access to AWS resources for users who already have passwords elsewhere, such as in your corporate network or with an internet identity provider.
IAM Components
IAM consists of four main components: Users, Groups, Roles, and Policies. Policies define detailed permission settings, which are then attached to role, users, or groups. These roles are in turn linked to users or AWS resources to set their permissions.
1. Users
IAM users represent individuals or services that use AWS. After creating an IAM user, you can generate the following credentials:
A password for logging into the management console
Access credentials (access key ID and secret access key)
These credentials are different from root user security credentials and are defined for only one AWS account.
2. Groups
Groups are collections of users with the same permissions.
For example, you can create groups like 'Development Team' or 'Operations Team'.
Groups are useful when you need to assign common permissions to multiple users, simplifying the process of managing permissions for several users.
Note that IAM groups, unlike IAM users or roles, don't have their own credentials.
3. Policies
Policies are JSON documents that define permissions in AWS. They specify rules to allow or deny access to specific resources. These policies are attached to IAM users, groups, and roles. The main elements of a policy are 'Effect', 'Action', and 'Resource'.
The basic JSON policy structure is as follows:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}Effect
Can be either "Allow" or "Deny".
It determines whether the statement allows or denies specific actions.
Action
Defines the actions that can be performed. For example: "s3:GetObject"
You can specify multiple actions using wildcards
Resource
Specifies the AWS resources to which the actions apply.
It uses Amazon Resource Names (ARNs) to identify resources.
You can specify multiple actions at once using wildcards.
* A Quick Note on Permissions:
4. Roles
IAM roles are a feature that allows you to grant temporary permissions to users or services. IAM roles enable flexible management of permissions needed for specific tasks. Roles use temporary credentials to grant permissions, which is more secure as it doesn't require long-term credentials like access keys.
IAM User Management
IAM users represent entities that interact with AWS, which could be actual people or applications and services. Each user has unique credentials for accessing AWS resources.
1. Things to consider when creating an IAM user
Access Type: AWS Management Console access, programmatic access, or both
Permission Scope: Minimum necessary permissions for the user's tasks
Group Membership: Manage users with similar roles in groups
Password Policy: Apply policies that enforce strong password usage
2. Access keys and Secret access keys
These are credentials that allow users to access AWS programmatically. They must be stored securely and immediately changed or deactivated if compromised.
3. How to set user permissions
1) Direct Policy Attachment vs. Group Policy Attachment
Direct Policy Attachment: Used when individual users need specific permissions.
Group Policy Attachment: Applies permissions to multiple users with similar roles simultaneously.
2) Principle of least privilege
This principle involves granting users only the minimum permissions necessary for their tasks, preventing security incidents caused by unnecessary permission grants.
IAM Policies Deep Dive
1. Policy Types
AWS managed policies: Pre-defined policies provided by AWS for common use cases.
Customer managed policies: Policies created and managed by users for specific requirements.
Inline policies: Policies directly included in a specific user, group, or role.
2. Policy writing considerations
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
"Condition": {
"IpAddress": {
"aws:SourceIp": "192.0.2.0/24"}}
}
]
}1) Policy Components
Version: Specifies the policy document version. It's recommended to use the latest version '2012-10-17'.
Statement: This is the container that holds the main elements of a policy document. It can include one or more statements.
Effect: This defines the result of the policy. It can have two values: 'Allow' or 'Deny'. In our example, we're allowing access ('Allow').
Action: This specifies what actions the policy allows or denies. For instance, in our example, we're allowing the S3 object retrieval action ('s3:GetObject').
Resource: This identifies the AWS resources to which the policy applies. In our example, we're targeting all objects ('*') in the 'example-bucket'.
Condition: This defines the conditions under which the policy applies. Our example uses the 'aws:SourceIP' condition to allow access only from a specific IP address range, '192.0.2.0/24'.
2) Policy Writing Considerations
Adhere to the Principle of Least Privilege: Enhance security by granting only the minimum necessary permissions.
Use wildcards(*) cautiously: Use carefully to prevent granting excessive permissions.
Implement explicit denials when necessary(Deny): Takes precedence over Allow, and should be set explicitly when needed.
Utilizing IAM Roles
1. Concept and Use Cases of IAM Roles
IAM roles are tools for setting specific permissions for IAM users. They are used for authentication and granting temporary access rights to specific AWS resources within an AWS account. For example, you can set up a role to allow an EC2 instance to access an S3 bucket.
Both roles and users are AWS credentials that determine what actions can and cannot be performed in AWS according to permission policies. However, roles are not associated with a specific individual and can be assumed by anyone who needs that role. Also, roles don't have standard long-term credentials like passwords or access keys; instead, they provide temporary security credentials.
IAM role use cases:
EC2 instance accessing S3 bucket: You can grant an IAM role to an EC2 instance to allow it to access an S3 bucket. This allows applications running on the EC2 instance to securely access the S3 bucket.
Cross-account access management: You can securely share resources across multiple AWS accounts. For example, you can use roles to safely allow users in a development account to access resources in a production account.
Using AWS services: Lambda functions or other AWS services can use roles to access other AWS resources.
Providing temporary credentials: You can set up temporary credentials for specific tasks. This enhances security and reduces the risk of long-term credential exposure.
2. Cross-Account Access Management
You can use IAM roles to securely share resources across multiple AWS accounts. For example, you can use roles to safely allow users in a development account to access resources in a production account.
3. Comparing IAM Roles and Policies
IAM Role | IAM Policy | |
Target | All specified targets | One IAM user, separated by account |
Credential Type | Temporary authorization method | Long-term or permanent authorization method |
Permission Acquisition Method | Access allowed only during specified time | Access allowed as long as policy is attached |
Use Cases | EC2 instances, Lambda functions, temporary permission management | Used for specific resources with detailed access control |
Components | Trusted entity, permission policy | Effect, Action, Resource, Condition |
Main Purpose | Enhancing security and flexible permission management | Detailed access control |
Conclusion
Through this AWS IAM guide, we've explored the core of IAM. By understanding and applying each component of IAM - users, groups, roles, and policies - in real-world environments, you can manage your AWS environment more securely and efficiently.
I hope this guide serves as a solid first step in strengthening your AWS security. In the upcoming practical IAM guide, we'll cover IAM setup and hands-on exercises focusing on real-world cases, so stay tuned!
Comments