AWS Access Analyzer Policy Generator analyzes an IAM user or role’s CloudTrail history and creates a least privilege IAM policy with only the actions that are in use (announcement). This policy generator looks like a great building block for minimizing AWS privileges within continuous delivery processes because it is available via native AWS APIs.

How the policy generator works

The policy generator operates similarly to several free and commercial tools:

  • Analyze CloudTrail audit logs to determine which API actions principals called recently
  • Generate an IAM identity policy allowing only the API actions in-use

They’ve taken a proven practice and codified policy minimization as a service.

This service has a few important differences from other tools:

  1. The service is available in your AWS account today with no additional software deployment or direct costs.
  2. The policy is generated by AWS’s provable security technology and supports templating for further restriction.
  3. Policy generation and retrieval services are available via APIs and are composable into automation workflows.

As with many new AWS feature launches, Policy Generator focuses on key security use cases and has conservative limits. In particular:

  • capability available via AWS console, CLI, API, and some SDKs
  • covers 16 AWS services
  • access analyzer default limits are tight:
    • one concurrent policy generation
    • 5 generated policies per day, including cancelled requests

The user guide calls out several important things you should know about generating policies:

Things the Access Analyzer team wants you to know about policy generation

Importantly, the CloudTrail trail must be in the same account as the identity being analyzed. Organization trails not supported yet.

AWS Access Analyzer Policy Generator’s capabilities and limits will surely grow over time. But it’s a compelling building block right now.

Minimize security policies continuously

Most importantly, this policy generation capability is all available via AWS APIs. This simplifies integrating this important capability into your continuous delivery & security processes.

The policy analysis and generation APIs are already available in the AWS CLI and some AWS SDKs. We can start building a better policy improvement process (incl Python boto3, Go sdk-for-go) today.

We think the biggest outstanding challenge to solve is how to help engineers understand and integrate the proposed policy into continuous delivery workflows safely.

We’re starting with these questions:

Q. How should engineers be prompted an to review an improved policy or privileges that are no longer needed?

Integrate with natural points in the development and review process. Perhaps:

  • a bot that notifies a chat channel with a pointer to a policy diff
  • suggested or automatic minimization when executing terraform plan or cdk synth

Q. How should we manage the policy generation concurrency & throughput limit and analysis latency?

Results need to be available on-demand, not 6 hours later. Consider spreading analysis load over a week or month during non-working hours. Prioritize identities within an account by risk starting with e.g., principals that can administer IAM.  This enables both bulk cleanup and continuous security policy engineering. Analysis results are probably cacheable, and invalidated on policy changes.

Q. How should API actions that aren’t logged in CloudTrail be handled?

Unlogged API actions are a known problem, even for security-critical actions like iam:PassRole. Fortunately, the list of unlogged API actions is known so we can support engineers with information during the review process. The unlogged API action case could be solved the same way as to the ‘new action’ case. In the new action case, an engineer needs to allow access to a previously minimized principal so that they can develop a new feature. Both cases could be solved by configuring an allowed action list on that principal’s policy infrastructure code.

Q. How should APIs not covered by the Policy Generator be handled?

The Policy Generator currently covers 16 AWS services. There are many notable gaps such as DynamoDB and SQS. We’d expect this coverage to expand, but will need to merge the generated and current policies somehow. Perhaps it’s good enough to minimize a service at a time.

We’ll dive into these questions next week as we start building policy minimization into continuous delivery workflows using Terraform or CDK.

Work with us!

If you want to minimize privileges within your continuous delivery pipeline, we’d love to work with you to develop a solution built on AWS Access Analyzer Policy Generator.

Contact us and we’ll discuss the specific problems you’re trying to solve and get going!