Subscribe
AWS

AWS IAM: Between dream and nightmare

AWS IAM: Between dream and nightmare

I have been using AWS professionally for over 4 years now.

To be a bit old-fashioned, when I started on AWS, the following services and features did not exist:

  • The ALB/NLB
  • ACM
  • ElasticSearch Service
  • Lambda inside a VPC or with the duration of more than 5 minutes
  • ECS/EKS/ECR

During these 4 years, I had the opportunity to do a lot of IAM, essential to deploy secure solutions on Amazon.

IAM and least privilege

Identity and Access Management (IAM) is the AWS service that defines users or roles and their associated permissions.

By following the precepts of the AWS well architected framework, the good practice is to assign the finest possible rights for our application to work.

Why this? Several reasons here:

  • If my application were to be compromised, I limit the impact as much as possible, because the attacker will only have restricted access to my infrastructure.
  • This can allow me to detect abnormal behavior of my infrastructure, if I see a lot of access denied for the role of my EC2 on APIs that it is not supposed to exploit.
  • It is a good general hygiene practice in IS to limit as much as possible the perimeter accessible by an application.

The tools provided

In order to position fine rights, AWS allows the creation of policies to indicate the scope of a user or a role.

This tool describes, in JSON format, the rights to be applied. This gives in a very basic way something of this type :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "mapolicyS3",
      "Action": [
        "s3:CreateBucket"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::demo-bucket-tferdinandnet"
    }
  ]
}

As you can see, the policies are human readable and allow for more or less efficient filtering across all API calls and AWS resources.

To assist in the creation of these policies, AWS provides several tools, including :

In addition, there is documentation of the APIs, with their filtering and resource naming scheme on the official website: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html.

So everything's perfect?

NO! There are indeed a certain number of tools and documentation on AWS, which will answer a good part of the use cases, as long as you don't try to really make the least privilege ...

Why is that?

Limits

First of all, I'm going to talk about AWS limits. There are two types of limits on AWS:

  • Soft limits: these limits are mainly there to protect the customer from misusing AWS and making his bill explode, and can be changed with a support ticket.
  • Hard limits: These limits apply identically to all AWS accounts and cannot be modified under any circumstances.

It is important to note that the limits on Amazon's MRI can be reached fairly quickly when trying to severely restrict resource rights, as policies quickly become very verbose.

As an example, you can put a maximum of 10 managed policies on a role or user, with a limit of 6144 characters for each one (without counting spaces), to give an example of the least privilege on a "strong" service like RDS can easily exceed 10,000 characters...

For more information on the limits, I invite you to consult the associated page: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html.

Heterogeneity

If limits were the only problem... We can also talk about the heterogeneity of resource filtering, some are based on the ARN, some on the name of the resource, some on an ID generated at the time of its creation... Concerning this case, it is almost impossible to manage restricted privileges, because to restrict the right to create/modify the resource, it must already exist!

Also, the available conditions are not always the same, or even do not have the same names. A simple filtering on a tag (quite basic on AWS) may not be possible depending on the resources, or the API call made.

The support is out...

Because of the problems I have mentioned above, I had to contact support several times for anomalies that I could not explain.

Apart from the fact that I've been told very frequently "Yeah, your policies are complicated", in most cases, support is useless at best. At worst, it meets my need, not understanding that my job is to secure deployments and infrastructure in AWS...

The support is the champion of the wildcard (*), a magical tool that you wield when you can't find it. The support solution is very often to pass the API call as a wildcard resource or the API itself.

The concern is that from then on, we don't make any more minimum privilege, we certainly restrict, but very far from the minimum...

I could also talk about the tickets I've been opening lately. They were once again known bugs in the IAM AWS that could only be circumvented by wildcard, without any resolution date being given to us .

In conclusion

You'd think with my last paragraphs that I would find AWS's IAM completely off the mark, but that's not the case.

I'm aware that resource filtering is a complex thing to understand and implement, and Amazon is far from being a bad student at this point.

However, I think Amazon would win by giving real examples of least privilege in their documentation instead of inserting wildcards everywhere. It also creates tensions when people like me want to restrict rights since many users don't understand why we are moving away from AWS documentation.

Moreover, the limits on the IAM are aberrant and unnecessary, they just push to give wider rights to save precious characters and make their automation more complex.

Security is a major issue for companies, let's hope AWS hears them!

Read next

Comments ()