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)
Senior DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
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?
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 DevOps Engineer with 8.5+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
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)
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?
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
DEV / QA
Resource: docs.aws.amazon.com/IAM/latest/Use...
The suggestion of using tags & the shared documentation certainly helps, thank you Raphael!