What I have learned about IAM on AWS

Amazon-Web-Services · 20 Mar 2022

This is the first post of content for preparing yourself for becoming an AWS Solutions Architect Associate.

We are going to start by discussing AWS Identity and Access Management (IAM). As cloud architects and engineers we know already that IAM is extremely important to protecting our cloud infrastructures. That is no different within AWS.

Microsoft has Azure Active Directory (Azure AD) as their identity provider service for all Microsoft cloud services and IAM for role-based access control. Azure AD can also be used as an identity provider for other cloud and hybrid services for single sign-on capabilities.

Azure AD can be used for managed identity for Azure users and resources, but Azure also has RBAC through IAM within Azure subscriptions, Resource groups, and individual services. The IAM within Azure is similar to how AWS IAM is used.

The role-based access control of AWS IAM allows you to create users for levels of access to AWS services and resources. When a user is created, they have no access to any resources within AWS.

For users to be granted administrator permission to access AWS resources, a group needs to be created with a role policy in that group to grant the level of access. Users are then added to these groups. This is a difference that how Azure IAM RBAC works as you can grant this access and permissions to individual users whether they are a part of a group or not.

The users that are added to Resource group or resource permissions within Azure IAM still need to be users that are included within Azure AD. Azure AD enforces the multi-factor authentication (MFA) on the user accounts, not within Azure IAM.

AWS IAM manages users, MFA enforcement, and group permissions. AWS IAM also assigns programmatic permissions to users and resources for API access to AWS resources.

When you create an AWS account, the first account that is created is the root account. This account is similar to a Global Administrator within Azure AD. It has full access to the account and all resources within that account. Unlike the Global Administrator in Azure AD, there is only one Root account within AWS. It should be protected and never used to access the AWS account.

Best practice is that you create an AWS Administrator group and add uses that need full administrator access to that group. The root account should be locked down with a strong password and MFA to avoid misuse and unauthorized access.

The root account is the only account that is associated with an email address for username.When a user account is created, their username is simply an ID that is created in AWS IAM with a password. As is a best practice with the root account, all IAM users should have MFA enabled. Within AWS IAM, there is an option to use an Identity provider to create the user, but by default, it is an assigned username that is NOT associated with an email address.

AWS IAM allows you to configure password length and complexity, and require users to reset their password on first login.

IAM roles are more secure and easier to manage than access keys.

This has been the first part of our journey to learn AWS for the Solution Architect Associate exam. The next post will focus on accessing and managing S3 storage accounts.

Advanced IAM

AWS Directory Services Cloud services to connect and use to Active Directory. SSO and connection to on-premises Active Directory.

AWS Managed Microsoft AD - high availability with domain in their own availability zone. This is similar to Azure AD DS. Multi-AZ deployment; patching, monitoring, and recovery; instance rotation; snapshot and restore Customer has the responsibility for managing within the AD for users, groups and GPOs; scaling out the DC; forest trusts; certificate authorities; Federation.
Simple AD - standalone directory in the cloud. Small <500 users or Large <=5,000 users. Does not support trusts to the on-premises AD.
AD Connector is a directory gateway, proxy to on-premises AD. Similar to Azure AD Connect.
Cloud directory - for developers. fully managed service.
Cognito user pools - nothing to do with AD. For SaaS services for web or mobile. Social media based sign-on. Similar to Azure AD B2C.

IAM Policies

Permission boundaries and evaluating IAM policies

Azure resource name (ARN) - arn:partition:service:region:account_id:

Partition - most popular is aws, but for some regions, such as China, this may be aws-cn.
Service - ex: s3, ec2, rds - etc
Region - ex: us-east-1
Account ID is a number assigned to the resource for your account.

Omitted values, such as global region may have a double colon - ::

At the end of the ARN, we use a “/” and then call the specific resource with a “*” that can be used as a wildcard.

Policies are a list of statements in a json format.

AWS managed policies - built-in policies

Customer managed policies - custom policies

Must attach a policy to a role for it to be affective.

Role then is attached to instances within AWS.

Inline policies are created for ad-hoc permissions on specific resource that cannot be used for other resources.

Policies are implicitly denied. You must create a policy to allow.

Permission boundaries - used to delegate administration to users. These prevent privilege escalation or unnecessary broad permissions. This is similar to custom roles or PIM in Azure AD.

A user that has Administrator Access can be given a boundary to specific resources, such as Lambda functions or DynamoDB only.

AWS Resource Access Management (RAM)

Access to resources across multiple accounts to reduce operational overhead.

Can only share with specific resources (currently eight).

Similar to cross-account peering to view resources.

Similar concept to cross-region access within s3 clusters.

RAM requires an acceptance of an invitation to share the resource between accounts.

AWS Single Sign-on

Centrally managed service to access AWS accounts and business applications. Similar to Enterprise applications marketplace within Azure AD.

Integration with Active Directory or SAML enabled applications.

I hope that you are enjoying this information so far. It is helping me to continue to comprehend these services as I prepare for the exam myself. Thank you very much.

Reference links:

What I’ve Learned about IAM on AWS

https://captainhyperscaler.github.io/amazon-web-services/2022/03/20/aws-iam

What I’ve Learned about S3 on AWS

https://captainhyperscaler.github.io/amazon-web-services/2022/03/20/aws-s3

What I’ve Learned about EC2 on AWS

https://captainhyperscaler.github.io/amazon-web-services/2022/03/22/aws-ec2

What I’ve Learned about EBS on AWS

https://captainhyperscaler.github.io/amazon-web-services/2022/03/22/aws-ebs

What I’ve Learned about Cloudwatch on AWS

https://captainhyperscaler.github.io/amazon-web-services/2022/03/22/aws-cloudwatch

What I’ve Learned about RDS on AWS