Hello Developers!
Here i dropped short note about

1. Organization concept in AWS
2. SCP Hierarchy
3. IAM conditions
4. Deference between IAM roles and Resource Based Policies
5. IAM Permission Boundaries
6. AWS Identity Center

Lets talk about one by one

Organization concept in AWS

So, sometimes we need to work with multiple AWS accounts, in this case this global service helps to achive it. this service allows to manage multiple AWS accounts.

Important to know, There is only one main account and this account has super power to manage other member account (rest account know as member accounts).
Also member accounts cannot be a part of other organization, or member account can onlu be part of one organization.

Please refer below attachment to get better idea of this concept

As you can see, Root Organizational unit (OU), which is the outermost of your account. within this root ou we can set Main organizarion or management account.
After then we can create sub OUs. you can see we set up two OUs which is Dev OU and Prod OU. Then we can create member accounts within it. Also we can create another level of account as Prod OU. So, we can extend our hirachical tree as much as we want.

So why do we need this concept ?
Actually, we can gain lots of advantages.

1. Better security - for example, having multiple VPC in single account is less secure than having multiple accounts because accounts more separated than VPCs.
2. Use tagging standards for billing purposes.
3. Enable CloudTrail on all accounts, send logs to central S3 account
4. Security: SCP or Service control policies

SCP Hierarchy

This is an IAM policy which applied to OU or Accounts to restrict Users and Role
Important to know: This SCP policies not apply to manage account, which mean manage account or root accout has full admin power.

refer below attachment to get better idea of SCP

Management Account: No restrictions even defined DenyAccessAthena SCP to Management Account. Still management account has access to Athena.

Account A: Since Root OU has FullAWSAccess SCP, Account A also inherit that abilities. But prod OU has DenyRedshift SCP, there for this account Can do anything EXCEPT access Redshift (explicit Deny from OU).

Account B: Same as account A, Can do anything EXCEPT access Redshift (explicit Deny from Prod OU) and EXCEPT access Lambda (explicit Deny from HR OU).

Account C: Can do anything EXCEPT access Redshift (explicit Deny from Prod OU)

There are two strategies in SCP

1. Blocklist
2. Allowlist

IAM Conditions

These conditions apply to policies within IAM. So, that can be for your resource policies like S3. Actually, it could be anything.

Condition-1: ass:SouceIp - with the help of this condition, we can restrict the client IP from which the API calls are being made

in this approach we can ensure that only your company can access your own AWS environment.

Condition-2: ass:RequestedRegion - with the help of this condition, we can restrict the region the API calls are made to

Condition-3: ass:ResourceTag - with the help of this condition, we can restrict based on tags

Condition-4: ass:MultiFactorAuthPresent - with the help of this condition, we can to force MFA

IAM for S3
This is a bit tricky one, So lets discuss about it.
refere this attachment which consist S3 Policy.

There is two statements

1. s3:ListBucket permission applies to arn:aws:s3:::test Because this is bucket level permission but
2. s3:GetObject, s3:PutObject, s3:DeleteObject applies to arn:awn:s3:::test/* because these are object level permission.

IAM Roles vs Resource Based Policies

Lets talk about what is the fundamental difference between IAM Roles vs Resource Based Policies.

Assume if you want to perform API call on a S3 bucket, then you do have two ways to achive it.

1. attach a role to a user
2. handle bucket policy

So, what is the different ?
When you assume a role (user, application or service), you give up your original permissions and take the permissions assigned to the role
When using a resource-based policy, the principal doesn’t have to give up his permissions

IAM Permission Boundaries

Important point, IAM Permission Boundaries are only for users and roles NOT for Groups.
Advance feature to use a managed policy to set the maximum permissions an IAM entity can get.

We have this IAM permission boundaries. It looks just like an IAM policy. So we're saying, allow everything on S3 CloudWatch and EC2. So we attach this, for example, to an IAM user and that's its permission boundaries. That means that it can only do things within S3 CloudWatch and EC2. And then you need to specify on top of things an IAM permission through policy. And so here, say we attach to the very same user, allow iam:CreateUser, resource *. So there is a boundary and there is an IAM policy with permissions. What is going to be the results permission in this case? Well, nothing, no permissions because the IAM policy is outside the IAM permission boundary. Therefore, our user is not allowed to create other IAM users because that is not in its IAM permission boundary.

Effective permissions ??

Example IAM Policy

Q1 - Can you perform create SQS queue ?
No, You can't. The reason is first statement Deny all the SQS actions, so you cant.

Q2 - Can you Delete Queue ?
No, you can't. Even the second statement allow to delete queue permission, first statement blocked this DeleteQueue effect.

Q3 - Can you Describe EC2 Instance ?
No you can't. Even there is no Deny this action, this IAM policy don't describe any EC2 actions. which mean no access to EC2.

AWS Identity Center

This is a successor to AWS Single Sign-On service.
This service provides

1. One login (single sign-on) for all your

   • AWS accounts in AWS Organizations
   • Business cloud applications (e.g., Salesforce, Box, Microsoft 365, …)
   • SAML2.0-enabled applications
   • EC2 Windows Instances

2. Identity providers

   • Built-in identity store in IAM Identity Center
   • 3rd party: Active Directory (AD), OneLogin, Okta...

PS: This article is based on the concepts I learned from Stephan Maarek's AWS Solutions Architect - Associate course. I would like to thank Stephan for his excellent teaching and for sharing his deep expertise in AWS. Without his guidance, this article would not have been possible. If you're looking to expand your AWS knowledge, I highly recommend Stephan's courses.