Need OF Identity Access Management/IAM?
If organization have less no of AWS account then management of those accounts is simple since it is easy to manage the logs and their workaround. Admin can easily perform changes but if organization have large no of AWS account of different departments then this task gets hectic so we need to create a admin for each and every department . So with every account we have different sets of keys. So here we have 2 approaches:
i. Simplest is to create login in each account and mange those changes but this is not an ideal approach.
ii. Creation of central entity and bind all the account with central entity. In central entity, we can implement access key and secret key. So addition or deletion of access key or user can be handled from here only. There is no need to visit each and every AWS account.
Central account is known as identity account.
What Is Identity Access Management/IAM?
IAM provides an approach to the organization where they can manage the different type of resource assigned to different type of users. IAM is very powerful service that have power to control authorization of persons and infrastructure resources.
We can access IAM policy through AWS CLI, management console and AWS SDK.
Note: IAM policy implementations is for AWS infrastructure resources and not for permissions within your application.
Before moving further there are some basic terminologies about IAM which we need to understand.
IAM entity that is allowed to interact with AWS resources. There are three types of principals:
i. Root user: Whenever we create AWS account first time, a single user with all rights and functionality get created i.e. known as “Root User”.
Note: It is always recommended not use “root user” for every task.
ii. IAM USER: Persistent entity that can be bind with IAM service to represent individual people or applications.
iii. Roles/Temporary Security Tokens: Advanced IAM usage
Roles: Grant the specific resources permission for a specific duration to specific user.
Security Token Service/STS:
AWS provide temporary security token facilities. These token are valid for specific duration after that they are needed to be regenerated.
So how AWS uses them? AWS will use all principals in accessing resources. Some major resources are:
i. Amazon EC2 roles: Admin can attach IAM role to ec2 instance. Admin can modify, replace or delete the attached roles.
ii. Cross-Account Access: By creating trust relationship, admin can give permissions to users from other AWS accounts, to use those account whether you control those accounts or not.
iii. Federation: Granting permissions to users authenticates by a trusted external system.
So we have already learnt about principle but how we can apply those principles.
i. User Name/Passwords: Human has to present credentials to verify its identity it happens when user is required to singin to his account.
ii. Access Key: Access keys known as KeyPair, it is combination of “Secret Key” and “Access key ID”. This are useful when you don’t want to authenticate yourself again and again. We can use these KeyPair just to authenticate ourselves for one time and then we can use the CLI to actually perform the actions on the AWS account.
iii. Access Key / Session Token: Whenever AWS uses “Assume Role” feature it is combination of access key ID, Access Secret Key, Session ID. After the expiration, these will be removed.
After authentication, what actions a principle can or cannot perform is called authorization. In IAM, authorization is handled by principles and associated policies (policies is nothing as JSON document as shown in above image).
i. Service: For what service does these permissions apply? Most of AWS services support granting access through IAM, including IAM itself.
ii. Condition: If admin wants to put one or more restriction while accessing the resources, we can include those here. Such as this resource must be accessed from this particular IP address.
In every IAM policy, we have four elements. We will try to understand them on the basis of this example:
It is global, and a compulsory part and other three are its sub part. In a single policy, we can declare multiple individual statement.
i. Effect: Specify whether statement is “allow” or “deny”. In our case, it is allow only. So it will provide whether to allow the user access to that resource or not. Like read write and modify.
ii. Action: Here we will define list of actions and each AWS has its own set of actions.
iii. Resource: On which Resource the policy is going to be implemented.
Defines the version of the policy. There are 2 supported version available.
i. 2012–10–17: Current version, it is recommended to always define version.
ii. 2008–10–17: Earlier version, if you do not include “Version Element”, it is set on this one by default.
Note: Some iam support only to latest iam.
IAM Policy evaluation:
· Decision starts with assumption that request will be denied.
· Then all attached policy gets evaluated.
· Searching for any explicitly deny in the policy because explicit deny has precedence over allow.
· If explicit deny is not found then it looks policy which mentions allows.
Advantage of IAM Policy:
· It is based on traditional approach. So easy to understand.
· It can be bind single users or a no of users by making a group.
· It can perform single action on a very specific resource. For it admin need the unique id of resource i.e. ARN in case of AWS.
· Policy can bind on-premises resources or cloud resources.
After getting basic information about IAM we came to know how well these IAM policy but if admin does not implement them in a proper way it will be risky also.
Example: Organization requirement is that AWS resources can be handled by only a particular IP address.
To implement this admin by mistake allowed the whole subnet. So any one from that subnet can access that AWS resource and modify can modify that as well.
So while implementing the AWS IAM policy it is very important to set policies very efficiently.