Cloud Security Solutions | Learn AWS | Understanding AWS IAM Policies

Understand fine grained authorization using Roles and IAM Policies

Lets demystify AWS IAM. What is a IAM Policy? What is a Role?

On every aws compute platform, your code will be running using credentials associated with the Role you provided to start the servers. Each role has no permissions by default, so you have to add capabilities to the role in order to interact with other AWS services. There are managed policies and user-defined policies, but having a deeper understanding will improve your security posture and also save you time parsing through the massive AWS documentation.

The way amazon does fine-grained security controls is by using IAM - Identity and Access Management. Understanding IAM is not immediately intuitive for some reason. I remember struggling for a long time.

To put it simply, an IAM policy statement is a permission statement attached to a Role.  For example, if an EC2 instance is trying to interact with s3, dynamodb, redshift or cloudfront, then it needs to have the corresponding permissions attached to the Role. The reason amazon has this is to avoid giving too much access to your server, in case of security compromises.

It is defined as a set of actions, resources on which the action may be applied, a list of principles (account ids or ‘*’’), and an effect. Actions, Resources, Principles, Effect.

Here is an example AWS CDK (cloudformation template framework) snippet. It simply gives the Role the ability to decrypt or describe the key, using the key resource.

handlerRole.addToPolicy(

  new iam.PolicyStatement({

    actions: ['kms:Decrypt', 'kms:DescribeKey'],

    effect: iam.Effect.ALLOW,

    resources: ['<encryption key ARN>'],

  }),

);

Actions. Each AWS Service (ec2, s3, dynamodb, etc) has a prefix and a set of actions. These actions are usually corresponding to the services’ APIs that it supports. For example, for Amazon S3, there are actions such as s3:GetObject, s3:CreateBucket, s3:PutObject. You can imagine that for each of amazon’s 200 cloud services, they each have a short-name and a list of actions that you can possibly call.

Resources, is typically a list of resources where the actions can be performed. This list typically contains a list of ARNs (an identifier you can usually find on the AWS Console), or just put ‘*’, if you are not focused on fully scoped down policies. 

The Effect term, is whether it is an Allow policy or a Deny policy. You can explicitly deny roles from doing certain actions, but typically people scope down the Allow to the minimum possible scope that the Role needs to perform its actions.

Principles is a list of accounts or just putting ‘*’ is quite common since using this field is only relevant for resource policies scenarios.

For cross-account access, use Resource Policies

Companies that setup accounts for multiple teams will frequently need to use resource policies. It is crucial to understand this if one needs to integrate with other teams. It will save time creating custom solutions and workarounds.

Not all services have this concept called resource policies. It is a concept for extending functionality cross-account. The resource needs to specify this Policy Statement and needs to specify the Principle field. You can imagine Team A wants to push some content into Team B’s sqs queue . To do this, oftentimes Team A will provide them an sqs queue arn (resource), and allow the action sqs:SendMessage for Team B’s account number (Principle). Other services with resource policies include s3, sqs, kms, and eventbridge. Stay tuned for a more detailed post about resource policies.

If you enjoyed this article, please follow and share with others!