AWS Identity and Access Management (IAM) is an important and fundamental part of AWS. You can create IAM policies and service control policies (SCPs) that define the desired level of access to specific AWS services and resources, and then attach the policies to IAM principals (users and roles), groups of users, or to AWS resources. With the fine-grained control that you get with IAM comes the responsibility to use it properly, almost always seeking to establish least privilege access. The IAM tutorials will help you to learn more, and the IAM Access Analyzer will help you to identify resources that are shared with an external entity. We recently launched an update to IAM Access Analyzer that allows you to Validate Access to Your S3 Buckets Before Deploying Permissions Changes.
New Policy Validation
Today I am happy to announce that we are adding policy validation to IAM Access Analyzer. This powerful new feature will help you to construct IAM policies and SCPs that take advantage of time-tested AWS best practices.
Designed for use by developers and security teams, validation takes place before policies are attached to IAM principals. Over 100 checks, each designed to designed to improve your security posture and to help you to simplify policy management at scale, are performed. The findings from each check include detailed information and concrete recommendations.
Validation is accessible from the JSON Policy Editor in the IAM Console, as well as from the command line (
aws accessanalyzer validate-policy) and your own code (
ValidatePolicy). You can use the CLI and API options to perform programmatic validation as part of your CI/CD workflows.
In the IAM Console, policy validation takes place in real-time whenever you create or edit a customer-managed policy, with findings broken down by severity; here are some examples:
Security – Policy elements that are overly permissive, and that may be a security risk. This includes use of iam:PassRole in conjunction with NotResource or with “*” (wildcard) as the resource:
Error – Policy elements that stop the policy from functioning. This includes many types of syntax errors, missing actions, invalid constructs, and so forth:
Warning – Policy elements that don’t conform to AWS best practices, such as references to deprecated global condition keys or invalid users, and the use of ambiguous dates:
Suggestion – Policy elements that are missing, empty, or redundant:
Things to Know
As I noted earlier, we are launching with a set of over 100 checks. We have plans to add more over time, and welcome your suggestions.
In the Amazon spirit of drinking our own Champagne, we routinely validate the Amazon-managed IAM policies and fine-tune them when appropriate. From time to time we mark existing managed policies as deprecated, issue notifications to our customers via email, and make updated replacements available. To learn more about our process, read Deprecated AWS Managed Policies.
As you may know, there are already several open source policy linters available for AWS, including the well-known Parliament from Duo Labs. Our customers told us that these tools are useful, but that they wanted an AWS-native validation feature that was active while they were editing policies. A group of developers on the IAM team responded to this feedback and implemented policy validation from the ground up.
You can use this feature now in all AWS regions at no charge.