Introduction to AWS IAM Identity Management
AWS IAM (Identity and Access Management) is a complex topic while learning about AWS Cloud. There are lot of terms under this topic that can be confusing and are often wrongly used. In this post I will be giving an overview of Amazon AWS IAM Identity Management Service.
Table of Contents
I am going to explain few terms below that you should be aware of
- IAM Principals: These are people, services or applications that can perform actions on AWS Accounts
- IAM Policies: These define what a principal is allowed to do on a resource
- Resource: Anything we create on AWS is a resource and has a unique ARN
IAM Principals
IAM Users
- These are the most basic form of IAM Principal and often represent a person or application.
- These exist only in the account they are created and can’t be used for other AWS account in same organization.
- These can have both Console login or CLI login access
IAM Roles
- IAM Role is an identity assumed by a person, service or resource
- Roles can be used to provide identity in large organizations using SSO
- IAM Roles have AssumeRoleTrust policy which specifies what principals are allowed to assume a role
Root User
- Full priviledged user in an AWS Account
- Username is the email address used to create the AWS Account
- Most important account as it gets all communications from AWS for any critical activity
IAM Groups
- It’s a group of IAM Users
- Users in group can inherit permissions from policies attached to the group
- IAM Groups are not IAM Principals like IAM Users
AWS Services
- AWS services can act on resources within an account by assuming IAM roles
- Services like Lambda and EC2 often require role-based permissions.
- In IAM policies, AWS services are represented as .amazonaws.com, commonly seen in Assume Role Trust policies.
Federated Identities
- In organizations, there may be multiple AWS accounts and to create users with access to each account is repetitive task hence AWS has provided Federated Identities which can use centralized Identity (Active Directory) or SAML Authentication services (ADFS, Okta, etc.) or OpenID to grant acces to assume specific role in specific account they are authorized to access.
- MFA is done by authentication system so no need for AWS Mfa.
- IAM Roles must trust SAML Identity Provider for Federated Access
IAM Permissions
Policies define what a principal is authorized to do in your account. A Principal can have multiple permissions/policies attached to it.
AWS Provides many existing managed policies called AWS Managed Policies which can be used as it is however customers can also create custom fine-grained policies called Customer Managed Policies or Inline Policies
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]The policy in above example used wildcard “*” for Action and Resource which allows to perform all actions on all the resources.
IAM Policy consists of:
Sid or statement identifier (optional)
Effect
- It defines if the policy allows or denies actions
- By default everything is implicit deny
- AWS evaluates all possible policies applicate and looks first for any explicit deny before allowing anything
- If there is any explicit allow, then only the action is allowed. Otherwise, all requests are denied.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ec2:Describe*",
"secretsmanager:ListSecrets",
"secretsmanager:GetSecretValue"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Action": ["*"],
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:HR-Passwords*",
"Effect": "Deny"
}
]
}In the above policy, the first statement allows list and get secret on all resources, however on second statement, there is explicit deny for “HR-Passwords*” so the user/principal this policy is attached to won’t be allowed to get the HR Password
Action
- List of things that can be performed on resources
- Actions can be written in form of ec2:StopInstance which means that the statement allows to stop an EC2 instance.
Resource (ARN)
- Resources the statement applies to.
- These are always in ARN format which contain AWS Region, Account ID, Resource name
- Example: arn:aws:s3:::mys3bucket123
- Global Services (like IAM) have empty value for the region
- All AWS Managed Policies have wildcard as resource value since they don’t know what resources would be there in an account
Condition:
- These are optional statements that must be satisfied for policy to be granted.
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::mys3bucket123/AWSLogs/AccountNumber/*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "vpc-abcdef2",
"aws:PrincipalServiceName": "glue.amazonaws.com"
}
}
}The above policy denies writing to mys3bucket123 if source vpn is not vpc-abcdef2 and service is not AWS Glue.
Principal
- This is only required for resource-based policies not identity-based policies.
- It specifies the Principal that is allowed/denied access to a resource.
- The policy can be applied to anyone or all AWS customers using wildcard “*”.
While this is not a deep dive into IAM but still I have tried to cover basics. I might add more things to this page in future.
