4 ms·

> I don’t think Cloudflare workers, as deployed by Cloudflare, really tick that box either. They mostly do. You can map different Workers to different paths in

> I don’t think Cloudflare workers, as deployed by Cloudflare, really tick that box either. They mostly do. You can map different Workers to different paths in your site. A Worker can only access the resources it is explicitly bound to. E.g. if you create a KV namespace for storage, a worker can only access that namespace if you configure it with a "binding" (a capability in an environment variable) pointing at the KV namespace. Workers on your account without the binding cannot access the KV namespace at all. Some more on the philosophy in this blog post: https://blog.cloudflare.com/workers-environment-live-object-bindings/ https://blog.cloudflare.com/workers-environment-live-object-... There are a couple of caveats that exist for legacy reasons, but that I'd like to fix, eventually: * The HTTP cache is zone-scoped. Two workers running on the same zone (domain name) can poison each others' cache via the Cache API. TBH I want to rip out the whole Cache API and replace it with something entirely different, it is a bit of a mess (partly the spec's fault, partly our implementation's fault). * Origin servers are also zone-scoped. All workers running on a zone are able to send requests directly to the zone's origin server (without going back through Cloudflare's security checks). We're working on introducing an "origin binding" instead, and creating a compat flag that forces `fetch()` to always go back to the "front door" even when fetching from the same zone. Note that if you want to safely run code from third parties that could be outright malicious, you can use Workers for Platforms: https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/ https://developers.cloudflare.com/cloudflare-for-platforms/w... (I'm the tech lead of Cloudflare Workers.) (EDIT: lol wrote this without reading your username. Hi, Andy!)

amluto 2y ago
The worker binding system seems pretty great. I'm thinking more about the configuration / deployment mechanism. In the old days, if I wanted to deploy a little script (on scripts.myuniversity.edu, for example), I would stick the file in an appropriate location (~username/cgi-bin, for example), and the scripts would appear (be routed, in modern parlance, but the route was entirely pre-determined) at a given URL, and they could access a certain set of paths (actually, anything that was configured appropriately via the AFS permission system). Notably, no interaction was needed between me and the actual administrator of scripts.myuniversity.edu, nor could my script do anything outside of what AFS let it do (and whatever the almost-certainly-leaky sandbox it ran in allowed by accident). But Cloudflare has a fancy web UI [0], and it is 100% unclear that there's even a place in the UI (or the command-line API) where something like "the user survey team gets to install workers that are accessible at www.site.com/surveys and those workers may be bound to resources that are set up by the sane team" would fit. And reading the "role" docs: https://developers.cloudflare.com/fundamentals/setup/manage-members/roles/ https://developers.cloudflare.com/fundamentals/setup/manage-... does not inspire confidence that it's even possible to pull this off right now. This kind of thing is a hard problem to solve. A nice textual config language like the worker binding system (as I understand it) or, say, the Tailscale ACL system, is nice in that a single person can see it, version it, change it, search-and-replace it, ask an LLM about it, etc. But it starts to get gnarly when the goal is to delegate partial authority in a clean way. Not that monstrosities like IAM or whatever Google calls their system are much better in that regard. [1] [0] Which I utterly and completely despise, but that's another story. Cloudflare, Apple, and Microsoft should all share some drinks and tell stories of how their nonsense control panels evolved over time and never quite got fixed. At least MS has somewhat of an excuse in that their control panels are really quite old compared to the others. [1] In the specific case of Google, which I have recently used and disliked, it's Really Really Fun to try to grant a fine-grained permission to, say, a service account. As far as I can tell, the docs for the command line are awful, and the UI kind-of-sort-of works but involves a step where you have to create a role and then wait, and wait, and wait, and wait, and maybe the UI actually notices that the role exists at some point. Thanks, Google. This is, of course, a nonstarter if one is delegating the ability to do something useful like create two resources and link them to each other without being able to see other resources. (Hi Kenton!)
- kentonv 2y ago
  So, two possibilities: 1. If you have a relatively small number of users whom you want to permit to deploy stuff on parts of a Cloudflare account, you may need to wait for finer-grained RBAC controls to be fleshed out more. It's being worked on. I really hope it doesn't end up as hopelessly confusing as it is on every other cloud provider. 2. If you have a HUGE number of users who should be able to deploy stuff (like, all the students at a university), you probably want to build something on Workers for Platforms. You can offer your own completely separate UI/API for deploying things such that your users never have to know Cloudflare is involved (other than that their code is written in the style of a Cloudflare Worker).
  - amluto 2y ago
    Workers for Platforms looks pretty neat, and I hadn’t seen it before. I don’t think it’s targeted at the low-effort CGI-like little bit of script on an otherwise mostly static site market, though. But maybe someone could build that on top of it? Heck, one could probably even build middleware to deploy regular workers for this type of use, where the owner of the worker has no Cloudflare credentials at all and only interacts with the middleware. (Other than the origin and cache API issues.)
    - kentonv 2y ago
      Right, that's exactly the idea. You could build your own CGI-like hosting platform using WfP to run untrusted JavaScript. To be clear the two caveats don't apply to WfP. The cache API is disabled there. The origin thing can be solved by installing an "outbound worker", which intercepts all outbound requests from the untrusted workers and so can block unwanted requests to origin.

