4 ms·
It's a back and forth. You get excited about building lambda functions and are surprised at how easy they are, and how much autonomy you have as a developer. Th
by xrd 8y ago
It's a back and forth. You get excited about building lambda functions and are surprised at how easy they are, and how much autonomy you have as a developer. Then, you try to deploy them, and realize you have to file 14 tickets to get the correct IAM settings setup for your production function. No one knows all the permissions you need, and the only way to understand is to try one, see if it works, and what other services you need access to. And, it'll kill all sense of autonomy you had a few hours prior.
- snypox 8y agoI 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 8y agoSo you didn’t test it in a dev account first?
- xrd 8y agoIf 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 8y agoThat’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 8y agoI 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 8y agoI 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 8y agoI 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 8y agoThere 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.
- tjpnz 8y agoOur DevOps guy and I spent an afternoon dealing with this. Turns out the AWS Management Console makes it stupidly easy to accidentally overwrite permissions.
- scarface74 8y agoSounds like a process problem. Why don’t you have a CloudFormation template, with the IAM role you need and the lambda function and have it deployed in DEV Account that you hand off to the powers that be?
- twalla 8y agoYou also can have the opposite problem where devs have no oversight and there are wide open security groups and IAM roles shared between like 30 lambdas and changing one thing with one of them causes everything to come toppling down like a house of cards because handing that much autonomy to someone who doesn't fully understand (or care about) the underlying infrastructure is like giving a drunk toddler a bucket of hand grenades.