4 ms·

I work in a strict environment where the IAM role is not getting deployed with the app. Developers don't have permission to add/modify IAM roles at all. A diffe

by snypox 7y ago

I work in a strict environment where the IAM role is not getting deployed with the app. Developers don't have permission to add/modify IAM roles at all. A different team is handling IAM.

scarface74 7y ago
I understand that, why wouldn’t the team that handles approving IAM also be approving deploying the app? I’m not saying developers should be willy nilly deploying IAM permissions. I’m saying that having one IAM role that is used by all lambdas is the opposite of a strict environment. The IAM role should be deployed and approved with the resources that need it.
- snypox 7y ago
  I agree. I still think the whole IAM role thingy could be very tricky. For instance you need a specific role to be able to run your Lambda in a VPC. Let's be honest, it's not extremely obvious when you're new to AWS.
  - scarface74 7y ago
    There is always a trade off between security and ease of use. Especially if you want to enforce the concept of least privilege - which you should be doing in a “strict environment”. If you have one role that has any permission that any lambda might need, your entire organization is doing nothing more than security theatre. If you want ease of use, give all of your roles Admin rights. Is that a good idea? Of course not. But it would also not be a good idea for AWS not to by default deny everything and leave it up to the implementation to decide the level of permissions. Also, if roles and permissions aren’t the same between the dev and production account, someone must be going in and manually changing permissions either in dev, prod or both. A “strict” environment would have an automated, auditable process to change roles through a pipeline using cloud formation templates that first deployed changes to dev and then after the right approvals through to production.

4 ms·

I work in a strict environment where the IAM role is not getting deployed with the app. Developers don't have permission to add/modify IAM roles at all. A diffe

by snypox 7y ago

I work in a strict environment where the IAM role is not getting deployed with the app. Developers don't have permission to add/modify IAM roles at all. A different team is handling IAM.

scarface74 7y ago
I understand that, why wouldn’t the team that handles approving IAM also be approving deploying the app? I’m not saying developers should be willy nilly deploying IAM permissions. I’m saying that having one IAM role that is used by all lambdas is the opposite of a strict environment. The IAM role should be deployed and approved with the resources that need it.
- snypox 7y ago
  I agree. I still think the whole IAM role thingy could be very tricky. For instance you need a specific role to be able to run your Lambda in a VPC. Let's be honest, it's not extremely obvious when you're new to AWS.
  - scarface74 7y ago
    There is always a trade off between security and ease of use. Especially if you want to enforce the concept of least privilege - which you should be doing in a “strict environment”. If you have one role that has any permission that any lambda might need, your entire organization is doing nothing more than security theatre. If you want ease of use, give all of your roles Admin rights. Is that a good idea? Of course not. But it would also not be a good idea for AWS not to by default deny everything and leave it up to the implementation to decide the level of permissions. Also, if roles and permissions aren’t the same between the dev and production account, someone must be going in and manually changing permissions either in dev, prod or both. A “strict” environment would have an automated, auditable process to change roles through a pipeline using cloud formation templates that first deployed changes to dev and then after the right approvals through to production.