IAM roles for non-human access

Any application you wrote in the cloud is probably going to accessing some other resources ion the cloud like, EC2 instance and Lambda functions need to access S3 or DynamoDB.

You need some identity to make those API calls to access data. Those API calls and that identity would be an IAM role.

So that you, as a developer doesn't need to handle any credentials at all, you just associate a role with this instance or with this lambda function. AWS will take care to rotate those credentials.

 

In Management Console, you will see:

"AWS Service" & "Another AWS account", first one is non-human access, second one is human-access.

 

Some questions like:

A developer is running an application on an Amazon EC2 instance that requires access to an Amazon S3 bucket. An administrator creates a role that includes policies that grant read permissions to the bucket and that allow the developer to launch the role with an Amazon EC2 instance. The instance is launched with the created role attached. What additional step is required for the application running on the instance to access the objects in the bucket?

"EC2 instance has role to access S3", which means non-human access IAM role is assoicated. So it is enough for EC2 instance to access objects inside that bucket.

Answer selection:

A. Create an IAM policy that allows the developer permissions to access the bucket. 
Attach the policy to the developer's IAM User.

B. No other steps are necessary. The application running on the instance 
will be able to access the bucket.

C. The administrator must grant the developer permissions to access the bucket.

A: Try to confuse you, whether you still need to give human-access to S3, NOT necessary if developer himself not going to access S3. Only EC2 instance need to access S3.

B: Which is correct

C: The same as A.

 

Because you may have some user just need to read data other than modify data, always give a "ReadOnly" role makes life easier.

 

IAM resource in JSON

Read: https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html

The place to find which actions you can allow in the resource.

Example:

 

---

 

Question: To save cost, you only want some cheap instance to be launched. So add "Condition", only allow "t3.nano/micro".

Chose options is correct?

 

Answer: C

When IAM doing the permission matching.

For example: "security-group", it doesn't have "InstanceType" attr, therefore, it results in an deny condiiton.

 

Resource based policy

One account wants to access the S3 bucket in another account.

We can use "Principal" section for S3 policy, in "Principal", list the AWS account ID which are allowed.

In acount 111xx, also need to list S3 bucket into "Resource"

 

Multi accounts want to access S3 bucket

Using "PrincipalOrgId".

 

Assume Role for cross acount access

In DyanmoDB Table, add "Action": "sts:AssumeRole" and "Princiapal" for the AWS account wants to access this table.

For the account want to access Table, add "Action": "sts:AssumeRole" as well.