Access Undenied on AWS

Introducing our new open-source tool: Access Undenied on AWS. The tool parses AWS AccessDenied CloudTrail events, explains the reasons for them and offers actionable fixes.

Introducing AWS Access Undenied

Access Undenied on AWS is an open source CLI tool that analyzes AWS CloudTrail AccessDenied events, scans the environment to identify and explain the reasons for the events and offers actionable least-privilege remediation suggestions. Basically, you give the tool a CloudTrail event with an “Access Denied” outcome, and the tool will tell you how to fix it!

What’s the problem?

It’s a beautiful day. You’re building a lambda function, and everything is going exactly as planned. The code looks great. Then you give it a test and…

"errorMessage": "An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied",

As you know, many things in IAM can cause an action to be denied; here’s a partial list:

• Missing allow in an identity-based policy
• Explicit deny in an identity-based policy
• Missing allow in an resource-based policy
• Explicit deny in an resource-based policy
• Missing allow in a service control policy
• Explicit deny in a service control policy
• Missing allow in a permission boundary
• Explicit deny in a permission boundary

And we haven’t yet mentioned VPC endpoint policies, session policies or granular service-specific data access controls.

Even once you know the policy type causing “access denied,” you still have to find the policy and the statement inside the policy causing the denial and potentially replace it with a least-privilege alternative.

AWS to the rescue

When we started working on AccessUndenied, AWS access-denied messages had very little detail on the reasons for which access was being denied. In 2021, for easier permissions troubleshooting, AWS introduced changes to access-denied errors. These changes offered more detailed error messages, such as:

User: arn:aws:iam::777788889999:user/JohnDoe is not authorized to perform:
codecommit:ListRepositories with an explicit deny in a service control policy

Further information can be found in the AWS IAM documentation.

These AWS error message updates have significantly improved the ability of users to troubleshoot Access Denied messages. However, we still find significant use cases for an automated strategy for remediating access-denied situations and facilitating access.

But challenges remain

AWS users trying to resolve Access Denied scenarios still encounter many challenges:

• Some AccessDenied messages still do not provide details. Among the services for which some, or even many, messages are lacking in details are: S3, IAM, STS, CloudWatch, EFS, DynamoDB, Redshift, Opensearch and ACM. For example:

  An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

  And here’s another example:

  "User: arn:aws:iam::123456789012:user/username is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::123456789012:role/role-name"

• When the reason for AccessDenied is an explicit deny, users can have difficulty tracking down the specific policy and statement that give the explicit deny. Specifically, when the reason is an explicit deny in a service control policy (SCP), it is difficult to find and assess every single policy in the organization that applies to the account.
• When the problem is a missing allow statement, it can still be challenging to create the least-privilege policy that allows the desired access without granting excessive permissions.

Some of these problems are here to stay. For example, it is quite sensible that AWS does not grant unprivileged actors details on the exact content and identity of the service control policies preventing them from acting in a certain way. The need to maintain a balance between easy troubleshooting for builders and opacity to attackers requires that users do some of the work in troubleshooting more complex scenarios.

Access Undenied on AWS – an automated solution

Access Undenied on AWS is a free open source tool that runs completely locally (or in your environment). It analyzes AWS “access denied” events and offers actionable remediation steps to facilitate access. You completely control its permissions and actions, and it does not send data to anyone. You can use it from the command-line interface (CLI) on a local machine on single events, query and download batches of events for analysis or even run it from a lambda function and have a lambda that receives an event and returns the reason that access was denied.

Full details on the output format can be found in the Access Undenied README.

Challenges

While building this tool we ran into challenges. One of them was in constructing exact permission representations from CloudTrail events. (I made extensive use of Ian Mckay’s iam-dataset project, which we also contribute to). Another challenge was using the basic SimulateCustomPolicy API to simulate more complicated IAM scenarios.

Contributing to Access Undenied

Access Undenied supports resource policies for many resources and some of the most common condition keys, but you can help us and the community make Access Undenied even more awesome by contributing to some good first issues in the repository.

If you stumble across any issues, or wish to suggest features you’d like to see supported in the tool, feel free to open new issues on the GitHub repository.

Feel free to write to me with questions, suggestions and comments.
[email protected] 
Twitter: @NoamDahan

Ready to take it for a spin? Try "Access Undenied" here, or read more about it here.