4 ms·

I wish people would speak about this problem more. I can’t tell you how many times I need reiterate certain things with our DevOps team to get the proper permis

by snypox 7y ago

I wish people would speak about this problem more. I can’t tell you how many times I need reiterate certain things with our DevOps team to get the proper permissions because I can’t seem to get it right the first time.

scarface74 7y ago
So you didn’t test it in a dev account first?
- xrd 7y ago
  If the dev account role has different permissions, it doesn't matter. Of course (s)he tested it first in a dev account. The point is the context around roles matters much more than the code that runs inside it, a critical flaw of AWS. Fairly, this problem is definitely not just limited to AWS but I find their implementation particularly poor.
  - scarface74 7y ago
    That’s still the issue. You should have a custom role for each set of lambdas that make up a service. Your role and your lambdas should be in the same CF template that can be deployed together. Security best practices is for the role to have the least amount of privileges the lambda needs. Not just one generic “lambda role”. Whoever is responsible for production deployment could audit the role’s permissions and the definitions would be in source control.
- 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.

by snypox 7y ago

scarface74 7y ago

So you didn’t test it in a dev account first?

xrd 7y ago
If the dev account role has different permissions, it doesn't matter. Of course (s)he tested it first in a dev account. The point is the context around roles matters much more than the code that runs inside it, a critical flaw of AWS. Fairly, this problem is definitely not just limited to AWS but I find their implementation particularly poor.
- scarface74 7y ago
  That’s still the issue. You should have a custom role for each set of lambdas that make up a service. Your role and your lambdas should be in the same CF template that can be deployed together. Security best practices is for the role to have the least amount of privileges the lambda needs. Not just one generic “lambda role”. Whoever is responsible for production deployment could audit the role’s permissions and the definitions would be in source control.
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.