Saturday, 5 January 2019

AWS IAM: Identity and Access Management in AWS

Identity and Access Management is a very useful service offering from AWS. IAM is used to authenticate and authorize the users and AWS services to use AWS resources. Below are the basic points to not about AWS IAM:

1. Authentication and Authorization: Control access to AWS resources for your users. For example, developer should only be able to access compute and storage resources, DBA should only be able to access database resources etc.

2. Components: Users, Groups, Policies, Roles

3. Root User/Account: User/Account with which you have created your AWS account. It has all the access. It is advisable not to use root account. Instead, create an Admin account and provide all the access. Keep it for emergency purpose. 

4. User Access Type: You can provide two types of access to user: Programmatic Access (Access Key ID and Secret Access Key), Console Access (Password).

5. Access Key ID and Secret Access Key: You have to note down the Secret Access Key, once lost, you need to regenerate it.

6. User Login URL: https://your_account_name.signin.aws.amazon.com/console

7. Groups and Policies: Instead of assigning policies to individual users, it is recommended to create a group and assign the policies to that group. Now keep adding/removing users to that group. For example, if you want to create 5 developer accounts and want to assign same policies to them, instead of assigning those policies to individual accounts 5 times, better create a group say “Developer_Group”, assign those policies to this group and add all those 5 users to this group. Later, you can add/remove users to/from this group.

8. Roles: Set of permissions. Assigned to AWS services. For example: Create a role of type “Amazon EC2”, assign permission “AmazonS3FullAccess”. Now assign this role to any EC2 instance (Actions -> Instance Settings -> Attach/Replace IAM Role). Now any application deployed on this EC2 instance will be able to communicate with S3. 

Example: Suppose you have created a web application which uploads a file to S3. If you run this web application on the EC2 instance which has above role assigned, your file will be uploaded to S3 successfully. But if you run the same web application to any other EC2 instance which does not have above roles assigned to it, you will get access denied error. 

Now there are two ways to run this web application successfully on this server. Either assign the above role to this EC2 instance or mention Access Key ID and Secret Access Key (of the user who has S3 access) in your web application code.

9. User vs Role: User and Roles are similar components. We need to attach permission to them. “User” is created for people while “Role” is created for AWS resources.

10. Policies: Policies are permissions. You can also create your own policies using “Policy Generator” or using JSON code. If you assign both “Allow” and “Deny” policy to a user, “Deny” will be given priority. 

11. MFA (Multi Factor Authentication): Multi-layer of security. Just like OTP. You need to manage a Virtual MFA Device. To do this, click on to activate a virtual MFA device, a bar code will be displayed, download Google Authenticator App, scan the bar code shown in console, now two authentication codes will be generated, write them to the console and that’s it. Now if the user with MFA logs in to the console, he/she has to provide MFA code also. 

12. Global Service: IAM is not region specific, it is global service.

13. Eventual Consistency: There is eventual consistency when you change any settings like policy/roles/permissions

14. Free to use

No comments:

Post a Comment