How to generate an IAM policy from Go code
- Add your codePaste it into the Go (AWS SDK for Go) 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 Go SDK calls become IAM actions
In the AWS SDK for Go v2, each client method is named after the API operation it calls, so the IAM mapping is usually direct: ReceiveMessage needs sqs:ReceiveMessage, DeleteMessage needs sqs:DeleteMessage, and PutObject needs s3:PutObject. The generator finds the clients created with NewFromConfig and the methods called on them, and groups the actions into statements by service.
Watch for operations whose permissions differ from their names. Listing objects with ListObjectsV2 needs s3:ListBucket on the bucket ARN. Writing to a bucket encrypted with a customer-managed KMS key also needs kms:GenerateDataKey, and code that hands a role to Lambda or ECS needs iam:PassRole. The Service Authorization Reference documents the exact actions, resource types and condition keys for every service.
Resource names that come from flags, environment variables or config files aren't visible in the source, so the policy uses wildcards for them. Fill in the real ARNs, then validate with IAM Access Analyzer policy validation. IAM Access Analyzer policy generation can also build a policy from the role's recorded CloudTrail activity, which is a useful cross-check for long-running services.
The sample uses the AWS SDK for Go v2 (github.com/aws/aws-sdk-go-v2). Code written for the older v1 SDK calls the same API operations, so the IAM actions are identical.
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. - Paste the whole package if calls are spread out. Methods on helper structs that wrap SDK clients are only visible if their code is included.
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.
Which Go SDK versions does it support?
The sample and examples use the AWS SDK for Go v2, where clients are created with NewFromConfig. Code using the older v1 SDK calls the same API operations, so it maps to the same IAM actions.