make a binding? Yea, that'd be via wrangler, they'd need your credentials for that, with such they c
make a binding? Yea, that'd be via wrangler, they'd need your credentials for that, with such they could just bypass that limitation
SAlso in theory someone could extract a bearer token and use the same token to access another D1 DB.
SThe file exists in the repo no? So it means having tighter security controls on the auth service DB for instance wouldn't be of value because say an open source component that uses that service could be compromised and access the auth DB.
Cif they have your token, you need D1 scope to even publish a Worker afaik, so it could just be used to access them at all
.With cf workers, you can use like cloudflare’s own database, does this cost? Is there info on costs?
C
CI mean you can't scope tokens even to specific workers, so they could simply override your auth worker anyway
SGuess that could be a place for future improvement, more granular access management for workers and resources in general
SI'm not hosting any high risk data but it'd be an inhibitor to doing such a thing if I were
Cthat's for sure
CI wouldn't start with restricting what workers can bind to things though
SIt'd fail PCI compliance this way though unfortunately
SSimple role based access would be plenty if you could openly configure what those roles could do
Cyea really need worker/pages project granularity
SAlso vital for large scale projects for user permissions too
SWorkers could just piggyback on the same rbac
Chopefully r2 having bucket scoped tokens is just a start of getting those more granular resource-level scopes
SA terrifying but necessary thought haha
SAnd 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
