AWS IAM Core Concepts

AWS is probably the most important part of the AWS ecosystem as it is responsible for managing access to all other services and provide the backbone for any security concepts in AWS. Let’s dive into the core concepts of AWS IAM in today’s article!

Security is one of the most important considerations in computing. You don’t want anyone to access private user information by finding a loophole.

Of course, this applies even more to app stacks run in the cloud. There is a tremendous amount of different services in the offers of major cloud providers that may or may not communicate with each other. To make this interaction safe and secure, most cloud providers offer a service for Identity Management.

Core Concepts in AWS IAM

First, let’s talk about the core concepts of IAM.

The main purpose of IAM is to control access to resources in an AWS account and have a user perform actions on these resources. Whether or not a user is allowed to perform a particular action on a resource is determined by a policy.

Let’s dig deeper into this:

Identity

The first building block of AWS IAM is the idea of Identity. This can mean anything from a user, a role, or a group.

User

A user in IAM’s terms is a person or a service that interacts with resources in an AWS account

Role

A role is an identity with permissions assigned to it. Unlike users, roles are not associated with a single person. Rather, they can get assigned (or being assumed) to users or groups.

Group

A group is a set of permissions

Policy

An Identity is then attached to a Policy, the second building block of IAM. A policy dictates whether or not an identity can perform certain actions.

Principal

Resource

A resource is anything that lives inside your AWS account, like an S3 bucket, a DynamoDB table or any other product you can order from AWS. Resources are identified by an “Amazon Resource Identifier”. If you’re curious, that is an AWS specific variant of a Uniform Resource Identifier.

ARNs are composed of four parts:

• The general prefix: arn:aws: is shared among all ARNs
• The resource type (e.g. s3, ec2, dynamodb)
• The region (e.g. us-west-2). Some services are not bound to specific regions, in which case the region part would be blank
• The account id (e.g. 123456789012)
• The specific resource part.

Examples:

• arn:aws:s3:::my-s3-bucket
• arn:aws:ec2:us-west-2:123456789012:instance/i-01234567890123456
• arn:aws:rds:us-west-2:123456789012:db:mydatabase

Action

A single action or a list of actions that a policy should affect.

Example:

• s3:GetObject

Effect

Either Allow or Deny – this is the actual permission associated with the policy

Condition

Any additional condition under which the policy should be enforced.

Example:

"NotIpAddress": {
    "aws:SourceIp": ["192.0.2.0/24", "203.0.113.0/24"]
}

Examples

Having established the basic wording for a Policy, let’s have a look at an example. The following policy would grant an identity the right to create lambda functions in any resources:

{
	"Version": "2012-10-17",
	"Statement": [
		"Sid": "a-name-for-your-policy",
		"Effect": "Allow",
		"Action": [
			"lambda:CreateFunction"
		],
		"Resource": "*"
	]
}

How to create and apply Policies

Best Practices

When it comes to security considerations of your cloud infrastructure, I advise to follow three basic principles when dealing with AWS IAM:

• Least privilege:
• Groups first:
• Rotate often:

Final thoughts

As AWS IAM is the core service for access control, it is some of the most complex services in AWS. Amazon needs to ensure that all types of corporate rules and policies can be implemented in this very AWS service.

Therefore, mastering AWS is a topic on its own – and could fill an entire course for learning. We have now seen the core concepts that can get you started.