Why IAM?
IAM in AWS stands for Identity & Access Management. As it suggests, it is a Service by AWS to manage Identity and Access to Resources and Services. Now that we have understood the basic context of IAM let us talk about the Core Elements of IAM.
IAM Elements
- User – The fundamental identity in AWS is a User. You will need a user to do anything on AWS
- Group – You guessed it right, a group is a collection of one or more users.
- Role – Role is very similar to User but used by Resources on AWS to perform certain actions.
- Policy – Policy is the document that specifically tells who can perform which action on what entities.
One key thing to understand here is that a policy says what a User/Group/Role is allowed to do, so a policy should be attached to the User/Group/Role to make them useful. Without a Policy, a User/Group/Role is useless.
So, we start with Policy. Before diving into different types of Policies, let us understand the basic structure of an AWS Policy.
An AWS Policy just defines this.
- WHO
- WHAT
- WHERE
- UNDER WHICH CONDITIONS
Let’s understand Policy with this simple example
John’s mom allows John to play GTA V on XBOX only if he completes his homework in time.
- John is the User
- John’s Mom is AWS
- XBOX is the Resource
- GTA V is Action onResource
- “Completes his Homework in time” is the Condition
- “Mom allows John” is Effect
Types of Policies in AWS
Before we see an actual AWS Policy, let me define how these policies differ.
Identity-Based Policy: As the name suggests, these policies are attached to Identities (User, Group, and Role). This is sub-classified into Managed and Inline Policies.
- Managed Policies– Managed Policies are simple JSON documents which defines what can be and cannot be done to Resources by that Identity. These Policies can be used as many times as required. AWS Managed Policies are predefined by AWS and Customer Managed Policies should be defined by us.
AWS Managed Policy (Yellow Cube ones) and Customer Managed Policy (without yellow cube)
- Inline Policies – Inline policies are not predefined by anyone. These policies are directly attached to an Identity and cannot be reused. Inline Policy strictly applies to the Identity it is attached to only.
Resource Based Policies – Resource Based Policies are also Inline Policies because they are directly attached to Resources and cannot be reused in any other place. Resource Based Policies are strictly one-to-one.
Let us see some examples of different types of Policies and understand what each section does in the policy.
Sample AWS Customer Managed Policy:
This Policy is written or generated by us and named Read_Only_S3. As already mentioned, managed policies can be attached to many Identities. So, I can attach this Policy to a User/Group/Role if this policy is attached to a User.
That User can Read Objects from my-example-bucket001 if his Source IP is from 10.0.0.0/24 Subnet.
- AWS Managed PolicyInline Policy, and Resource-Based Policy (for example, S3 Bucket Policy) will look similar as the Policy structure remains the same.
- AWS Managed Policyis already created by AWS and is readily available to be attached to an Identity.
- Customer Managed Policyshould be created by us for a specific use and should be attached to the appropriate Identities.
- Resource Based Policyis written whenever needed and attached only to that Resource. For example, an S3 bucket makes sure access to the bucket is controlled.
- Inline Policyis also written in Real-time as needed and attached only to that specific identity.
If all this explanation is put in an image, it looks somewhat like this.
Accessing AWS
A user can access AWS in two ways
- Management Console – web-based access using provided credentials.
- AWS CLI – command-line based access using Access keys.
Access keys are different from Web Credentials. The User can create access keys under the Security Credentials section in IAM. A unique Access Key and Secret Key will be created, which can be used to access AWS resources. The Access Key created for a user will have the same permissions.
Roles can be attached to the Resources when a Resource in AWS needs to access other resources/services without user intervention. For example, an EC2 with an S3ReadAccess Role can access S3 and read its contents without any User Intervention.
Key Things to remember about IAM in AWS:
- IAM is global. It is not region specific.
- IAM is free of cost.
- IAM Policies can be super granular.
- IAM supports MFA (Multi-Factor Authentication)
- All IAM API calls via console/CLI are logged and can be managed in Cloud Trial.
Takeaways:
As always said, this whole theory is only to open a doorway for you to go and experiment with AWS Cloud. You will start seeing things unfold once you start writing policies and experimenting with them. Of course, if you don’t want to get your hands dirty by writing JSON documents, you can always use this free Policy Generator tool from AWS – https://awspolicygen.s3.amazonaws.com/policygen.html. We have to input a few parameters like the User to which this Policy is being attached, what actions he’s allowed to perform, and on which resources.
Testleaf’s AWS certification training online in Chennai has had a lot of success, with a high success rate. This is great news for anyone looking to get into this field.
Author’s Bio:
As CEO of TestLeaf, I’m dedicated to transforming software testing by empowering individuals with real-world skills and advanced technology. With 24+ years in software engineering, I lead our mission to shape local talent into global software professionals. Join us in redefining the future of test engineering and making a lasting impact in the tech world.
Babu Manickam
