ORIGINAL REDDIT POST
IAM Permissions
Hello! I am a student learning IaC. So far it's going ok, but it's time consuming applying the right AWS IAM permissions to my jenkins runner. I start the pipeline, wait for it to fail with a 403, then manually add the missing permission to the policy. Is…
Hello! I am a student learning IaC. So far it's going ok, but it's time consuming applying the right AWS IAM permissions to my jenkins runner. I start the pipeline, wait for it to fail with a 403, then manually add the missing permission to the policy. Is there a command or tool I can use to just list all the permissions it needs? Using OpenTofu but it looks like there isn't too much difference between that and Terraform, the process should be similar at least. Thanks!
Collected discussion
There are a ton of options here, Pike is a classic: https://github.com/JamesWoolfenden/pike but realistically if you run Terraform you should be assuming a role and that role should have all the permissions you will need assigned to it. So if you expect to manage VPCs and S3 and RDS for example, assign the full access policies for those. Technically you could segregate them out (i.e. you can manage buckets but not read objects) but realistically, the role terraform uses and the role an owner users should have the same access anyway in most orgs. There is a small band of size in the middle where you'd not be big enough to delegate complete AWS accounts but not small enough to share one, and that's where you get a lot of IAM boxing, but that doesn't apply here.
I think this is the winner. I'm going to run pike before I push, merge the permissions it generates with the current permissions in IAM, then push and run the pipeline.
The other way not mentioned is granting excessive permissions and then locking it down after a day by using AWS IAM Analyzer but requires CloudTrail.
I would avoid making the Jenkins role learn permissions by failing in the real pipeline. That tends to leave you with a policy nobody trusts and no clear record of why each action is there. A safer pattern is: run plan/apply in a disposable or low-risk account first, capture the CloudTrail events, generate a candidate policy from Access Analyzer, then review it against the resources your Terraform actually owns. Keep separate roles for plan and apply if you can: plan often needs broad read access, while apply needs write access only for the modules/accounts it is allowed to change. Also include the Terraform backend in the review. State bucket/table permissions, lock access, KMS, assume-role, and provider data-source reads are easy to miss if you only look at the resources being created. Once it works, treat the policy as code and require PR review for any expansion instead of patching it live after each 403.
Sic Claude or something at your codebase and ask what IAM privileges are needed. .
Try to read real tech docs instead blindly trust AI agent https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html https://aws.amazon.com/blogs/security/enable-external-pipeline-deployments-to-aws-cloud-by-using-iam-roles-anywhere/
Before AI it was the biggest pain in using terraform. Like others said, just vibe it out