IAM Permissions for Developers

Hi Landsamboni,

This is a tough question! Mainly because it depends on the culture and maturity of your organization. Current best practices are to deploy using Infrastructure as Code into accounts from a CI/CD system (IE: GitHub), which has the Admin (or similar) role to make changes, but that can only be used after the CI/CD tool applied all the tests and validations you want for your company. You can find some guidance on the topic here.

If you are currently doing manual deployments, one alternative could be to start by giving them a broad role, but leverage IAM Access Analyzer to analyze the activities they actually use and then scope down the privileges to what they actually need.

Hope this helps!

This is a good question but hard to give a simple answer that would work for all purposes. It doesn't help to try craft complex IAM policies to limit admin permission because when you grant permission to create your own policies, you can also elevate your permissions back to full admin. You could limit your developers to use pre-creations policies (or have some team to act as trusted proxy and create policies for others) but that make them dependented of someone else (and slow down the process) and/or lead to non-optimal (too wide permissions) policies :-( Better solution would be creating separate accounts for each project/team/environment and if necessary use service control policies to limit available services, region etc. This could work, if account creation is automated process and wouldn't cause too much overhead compared to things each team or developer is building.

If you must have multiple teams/developers working on shared account, and want to isolate them, and allow IAM policy creation. IAM permission boundary could do the trick. I've written a blog post and small lab exercise you can try out, to verify if this would fit your needs (see URLs below).

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
• https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
• https://carriagereturn.nl/aws/iam/policy/boundary/2021/10/07/iambound.html
• https://github.com/kallu/learn-cantrill-io-labs/tree/master/aws-iam-walled-garden

I hope you find some of these helpful in finding a solution for your IAM challenges.

You might try PowerUser and then scope down with a custom policy once you have a history of what they actually used.

You can also use boundary policies to create an account as a delegated admin.

Two roles come to mind: developers and installers. There's a lot to say here, however in short, each should ideally have different permissions (i.e.: IAM Policies). So if your developers only need access to S3, EC2, and CloudFormation then limit them to that. Likewise, for CFN deployment, you might want to create a separate role that's specified during the deployment to help protect your account (i.e.: can create S3 but not write to it, or only under certain conditions). So for installing, considering using a CloudFormation Service role per best practice. Work to keep the all policies to a minimum...apply least-privilege permissions per the IAM Best Practices Guide. Also take steps to prevent folks from escalating their permissions as mentioned in this AWS security blog. Also, you might want to consider using a multi-account strategy following the landing zone concepts such as AWS Control Tower, to help managing and track security related items.