AWS IAM is a magnificent creation. But developers and security professionals continue to face some recurring challenges while dealing with the service.
To that end, I’ve compiled a wishlist of 5 AWS IAM feature requests:
- IAM Authorization Debugging
- Mapping of API Calls, IAM Permissions, and CloudTrail Events
- SCP Audit Mode
- SCP for Resources
- API Request Parameters as Condition Keys
IAM Authorization Debugging
You make a request to AWS but you receive an error message saying it is unauthorized. This is a frustrating but common experience for developers. Knowing details like the values of condition keys could be extremely helpful in debugging IAM denials.
What can developers do today to understand authorization denials? Access denied error messages from AWS have improved recently, and they share context like which policy types are responsible for a denial. The sts:DecodeAuthorizationMessage action also provides useful details. Unfortunately, it is not supported by the vast majority of AWS services. You could also use the IAM policy simulator or the open-source access-undenied project to help you debug.
Mapping of API Calls, IAM Permissions, and CloudTrail Events
For a given AWS API call, what IAM permissions are needed? What are the CloudTrail events that will be generated for that API call? The relationship is not always one-to-one and can be a cause of frustration for both developers and security professionals. A programmatic mapping of these 3 entities can be very valuable for both developer productivity and for least privilege enforcement.
Not knowing all the IAM permissions needed for an API call can slow down developers. So, they often resort to trial and error. Or they might get frustrated and use overly permissive policies to move past the issue. A fantastic, unofficial mapping of IAM permissions with API calls can be found at permissions.cloud, but ideally AWS should maintain an official, up-to-date documentation.
Not knowing how IAM permissions map to log events makes it hard to pare down IAM privileges to move towards least privilege. AWS Access Analyzer has gotten better at suggesting least-privilege policies, but it still has limitations. Trailscraper is an interesting open source project that also tries to address the issue of least privilege.
If you're interested in some of the oddities around API calls, IAM permissions, and CloudTrail events, check out this blog post.
SCP Audit Mode
Service Control Policies (SCPs) are a powerful construct to limit the permissions of users and roles within AWS accounts. SCPs help organizations follow the principle of least privilege and reduce their attack surface.
However, AWS provides no audit mode for SCPs. So, deploying new SCPs may break production environments. In fact, only recently did access denied error messages even start revealing if SCPs were responsible for an access denial.
Workarounds to predict the impact of deploying an SCP are imperfect and time consuming.
- One option is to first deploy the SCP to staging accounts, but staging and prod can differ from one another in non-trivial ways.
- Another option is to piece together which permissions are in use via CloudTrail events. However, CloudTrail notoriously “does not log all AWS services and events”. Also, as discussed above, it is not easy to determine which permissions are required for different AWS API actions. Data from other sources like billing and the AWS Cloud Control API could help, but the picture may still be incomplete.
If you’re interested in diving deeper into the challenges of deploying SCPs, check out how Figma deployed region and service allowlisting.
SCP for Resources
Service Control Policies (SCPs) can be used to limit permissions of identities within your AWS accounts, but they do not limit access of identities outside of your AWS accounts!
An SCP-equivalent for resources – they could be called Resource Control Policies (RCPs) – could limit access to resources by all identities - even those outside of your AWS accounts. For example, an RCP might prevent the assumption of any IAM role in your AWS account by IAM principals outside your organization. Or, it might deny any IAM principal outside your AWS account from reading your S3 bucket data.
The aws:PrincipalOrgID condition key is the closest feature to RCPs that I’ve found. By using this condition key in resource policies, you can limit the access of IAM principals outside your AWS organization! However, forcing developers to include such a condition in every resource policy can be burdensome. You might consider enforcing such a requirement through IAC scanning tools.
API Request Parameters as Condition Keys
Admittedly, we’re getting greedy with this one… But many have pointed out that IAM often isn’t expressive enough in allowing certain API actions while blocking others. For example, a common desire is blocking the creation of public EKS clusters or API gateways while allowing the creation of private ones.
If API request parameters were somehow exposed as IAM condition keys, it could bring a few benefits. First, IAM policies would instantly become way more expressive. Second, IAM conditions may become easier to reason about because of the parallelism with API action request parameters.
Needless to say, we’re unlikely to get a clean implementation of this feature request. One challenge is that API actions and IAM permissions already don’t cleanly match up with one another. But AWS does frequently add powerful new condition keys, so there’s hope many common use cases will get addressed!
In this post, we reviewed 5 AWS IAM feature requests that could improve the livelihood of developers and security professionals. If you’re on board, vote by sharing them with AWS!