DEV Community

Discussion on: Infrastructure Access for Feature teams?

Collapse
raphael_jambalos profile image
Raphael Jambalos

For AWS, I think teams should create multiple AWS accounts for each environment (i.e dev, prod, uat) and use AWS Organizations to put all of that into one managed umbrella. After that, dev teams should only have access to dev and uat so they can debug the application. The ops team (or the more senior devs for a DevOps-centric company) are the only ones with access to the prod AWS account.

This way, access is self-contained to the AWS account level. Even at the AWS account level, a lot of things can be done. So for this, we can apply the principle of least priv so we only give access to what AWS services the developer needs to access (nothing more)

Collapse
vinayhegde1990 profile image
Vinay Hegde Author

Thanks for the valuable inputs Raphael, very helpful.

Separating access to dev/UAT & production based on seniority sounds a bit off-track to me as it'd leave junior colleagues with little understanding of prod architecture & issues + become a blocker if none of the seniors are available.

It can also lead to teams starting up resources in dev/UAT & miss on cleaning them up later, creating high bills in AWS/GCP.

What do you think is a good approach to solve this?

Collapse
raphael_jambalos profile image
Raphael Jambalos

Hi Vinay, I do think this multi-account structure can be improved upon by adding tags on resources and giving devs write permissions for those tagged resources.

PRODUCTION

  • Junior Dev: Read only, write access only when applicable
  • Senior Dev: More access

DEV / QA

  • Junior Dev: Write access to resources with the appropriate tags
  • Senior Dev: Full Access, can provision resources

Resource: docs.aws.amazon.com/IAM/latest/Use...

Thread Thread
vinayhegde1990 profile image
Vinay Hegde Author

The suggestion of using tags & the shared documentation certainly helps, thank you Raphael!