🍒 IAM: Basics 🍒
IAM what's that?
It is pretty quirky to understand but extremely powerful.Cannot dive deep at once, experiment with code-base and enhance the understanding. But to get started, think of it as A tool-set to control the access to resources provided by AWS.
Just generalizing the idea, access to resources could be of any form as following:-
🍒 People using Resources directly.
EX: I want to give other users of my account to have access to an only S3 bucket, or it could be access to another AWS account
🍒 AWS Resource using other AWS Resources to get work done.
Ex: I want to build my application, store its output and I want codebuild to take care of it on my behalf. I have my source code in codecommit and I want the desired result in ECR. So codebuild which is AWS provided resource needs access to codecommit resource and ECR resource too to carry out the flow.
Simple as that, but the quirkiness will start when trying to implement the way we want. :P
ALERT! Never use the root account. It can lead to terror. By default, Root has access to all and has all permission.
Features of IAM
🍒 Federated with other systems: Third-party based logins.
🍒 Cross account access: Access resources/performing actions from AWS account to another AWS account.
🍒 Granular control access: Complete control of what to access/perform actions on what resource, when and how, it could be any conditions set.
🍒 MFA: OTP based login gives an additional layer of security.
Remember everything in AWS communicates via API, will get into it later.
It takes care of two processes:
🍒 Authentication:
Are you the one for me? XD This step may not be necessary in few places such as S3...will know about it in later posts
🍒 Authorization:
Are you allowed to do whatsoever actions?
IAM components:
What makes IAM work?
User:
🍒 Has an identity as a user.
🍒 Have credentials to login via console/CLI
🍒 Has secret key and access which should never be shared. BAD!
🍒 By default, denied access to all.
Group
🍒 Two or more User forms a group.
🍒 Create a group, add users to it and provide common permission for easy and organized control because apart from defined users some of them have common requirements.
Role
🍒 To give exclusive permission.
🍒 The best way I understood this was with Linux example.
Ex: I have been denied write operation on /etc/hosts file.
I'll use sudo and do write operations.
So, here write operation is exclusive permission I needed so I assumed to be sudo (role) and did it. Simple isn't it!
Policy
🍒 Defines the action.What you have access to and what you don't.
🍒 A policy can be attached to User, Group, Role.
🍒 They are predefined and can be written by us.
🍒 Actions or resources that are not explicitly allowed are denied by default
🍒 Only 10 Managed policy can be attached to a role/user/group, if more needed request AWS customer support.
🍒 There can be any inline number of policies attached to role/user/group.
Types of Policy
Identity-based policies
Permission policies, attached to IAM identity (users/groups/role). these can be:
🍒 AWS Managed policy: Managed by AWS
🍒 Custome policy: Managed by us.
🍒 Inline Policy:
Particular to respective role/users/group..
Inline policy cannot be shared with others.
When Role/user having inline policy is deleted, inline policy also gets deleted.
🍒 Resource-based policies
Policy attached to resource (principal) directly (i.e S3 and IAM role trust policy) instead of using a role as a proxy. It is mandatory to specify principal.
Basically, it tells what action a specified entity can perform on resources under given circumstances. Will get into practicals for better understanding.
Resources that you want to share are limited to resources that support resource-based policies. Can attach resource-based policies to:
🍓 Amazon S3,
🍓 Amazon Simple Notification Service (SNS),
🍓 Amazon Simple Queue Service (SQS),
🍓 Amazon Glacier Vaults,
🍓 AWS Lambda functions,
🍓 VPC-endpoint policies
🍒 Service Control Policies
Service Control Policies (SCPs) are used to manage all the AWS Accounts in your AWS Organization. An organization might maintain numerous accounts based on needs...for production, for development, for testing..yadda yadda ...By default, it has all allow permissions.
Some essentials: When trying to use roles and policies first understand what policies to be applied to? under what conditions? on what resources? then understand the permission polices that are applicable and how it works on the resource independently?
Neat-Picks to be understood
🦋 IAM is a global service, which means it’s covering all regions within an account.
🦋 By default, user/role has deny permissions. When given permission it is within their account.
🦋 Access to cross-account, must write policy and attach.
🦋 When explicitly allow action/resource is mentioned the rest are denied. 🦋 Always evaluate policies combined, precedence to deny is given first, thus it first checks for deny actions and then checks for allow actions
🦋 All actions are independent of each other. Treat it as independently.
