And also probably against CF TOS haha
And also probably against CF TOS haha
Cthen you'd need workers paid like x100 over
SFor an auth service it wouldn't need to be hit hard
Cnah making extra accounts isn't, I have like 5, just what leo said, can't make them to purposefully evade limits
SI just want to segregate critical data like user PII
SI remember when you couldn't even join cf accounts, it wasn't that long ago
Cused to have no roles for free accts except superadmin
Cgot a lot better rbac now
SIt seemed kinda duct taped together
SEncrypting is useless here if you can get the decryption key
SEg by taking over the auth worker
SBut if they're on the same account, then you can get to the auth worker
Cif you had it as a secret, it'd be slightly harder to dump, couldn't just take over a toml or a different worker
SIn my understanding, the auth workers secrets would be accessible
SBecause the one bearer token could access the worker
Cyea to modify the worker code and dump it
Cyou'd raise the difficult a bit though
Cwould have to find that other worker on that account, the found secret, and modify the worker to return it
SOr just pull from whatever the worker is pulling from
Cof course possible still if they got a api token to modify workers
SThe bindings, do they use the rest API for the services behind the scenes?
Cyou mean how they reach stuff internally?
SYeah
Cthey def don't use the normal cf api, they might use different internal apis, but they don't use your normal credentials for them
SI wonder what the security is like for that layer, if that layer can access stuff not assigned to it. Sounds like a bountyable thing to dig into
Cthere was a nice blog post recently about that: https://blog.cloudflare.com/workers-environment-live-object-bindings
The Cloudflare Blog
Bindings don't just reduce boilerplate. They are a core design feature of the Workers platform which simultaneously improve developer experience and application security in several ways. Usually these two goals are in opposition to each other, but bindings elegantly solve for both at the same time
Cshouldn't be able to reach anything not assigned at all
SIn theory. But it shares an issue workers have in that they use isolates, and a vm escape or another branch prediction exploit and bad news
Cand they've got a bunch of protections against that: https://developers.cloudflare.com/workers/reference/security-model/, but yea
SThat also decries giving everything access to everything which is ironic given if you can edit the toml you can also access everythig
Cthey don't always get put in a shared process either
Sometimes, though, Cloudflare does decide to schedule a Worker in its own private process. Cloudflare does this if the Worker uses certain features that needs an extra layer of isolation. For example, when a developer uses the devtools debugger to inspect their Worker, Cloudflare runs that Worker in a separate process
SUsing dev tools is a pretty manual process though
SFor PCI and HIPAA compliance they'll have to offer isolation as an option
SThough those measures often a separate process isn't even enough
SSpectre proved a lowly browser could access kernel memory, spooky stuff
SIt'd be neat if you could bind certain columns or tables in R1 to workers as opposed to the whole DB
Cwould be interesting, probably require a fair bit of custom sqlite patches though
SSqlite already supports authorization hooks
SSo less than you'd think
SCloudflares cloudified, distributed sqlite
Cit's D1, not R1 lol
SThese names are...less than great lmao
CR2D1, beep boop
SI can't ever not get them mixed up
CThe D is for "not actually Distributed yet"
SOr Dsqlite
SNext cursed idea, postgresql durable object running via a wasm runtime
CCD1 cheats because they have their own custom saving/storage stuff, and sqlite is embedded into the runtime
SYou could probably deeply compress the wasm
SAlso that emulates x86 and creates an entire networking stack from scratch
