Access Undenied on AWS
Ermetic is launching a 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 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.
|Missing allow in an identity-based policy||A least-privilege, resource-granular policy for adding and the identity to attach it to.|
|Missing allow in a permission boundary or an SCP||Scanning of all relevant SCPs and permission boundaries, which returns a least-privilege resource-granular policy for adding, and the target (organizational unit, organization root, account, or permission boundary) to attach it to|
|Missing allow in a resource-based policy||A least-privilege, principal-granular policy for adding, and the resource to attach it to.|
|Explicit deny (in any type of policy: identity-based, resource-based, service control or permissions boundary||Scanning of all relevant policies to find the specific policy and statement causing explicit deny, and the outputting of that policy for the user to remove or rescope.|
Full details on the output format can be found in the Access Undenied README.
I also gave a conference talk on it!
You can watch my session at fwd:CloudSec in which I discussed the challenges we ran into while building this tool, and what can be learned from them. One challenge 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 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.
Ready to take it for a spin? Try "Access Undenied" here, or read more about it here.