AWS IAM policy language used everywhere:
- to define IAM policy itself
- to define resource-based policy like S3 bucket policy
- to define the most important AWS control - SCP (Service Control Policy)
- to define VPC endpoint policies
Let's take a look at the AWS IAM policy structure:
This policy's vital element is "Action," which is a list of AWS APIs that will be Allowed or Denied by the policy.
Currently, there are several thousands of AWS actions. A list of all of them could be found here.
It's extremely easy to make a typo in the action name when you are creating a policy.
But, AWS will detect and warn you, right?
Nope!
It might come as a surprise even for the experienced cloud engineers, but AWS does not verify API actions spelling.
Proof: https://docs.aws.
Yes, when you are using a policy generator, you can choose from the dropdown list of the available API actions.
But if you are using CLI, Cloudformation, Terraform, or any SDK, your policy will be accepted as long as a policy syntax and grammar will pass (policy grammar, but not action names or resource ARNs )
So what? Not a big deal? If policy not working, you can troubleshoot it using the policy simulator, right, and find a problem?
The challenge is that even an AWS native policy simulator will not check API (action names) spelling. It will show if the desired actions are allowed or blocked but will not point you to the simple typo in your policy.
As long as your policy is for the ALLOW effect, it's not a big deal. You might spend some time troubleshooting and not understanding why access is not granted, but generally, it should be OK, right?
Even in the case of ALLOW, not precisely:
when you are using Infra as a code, you might make a typo in production-related IAM/SCP/etc. policy and cause quite an outage!
What about policies that suppose to protect, a.k.a DENY effect? Implications, in this case, might be quite catastrophic:
- SCP that implements your AWS Account level preventative controls will allow actions that you think you have blocked, making controls not-exiting.
- IAM policy will not protect against destructive or unsafe actions.
- Resource-based policy might become unintentionally too open.
Luckily, AWS has a second layer of protection ( and implicitDeny ) that, up to a certain extent, will compensate for such mistakes: as long as API call (Action name) is not explicitly Allowed, it will be deemed as implicitDeny. This helps and might save your backend, but not in all cases. Moreover, relying on this it's definitely a bad security practice.
What could be a solution to the problem we just discussed?
A process and a tool of the IAM policy validation for the syntax and spelling.
The process is an IAM policy linting that must be done before any deployment or during PR review in your code repo.
As for the tool, it might be home built linting tool (example: extension or rule to the CloudFormation Linter https://github.com/
Note, the tool must be regularly and automatically synced with the latest list of the AWS IAM actions or manually updated to reflect any changes AWS might do to the subj.
