AWS Identity and Access Management (IAM) enables you to securely control access to AWS services. As such there is no cost involved with it, yet IAM is one of the services that every single AWS solution uses and does NOT apply to a single region.
Identity Management
Root Account Credentials - the user account that created the AWS account is called the root account. The root account has complete access to ALL the resources on the account can’t be restricted to the root account - makes sense because otherwise a different user could lock the root account out of the account they created!
- IAM users - Authentication is the name of the game here.
- Federated users - Authentication can occur via some other mechanism and be added granted access to AWS resources via a role.
Roles vs Access Keys
A role is set of permissions that can be attached to groups, users, or services. Roles are not access key credentials - they don’t give a user the ability to login to AWS - they control what the user can do or not do on AWS.
For example, instead of creating a username/password in an instance so it can access s3, and IAM roles can be assigned to the EC2 instance. This works for other services that you would like to communicate in AWS. IAM Roles can also be used to grant access to users from one AWS account to another or enable a mobile app to access AWS resources.
When an IAM role is assigned to a resource, the resource takes on that role. As an application of this concept, the code that runs on an EC2 instance takes on the role assigned to that instance; the EC2 Metadata service stores the role in this case.
An access key is used to sign requests from outside AWS. AWS SDKs and CLI use access keys. Of course, they can be disabled. Of course, they can be deleted. They can not be retrieved once issued. Access keys do have a temporary nature to them which can be optionally assigned.
Policies
There are two types of policies: Identity policies (connected to a user, role or group) and Resource policies (attached to a service like a service element like a S3 bucket). AWS has Managed policies, which are defined by AWS, and Customer Policies defined by customers. It is possible to create policies attached to a specific role, called an In-line Policy, but these are not best practice - much cleaner to write policies then attached them to an identity.
Policies contain statements and each statement matches an AWS API request. Each statement has an effect, an action, a resource, and perhaps conditions. Without a statement all API requests, by default, ALL requests to use a resource are denied - default deny. For effect, all allows override any default denies and all explicit denies override allows. The star (*) can be used in a policy as a wild card as can template strings like: ${aws:username}. NotAction matches everything except the specified list of actions.
Notable Policy Conditions
aws:SourceIP- limits where the API call is being made from; can be combined with CIDR blocks; works for public or elastic IP address NOT private addressesaws:RequestedRegion- limits where the API can be called (to limit the locations resources can be created)ec2:ResourceTag/[tag]: [value]- only if the resource tag/value match (could apply to any resource that supports tags)aws:PrincipalTag/[tag]: [value]- only if the role/user tag/value matchaws:MultiFactorAuthPresent- requires MFAarn:aws:s3:::MyBucket- bucket permissionarn:aws:s3:::MyBucket/*- object permission (inside bucket)aws:PrincipalOrgID- restrict access to an account in the organizationaws:SourceVpce- restrict access to a specific VPCE
Permission Boundaries
Permission Boundaries sets the maximum permissions that an identity-based (user, role, group) policy can grant to an IAM entity; this enables administration delegation and set what privileges the admin can delegated. For instance, if you want to create a role to admin DynamoDB, first assign AdministratorAccess to the identity then apply the AmazonDynamoDBFullAccess policy to scope the privileges down. It’s like an SCP but at the account level.
Rotating Credentials
Rotating keys is a big part of security… Roles use STS to automatically get access to AWS resources and rotate credentials several times a day. From an EC2 instance you can retrieve the information from the instance meta-data.
Instance Profiles
Instance profiles are wrappers around an IAM role that will be passed to an EC2 instance. When an EC2 instance is created from the console the instance profile is created automatically; from the CLI you would need to create this and use it manually.
Cross Account Role
To establish a cross account role access, there is a source account and a target account.
- In the source account make a user group and add users to the group that need access to the target account.
- If the source account is a third party, then have the owner specify a External ID and provide both the target account # and the External ID.
- In target account, create a resource permission policy that gives access to the required resources.
- Create a trust policy specifying the account ID and the external ID using the
sts:ExternalIdcondition if the source account is a third party. - In target account, create cross-account access role from the source account/group name and attach the trust policy and resource policy from above.
- Copy ARN of new role
- In source account, create a policy to the user group that enables
sts:AssumeRoleto the target account/role ARN and specifies thests:ExternalIdif the source account is a third party.
IAM Access Analyzer & IAM Access Advisor
Yikes, these service names were difficult; then they got combined. Not sure how any exam will cover this topic. Access analyzer used to examine resources that are shared with an external identity (outside the zone of trust - an account or Organization). Access Advisor use to analyze the permissions granted by analyzing the last 90 days of CloudTrail logs and enables you to refine overly broad access AND it enables policy validation. NOW, Access Analyzer does all these things.