When we talk about security, AWS IAM is one of the most fundamental & critical AWS service which needs suitable observation to design it because any careless & negligible exercise leads to huge complication & misshaping. AWS IAM is one of a kind which is ignored at the starting means not organise properly which leads to enormous complications while managing access to resources. Most of the time, a proper technique of managing AWS IAM access is ignored or doesn’t documented or configured properly due to which team has to change the IAM management format every time when there is a new requirement or modification.
We cannot say that we can build an access management approach which doesn’t need any changes because it’s impossible to build an approach that doesn’t need any modification and provides full functionality for infrastructure environments. We cannot create fully functional approach but we can follow some practices which helps team to managing things in a proper manner.
Context
So in this blog series, we will talk about IAM options and their use-cases , we will also talk about best practices while configuring IAM & how to manage IAM access using Terraform. For this, we are creating blog series which will cover following topics:
- AWS IAM: The challenge
- AWS IAM: Best practices Part X
- AWS IAM: Manage using Terraform
What options we have
Before diving into the IAM approaches, we will consider some options like policy, user, group & roles that AWS IAM have and we will also talk some basics and importance of these AWS IAM options. So, AWS IAM itself a term which consist of powerful options like policy, roles, group, users and etc. We will cover and talk about these options that AWS IAM have.
- Policies
As per AWS official documentation, A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied.
In simple words, policy is backbone of AWS identity access management which actually does all the logic like allow/deny on the basis of rules we defined in IAM policy.
All the rules will create using IAM policy object and most policies are stored in AWS as JSON documents. AWS also provided multiple ways to create and validate IAM polices like AWS Policy Generator & IAM Access Analyzer. IAM access analyzer is very powerful which not only validate but also provides multiple features like unintended access to AWS resources, Policy elements that don’t conform to AWS best practices also maintained by IAM access analyzer.
- Users
IAM user is an object that we create in AWS which is provided to user or application. The main function of IAM user is to provide access to resources on the basis of policy that attached to IAM user. There are two types of request that IAM user can configure, first is AWS management console access & other is programmatic access using credentials.
- Roles
An IAM role is an identity with permission policies that determine what the user can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. It is very similar to user because it uses request to provide access to AWS resources.
There are multiple situation where IAM roles can be used:
- grant the users to access the AWS resources in AWS account
- Grant AWS resources access to another AWS resources
- A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM
- Roles also used in AWS Security Token Service API
- Group
An IAM group is a collection of IAM users. You can use groups to specify permissions for a collection of users, which can make those permission easier to manage for those users.
An IAM group hold IAM policies which is used by similar kind of users or users who wants to use policy specified in IAM group.
Conclusion
We learnt about different options of AWS IAM which is actually not scope of this blog series but it’s important to know about these options before diving into the main segment and these blog series not only for folks who already have depth or intermediate knowledge of AWS IAM but also for folks who understand & have basic understanding about AWS IAM.
This blog series will mainly focus on the approaches & practices which can help in planning a structure or format for AWS IAM management. These approaches are not mandatory but according to use-case, anyone can follow any practices which can help them setting up AWS IAM in a proper way. Please let us know if you have any suggestions & approach related to this blog or IAM.
Stay tuned for upcoming AWS IAM blogs. Keep learning
Blog Pundit: Kapendra Singh & Sanjeev Pandey
Opstree is an End to End DevOps solution provider
3 thoughts on “AWS IAM: The challenge”