AWS IAM in a layman's terms (3) -- IAM policy setup to give development team maximal velocity and autonomy
syang.substack.com
We alluded in one of our previous post that the development team will own a lot of responsibility defining application related resource access control, simply because the dev team owns the infrastructure as code (IaC) responsibility themselves. No matter how well security savvy and security-educated a development team is, the central security team still needs some control, some kind of “trust but verify”. In this post, we briefly talk about leveraging the right type of AWS IAM policy mechanisms to build the responsibility separation between the “central” team and the individual “development” team. Here central and individual are relative: it can be the official central official IT security team vs. individual product line; and it can be the official DevSecOp platform team vs. individual
AWS IAM in a layman's terms (3) -- IAM policy setup to give development team maximal velocity and autonomy
AWS IAM in a layman's terms (3) -- IAM policy…
AWS IAM in a layman's terms (3) -- IAM policy setup to give development team maximal velocity and autonomy
We alluded in one of our previous post that the development team will own a lot of responsibility defining application related resource access control, simply because the dev team owns the infrastructure as code (IaC) responsibility themselves. No matter how well security savvy and security-educated a development team is, the central security team still needs some control, some kind of “trust but verify”. In this post, we briefly talk about leveraging the right type of AWS IAM policy mechanisms to build the responsibility separation between the “central” team and the individual “development” team. Here central and individual are relative: it can be the official central official IT security team vs. individual product line; and it can be the official DevSecOp platform team vs. individual