3 ms·

> Or that in order to be able to publish a message to SNS, my IAM policy must have a statement that allows the sns:Publish action on the topic's ARN. Like, sur

> Or that in order to be able to publish a message to SNS, my IAM policy must have a statement that allows the sns:Publish action on the topic's ARN. Like, sure … it's "annoying", in a sense, to need to understand what permissions your program requires. > Can we get rid of it? This is the thesis the article ought to have dug into. It seems innately obvious that there is no removing the need for understanding that your program requires sns:Publish, and then writing an IAM policy to that effect. (Well … short of just removing authorization outright, but good luck convincing the security team that IAM is silly?) AFAICT glacing at the repo, it derives the policy from the code, and proposes that as "PoLP". In a sense … "yes", it's PoLP as to what the code literally requires … but it ignores the number of times an IAM policy has been proposed to me that is trivially not PoLP in what the code should require, and you ask "what do you need these permissions for?" and first round trip is through "well, the code does $thing that requires that permission" and well, okay, but what possibly for? since you tend to know the rough design of the thing being built, and the implementing the design shouldn't require anywhere near as many perms as what are being requested … and then you suss out the bugs in the code for that. S3 is notorious in my book for this: devs will merrily call "GetBucket" on a bucket that by design you know exists, and boto's API encourages this. (And then you have legions of devs who think S3 is slow, and … well, yes, when you make network API calls whose result is entirely discarded!) I've seen "Publish" on a topic requested by the service that's the consumer. The bucket thing about. Requesting a permission against all resources, not a specific one.

baq 3y ago
Let me declare permissions inside the service and not in some completely unrelated cdk repo. OpenBSD pledge style. Yes privileges should be the least necessary but effort to actually declare them should also be the least necessary.
eladbenisrael 3y ago
Elad here (the author). That's a very good point. If a developer decides to use `bucket.list().filter(x => x == myFile)` instead of `bucket.get(myFile)` the result will be fundamentally different both from a security perspective (e.g. `ListObjects` instead of `GetObject` on AWS), but also from a performance perspective (`list` is O(n) but `get` is O(1)). If you think about this is primarily an issue of software engineering quality. The fact that today we are forcing the developer to go their devops team to request these permissions creates an organizational workflow that increases quality. That's why most of the teams I worked at requires code reviews. I believe the right approach is to enable devops teams to put up boundaries and rules that will get enforced downstream (build => deployment => production). This will allow both developers and devops teams to be be more independent but still be in control. Curious what people think about winglang's compiler plugin system as a way to help streamline these boundaries (https://www.winglang.io/docs/tools/compiler-plugins https://www.winglang.io/docs/tools/compiler-plugins).
- gravlaks 3y ago
  In my organization, we teach developers Terraform, and give them a reference Terraform setup (IaC repository) for running their apps in. They also have broad permissions in their own, isolated AWS account. There are some tradeoffs, but one pro is that they don't need to request permissions from a devops teams.
  - deathanatos 3y ago
    We have a similar setup: Terraform, and the repository is open to any eng to make pull requests against. The problem we hit is knowledge: while Terraform is not a huge knowledge hurdle to mount … it is still apparently enough. While good engineers will have no problem picking TF up, … more mediocre ones seem to struggle with it¹. We don't have a "reference", as things are still changing sufficiently that it isn't clear what a reference would be. (I know sometimes people have base VMs or similar, and write TF about that; we run on k8s, so the various teams essentially don't have to worry about the host VM at all — or at least, much.) It all comes back to engineering quality, I fear. ¹with knowledge acquisition itself; TF is not particularly unique here. In fact, I'd argue skills in knowledge acquisition is what separates good engineers from not.
    - gravlaks 3y ago
      > The problem we hit is knowledge: while Terraform is not a huge knowledge hurdle to mount … it is still apparently enough. While good engineers will have no problem picking TF up, … more mediocre ones seem to struggle with it¹. That sounds just like one of our problems too. Some engineers arent really to keen on learning it either. But my platform team spends some time on going on 1-1 sessions where we develop new things together with them (mob programming), which gives us possibility to teach and get insights. That mitigates this problem somewhat.

baq 3y ago

Let me declare permissions inside the service and not in some completely unrelated cdk repo. OpenBSD pledge style. Yes privileges should be the least necessary but effort to actually declare them should also be the least necessary.

eladbenisrael 3y ago

Elad here (the author). That's a very good point. If a developer decides to use `bucket.list().filter(x => x == myFile)` instead of `bucket.get(myFile)` the result will be fundamentally different both from a security perspective (e.g. `ListObjects` instead of `GetObject` on AWS), but also from a performance perspective (`list` is O(n) but `get` is O(1)). If you think about this is primarily an issue of software engineering quality. The fact that today we are forcing the developer to go their devops team to request these permissions creates an organizational workflow that increases quality. That's why most of the teams I worked at requires code reviews. I believe the right approach is to enable devops teams to put up boundaries and rules that will get enforced downstream (build => deployment => production). This will allow both developers and devops teams to be be more independent but still be in control. Curious what people think about winglang's compiler plugin system as a way to help streamline these boundaries (https://www.winglang.io/docs/tools/compiler-plugins https://www.winglang.io/docs/tools/compiler-plugins).

gravlaks 3y ago
In my organization, we teach developers Terraform, and give them a reference Terraform setup (IaC repository) for running their apps in. They also have broad permissions in their own, isolated AWS account. There are some tradeoffs, but one pro is that they don't need to request permissions from a devops teams.
- deathanatos 3y ago
  We have a similar setup: Terraform, and the repository is open to any eng to make pull requests against. The problem we hit is knowledge: while Terraform is not a huge knowledge hurdle to mount … it is still apparently enough. While good engineers will have no problem picking TF up, … more mediocre ones seem to struggle with it¹. We don't have a "reference", as things are still changing sufficiently that it isn't clear what a reference would be. (I know sometimes people have base VMs or similar, and write TF about that; we run on k8s, so the various teams essentially don't have to worry about the host VM at all — or at least, much.) It all comes back to engineering quality, I fear. ¹with knowledge acquisition itself; TF is not particularly unique here. In fact, I'd argue skills in knowledge acquisition is what separates good engineers from not.
  - gravlaks 3y ago
    > The problem we hit is knowledge: while Terraform is not a huge knowledge hurdle to mount … it is still apparently enough. While good engineers will have no problem picking TF up, … more mediocre ones seem to struggle with it¹. That sounds just like one of our problems too. Some engineers arent really to keen on learning it either. But my platform team spends some time on going on 1-1 sessions where we develop new things together with them (mob programming), which gives us possibility to teach and get insights. That mitigates this problem somewhat.