amluto 2y ago

The worker binding system seems pretty great. I'm thinking more about the configuration / deployment mechanism. In the old days, if I wanted to deploy a little script (on scripts.myuniversity.edu, for example), I would stick the file in an appropriate location (~username/cgi-bin, for example), and the scripts would appear (be routed, in modern parlance, but the route was entirely pre-determined) at a given URL, and they could access a certain set of paths (actually, anything that was configured appropriately via the AFS permission system). Notably, no interaction was needed between me and the actual administrator of scripts.myuniversity.edu, nor could my script do anything outside of what AFS let it do (and whatever the almost-certainly-leaky sandbox it ran in allowed by accident). But Cloudflare has a fancy web UI [0], and it is 100% unclear that there's even a place in the UI (or the command-line API) where something like "the user survey team gets to install workers that are accessible at www.site.com/surveys and those workers may be bound to resources that are set up by the sane team" would fit. And reading the "role" docs: https://developers.cloudflare.com/fundamentals/setup/manage-members/roles/ https://developers.cloudflare.com/fundamentals/setup/manage-... does not inspire confidence that it's even possible to pull this off right now. This kind of thing is a hard problem to solve. A nice textual config language like the worker binding system (as I understand it) or, say, the Tailscale ACL system, is nice in that a single person can see it, version it, change it, search-and-replace it, ask an LLM about it, etc. But it starts to get gnarly when the goal is to delegate partial authority in a clean way. Not that monstrosities like IAM or whatever Google calls their system are much better in that regard. [1] [0] Which I utterly and completely despise, but that's another story. Cloudflare, Apple, and Microsoft should all share some drinks and tell stories of how their nonsense control panels evolved over time and never quite got fixed. At least MS has somewhat of an excuse in that their control panels are really quite old compared to the others. [1] In the specific case of Google, which I have recently used and disliked, it's Really Really Fun to try to grant a fine-grained permission to, say, a service account. As far as I can tell, the docs for the command line are awful, and the UI kind-of-sort-of works but involves a step where you have to create a role and then wait, and wait, and wait, and wait, and maybe the UI actually notices that the role exists at some point. Thanks, Google. This is, of course, a nonstarter if one is delegating the ability to do something useful like create two resources and link them to each other without being able to see other resources. (Hi Kenton!)

kentonv 2y ago
So, two possibilities: 1. If you have a relatively small number of users whom you want to permit to deploy stuff on parts of a Cloudflare account, you may need to wait for finer-grained RBAC controls to be fleshed out more. It's being worked on. I really hope it doesn't end up as hopelessly confusing as it is on every other cloud provider. 2. If you have a HUGE number of users who should be able to deploy stuff (like, all the students at a university), you probably want to build something on Workers for Platforms. You can offer your own completely separate UI/API for deploying things such that your users never have to know Cloudflare is involved (other than that their code is written in the style of a Cloudflare Worker).
- amluto 2y ago
  Workers for Platforms looks pretty neat, and I hadn’t seen it before. I don’t think it’s targeted at the low-effort CGI-like little bit of script on an otherwise mostly static site market, though. But maybe someone could build that on top of it? Heck, one could probably even build middleware to deploy regular workers for this type of use, where the owner of the worker has no Cloudflare credentials at all and only interacts with the middleware. (Other than the origin and cache API issues.)
  - kentonv 2y ago
    Right, that's exactly the idea. You could build your own CGI-like hosting platform using WfP to run untrusted JavaScript. To be clear the two caveats don't apply to WfP. The cache API is disabled there. The origin thing can be solved by installing an "outbound worker", which intercepts all outbound requests from the untrusted workers and so can block unwanted requests to origin.