How to generate an IAM policy from Python code
- Add your codePaste it into the Python (boto3) editor, drag in a file, or keep the sample to see how it works.
- Generate IAM policyClick the button or press Ctrl + Enter. The result streams into the right-hand editor.
- Review and use itCopy or download the result, then test it before you rely on it. AI output is a strong first draft, not a guarantee.
How boto3 calls become IAM actions
Each boto3 client method corresponds to an API operation, and the IAM action is usually the service prefix plus that operation name in PascalCase. table.get_item() needs dynamodb:GetItem, update_item() needs dynamodb:UpdateItem, and sns.publish() needs sns:Publish. The generator reads both client calls (boto3.client) and resource calls (boto3.resource) and turns them into statements grouped by service.
Some methods don't map one-to-one. The list_objects_v2 paginator in the sample needs s3:ListBucket on the bucket ARN (arn:aws:s3:::acme-reports), not on the objects inside it. Managed transfer helpers like upload_file switch to multipart operations for large files. The Service Authorization Reference is the authoritative list of actions and resource types for each service.
Runtime values such as os.environ["ALERTS_TOPIC_ARN"] can't be read from the source, so the policy uses wildcards for them. Replace those with real ARNs, then check the result with IAM Access Analyzer policy validation. If the function already runs in a test account, IAM Access Analyzer policy generation can build a policy from its CloudTrail activity as a cross-check.
boto3's managed transfer methods (upload_file, download_file) use multipart operations for large files. If the generated policy only lists s3:PutObject or s3:GetObject, test with a large file before relying on it.
Tips for better results
- Paste the code that makes the AWS calls. Include the client setup and every function that calls the SDK, so no action is missed.
- Tighten resources after generating. Replace wildcards with the exact bucket, table or queue ARNs, and keep bucket-level and object-level S3 permissions in separate statements.
- Validate before attaching. Run the policy through IAM Access Analyzer policy validation to catch syntax errors, overly broad statements and mismatched resource types.
- Check indirect permissions. Encrypted resources need KMS actions, and handing a role to Lambda or ECS needs
iam:PassRole. Add these by hand if your setup uses them. - Include the Lambda handler and its helpers. Calls made in imported modules aren't visible unless you paste those modules too.
Frequently asked questions
Is the generated IAM policy least-privilege?
It's a least-privilege starting point: it lists only the actions your code calls. Because the tool can't see runtime values, resource paths use wildcards. Replace them with specific ARNs where you can, add conditions, and validate the result with IAM Access Analyzer before you attach it.
Why does the policy use wildcards in resource ARNs?
The generator reads your code, not your AWS account. Bucket names, table names and queue URLs that come from environment variables, configuration or function arguments aren't known, so they appear as wildcards such as arn:aws:s3:::*/*. Swap in the real names before deploying.
Does it catch every permission my code needs?
Not always. It infers actions from the SDK calls it can see. Permissions triggered indirectly, such as kms:Decrypt for encrypted objects, iam:PassRole when you hand a role to another service, or calls made inside other libraries, may be missing. Test with the policy attached and check CloudTrail for AccessDenied errors.
Does it understand boto3 resources and paginators?
Yes. It reads boto3.client calls, boto3.resource objects such as Table and Bucket, and paginators such as get_paginator("list_objects_v2"), and maps each to the underlying IAM action.