About the least privilege principle with examples

Let’s talk about something important in securing applications in AWS: the principle of least privilege.

1. What is the principle of least privilege about?

The least privilege principle states that IAM users, roles, groups and policies have only the least number of permissions necessary for the given task and no more.

Administrators and developers should assign users and roles the absolutely necessary permissions first and only add new ones when needed.

2. Examples

Let’s see some examples where the least privilege principle can be applied.

2.1. Access to S3 buckets

It’s common to assign a role to EC2 or ECS instances or Lambda functions so that they can access other AWS services, like S3.

It’s common that these roles are granted full access to S3, which is a bad practice because it provides access to other, non-application-related buckets as well.

This is what we are talking about:

{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Effect": "Allow",
        "Action": "s3:*",
        "Resource": "*"
    }
  ]
}

While this policy might be OK for an administrator, it’s not good for an EC2 role.

This policy is much better:

{
  "Version": "2012-10-17",
  "Statement": [
      {
        "Effect": "Allow",
        "Action": "s3:PutObject",
        "Resource": "arn:aws:s3:::<BUCKET NAME>/*"
      }
  ]
}

This allows the role, which the policy is attached to, to write objects (files) to the specified bucket, but access to other buckets is not allowed.

2.2. Too many administrators

Another frequently seen security issue is that too many administrators exist for a given account. Giving everyone admin access in the team is easy, but it also comes with a security risk. Not necessarily because someone would steal sensitive information from the AWS account but it’s rather a big exposure for something unwanted happening (e.g. an object which should not be deleted gets deleted or someone not knowing much about security groups or network ACLs misconfigure something).

The full admin access policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

It allows the user to do anything they want. It’s needless to say that this comes with great responsibility. It’s better to start with the most necessary permissions and gradually add new ones when necessary.

2.3. Security group settings

The least privilege principle can also be applied to security groups.

It can be sometimes seen that security groups have the following setting:

SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 22
    ToPort: 22
    CidrIp: 0.0.0.0/0

The above CloudFormation snippet creates a security group where SSH-ing into an EC2 instance is allowed from any IP address.

AWS doesn’t make developers’ and devops engineers’ life easy here because when an EC2 instance is launched through the console, the above inbound rule comes as default if one chooses to create a new security group for the instance.

Instead, it’s recommended to restrict the access to the IP address(es) of the office or VPN:

SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 22
    ToPort: 22
    CidrIp: 3.5.7.9/32
  - IpProtocol: tcp
    FromPort: 22
    ToPort: 22
    CidrIp: 10.12.14.16/32

This rule only allows SSH access to the instance from 3.5.7.9 and 10.12.14.16, and the access will be denied from any other addresses.

It’s even better to use Session Manager, because in this case it’s not necessary to open port 22. Through Session Manager, one can SSH into the instance from the console.

3. Summary

One important aspect of making cloud infrastructure secure is to apply the least privilege principle when architecting solutions or giving permissions to account users.

Assign only the least number of permissions necessary for roles, users and groups, and add new permissions when necessary.

Thanks for reading and see you next time.