Getting feet wheat in AWS STS and IAM

In line policy what's up with this sts assume role

AWS terminology is vast, and at times it can be confusing. One effective way to tackle this is by drawing comparisons.

You can’t talk about AWS without mentioning IAM (Identity and Access Management) and VPC (Virtual Private Cloud). These two are the cornerstones for building solid AWS knowledge and effectively managing AWS accounts.

When it comes to Users and Groups under IAM, these concepts are similar to access control in Unix-based systems or Linux. However, Roles introduce a new concept, reflecting the ability of a user or an EC2 instance to take action on specified resources for a limited period of time.

Behind users, groups, and roles, there are policies, which act as the glue holding IAM together. But it's not so simple—it can get complex! There are several types of policies in AWS.

Let’s break down what a permission policy is. First, a permission policy is assigned to users or groups of users, and it is typically managed by the customer. On the other hand, AWS preconfigured policies are the building blocks you can use to create permission policies. A permission policy can be made from several building blocks or just one.

Now, let’s take a closer look at the example image below. You’ll see that under Joe’s permission policy, only one policy is allocated—named Customer-inline. It sounds fancy at first, but when you dissect it, you’ll realize it’s quite simple:

{

    "Version": "2012-10-17",

    "Statement": {

        "Effect": "Allow",

        "Action": "sts:AssumeRole",

        "Resource": [

            "arn:aws:iam::<aws account number>:role/EC2-Role",

            "arn:aws:iam:: ::<aws account number>::role/S3-role"

        ]

    }

}

User Joe is allowed to perform the action of switching roles.

The Resources field tells us who Joe can become, what actions he can take, and on which resources. This feature is on-demand and available for a limited time, thanks to the ephemeral nature of the Security Token Service (STS).

It’s important to focus on this line in the policy:

"Action": "sts:AssumeRole",

This line specifies an action, which belongs to the STS service. The action is to assume a role, and without this permission, no user or group can assume a role.

This brings up the question: What role(s) can Joe assume? The answer lies in the Resources field:

"arn:aws:iam::<aws-account-number>:role/EC2-Role",

"arn:aws:iam::<aws-account-number>:role/S3-Role"

Of course, this requires the roles to be created first. If we were talking about EC2 or S3, the story would be different because these services are already built into AWS. Roles, on the other hand, are not created by default, and they need to be configured first.

Policies are a fundamental part of AWS, and Roles are no exception. The policy above specifies that any action listed under “Action” is allowed on any resources. The asterisk (*) acts as a placeholder, meaning it applies to all resources.

“Customer-inline” represents what action a user, a group, or a role can perform, and it is directly attached. It is related to AWS services.

A role permission policy describes what actions a role is allowed to take on what services / resources, let's take a look at AmazonS3FullAccess policy.

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": [

"s3:*",

"s3-object-lambda:*"

],

"Resource": "*"

}

]

}