Day 33: Advance in I AM Service

𝐎𝐫𝐠𝐚𝐧𝐢𝐳𝐚𝐭𝐢𝐨𝐧𝐬:

👉Allows to manage multiple AWS accounts, Global service

👉Service Control Policies applied to OU or Accounts to restrict Users and Roles

👉IAM Conditions- aws:SourceIp, aws:RequestedRegion, ec2:ResourceTag, aws:MultiFactorAuthPresent, S3 > bucket/object level permission

𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐏𝐨𝐥𝐢𝐜𝐢𝐞𝐬 & 𝐚𝐰𝐬:𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐚𝐥𝐎𝐫𝐠𝐈𝐃:

👉Aws:PrincipalOrgID can be used in any resource policies to restrict access to accounts that are member of an AWS Organization

𝐈𝐀𝐌 𝐑𝐨𝐥𝐞𝐬 𝐯𝐬 𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞 𝐁𝐚𝐬𝐞𝐝 𝐏𝐨𝐥𝐢𝐜𝐢𝐞𝐬:

👉Cross account-attaching a resource-based policy to a resource or using a role as a proxy

👉When we assume a role we 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

𝐈𝐀𝐌 𝐏𝐞𝐫𝐦𝐢𝐬𝐬𝐢𝐨𝐧 𝐁𝐨𝐮𝐧𝐝𝐚𝐫𝐢𝐞𝐬:

👉Supported for users and roles (not groups)

👉Policy to set the maximum permissions an IAM entity can get

👉Used in combinations of AWS Organizations SCP, Delegate responsibilities to non-administrators, self-assign policies and manage their own permissions, to restrict one specific user

𝐈𝐀𝐌 𝐈𝐝𝐞𝐧𝐭𝐢𝐭𝐲 𝐂𝐞𝐧𝐭𝐞𝐫:

👉One login (single sign-on) for AWS accounts in AWS Organizations, Business cloud applications, SAML2.0-enabled applications, EC2 Windows Instances

👉Identity providers- Built-in identity store OR 3rd party

👉Permission Sets — Multi-Account Permissions, Application Assignments, Attribute-Based Access Control

Organizations:

• Overview:

Organizations is an AWS service that allows you to consolidate multiple AWS accounts into an organization that you create and centrally manage.

It is a global service, providing a way to structure and manage multiple AWS accounts.

• Service Control Policies (SCPs):

SCPs are applied at the organizational unit (OU) or account level within Organizations.

SCPs allow you to set fine-grained permissions and restrictions on what users and roles in those OUs or accounts can do.

They act as a layer on top of IAM policies and can deny actions even if an IAM policy allows them.

• IAM Conditions:

IAM conditions are used to add constraints to policies. Examples of conditions include aws:SourceIp (restricting based on the source IP address), aws:RequestedRegion (limiting to specific regions), ec2:ResourceTag (using EC2 tags for resource-level permissions), aws:MultiFactorAuthPresent (ensuring MFA is present), and S3-specific conditions for bucket and object-level permissions.

Resource Policies & aws:PrincipalOrgID:

• Resource Policies:

Resource policies are JSON policy documents that you attach to a resource (like an S3 bucket, SQS queue, etc.).

They define who can access the resource and what actions they can perform.

They are used for cross-account access or to grant permissions to entities that do not belong to your AWS account.

• aws:PrincipalOrgID:
• aws:PrincipalOrgID is a condition key that can be used in resource policies.
• It restricts access to AWS accounts that are members of an AWS Organization with a specific ID.
• This is useful for ensuring that only accounts within your organization can access certain resources.

IAM Roles vs Resource-Based Policies:

• Cross Account Access:
• Cross-account access involves granting permissions to an IAM role in another account. This is done either by attaching a resource-based policy to a resource or using a role as a proxy.
• Role Assumption:
• When you assume a role, you give up your original permissions and take on the permissions assigned to the role. This is a key security feature for cross-account access.
• Resource-Based Policies:
• With resource-based policies, the principal (entity trying to access the resource) doesn’t have to give up its permissions. Instead, the resource owner defines who can access the resource and what actions they can perform.

Permission Boundaries:

• Overview:
• Permission boundaries are supported for users and roles (not groups).
• They set the maximum permissions an IAM entity (user or role) can have.
• They are often used in combination with AWS Organizations SCPs to create a secure and controlled environment.
• Use Cases:
• Used to delegate responsibilities to non-administrators, allowing them to self-assign policies and manage their own permissions within specified boundaries.
• Can be used to restrict specific users’ permissions even further than the SCPs.

Identity Providers & Identity Conter:

• One Login (Single Sign-On):

IAM Identity Providers (IdPs) enable single sign-on (SSO) for AWS accounts, business cloud applications, SAML 2.0-enabled applications, and EC2 Windows Instances.

• Identity Providers:

Built-in identity stores or third-party providers can be used as identity providers.

Built-in identity stores are AWS Directory Service, and third-party providers can include systems like Microsoft Active Directory or Okta.

• Permission Sets:

Permission Sets are used for multi-account permissions, application assignments, and attribute-based access control.

They help in managing permissions for users across multiple AWS accounts efficiently.