no, but why? You can only make bindings in the dash/via wrangler, and if someone has your dash login

no, but why? You can only make bindings in the dash/via wrangler, and if someone has your dash login/credentials they could just remove that restriction

CChaika no, but why? You can only make bindings in the dash/via wrangler, and if someone...

Somepotato•4/8/24, 5:40 PM

Can't you do it via wrangler.toml?

ChaikaOP•4/8/24, 5:40 PM

make a binding? Yea, that'd be via wrangler, they'd need your credentials for that, with such they could just bypass that limitation

Somepotato•4/8/24, 5:41 PM

Also in theory someone could extract a bearer token and use the same token to access another D1 DB.

CChaika make a binding? Yea, that'd be via wrangler, they'd need your credentials for th...

Somepotato•4/8/24, 5:41 PM

The 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.

ChaikaOP•4/8/24, 5:42 PM

if 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

.gwapes•4/8/24, 5:42 PM

With cf workers, you can use like cloudflare’s own database, does this cost? Is there info on costs?

ChaikaOP•4/8/24, 5:42 PM

https://developers.cloudflare.com/d1/platform/pricing/

SSomepotato The file exists in the repo no? So it means having tighter security controls on ...

ChaikaOP•4/8/24, 5:42 PM

I mean you can't scope tokens even to specific workers, so they could simply override your auth worker anyway

Somepotato•4/8/24, 5:43 PM

Guess that could be a place for future improvement, more granular access management for workers and resources in general

Somepotato•4/8/24, 5:43 PM

I'm not hosting any high risk data but it'd be an inhibitor to doing such a thing if I were

SSomepotato Guess that could be a place for future improvement, more granular access managem...

ChaikaOP•4/8/24, 5:43 PM

that's for sure

ChaikaOP•4/8/24, 5:44 PM

I wouldn't start with restricting what workers can bind to things though

Somepotato•4/8/24, 5:44 PM

It'd fail PCI compliance this way though unfortunately

Somepotato•4/8/24, 5:44 PM

Simple role based access would be plenty if you could openly configure what those roles could do

ChaikaOP•4/8/24, 5:45 PM

yea really need worker/pages project granularity

Somepotato•4/8/24, 5:45 PM

Also vital for large scale projects for user permissions too

Somepotato•4/8/24, 5:45 PM

Workers could just piggyback on the same rbac

ChaikaOP•4/8/24, 5:45 PM

hopefully r2 having bucket scoped tokens is just a start of getting those more granular resource-level scopes

Somepotato•4/8/24, 5:46 PM

A terrifying but necessary thought haha

Somepotato•4/8/24, 5:46 PM

And also probably against CF TOS haha

Original message was deleted

ChaikaOP•4/8/24, 5:46 PM

then you'd need workers paid like x100 over

Somepotato•4/8/24, 5:46 PM

For an auth service it wouldn't need to be hit hard

SSomepotato And also probably against CF TOS haha

ChaikaOP•4/8/24, 5:46 PM

nah making extra accounts isn't, I have like 5, just what leo said, can't make them to purposefully evade limits

Somepotato•4/8/24, 5:47 PM

I just want to segregate critical data like user PII

Somepotato•4/8/24, 5:48 PM

I remember when you couldn't even join cf accounts, it wasn't that long ago

ChaikaOP•4/8/24, 5:48 PM

used to have no roles for free accts except superadmin

ChaikaOP•4/8/24, 5:48 PM

got a lot better rbac now

Somepotato•4/8/24, 5:48 PM

It seemed kinda duct taped together

Original message was deleted

Somepotato•4/8/24, 5:48 PM

Encrypting is useless here if you can get the decryption key

Somepotato•4/8/24, 5:48 PM

Eg by taking over the auth worker

Somepotato•4/8/24, 5:49 PM

But if they're on the same account, then you can get to the auth worker

ChaikaOP•4/8/24, 5:49 PM

if you had it as a secret, it'd be slightly harder to dump, couldn't just take over a toml or a different worker

Somepotato•4/8/24, 5:49 PM

In my understanding, the auth workers secrets would be accessible

Somepotato•4/8/24, 5:50 PM

Because the one bearer token could access the worker

ChaikaOP•4/8/24, 5:50 PM

yea to modify the worker code and dump it

ChaikaOP•4/8/24, 5:50 PM

you'd raise the difficult a bit though

ChaikaOP•4/8/24, 5:50 PM

would have to find that other worker on that account, the found secret, and modify the worker to return it

Somepotato•4/8/24, 5:50 PM

Or just pull from whatever the worker is pulling from

ChaikaOP•4/8/24, 5:51 PM

of course possible still if they got a api token to modify workers

Somepotato•4/8/24, 5:51 PM

The bindings, do they use the rest API for the services behind the scenes?

ChaikaOP•4/8/24, 5:51 PM

you mean how they reach stuff internally?

Somepotato•4/8/24, 5:51 PM

Yeah

ChaikaOP•4/8/24, 5:52 PM

they def don't use the normal cf api, they might use different internal apis, but they don't use your normal credentials for them

Somepotato•4/8/24, 5:52 PM

I 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

SSomepotato I wonder what the security is like for that layer, if that layer can access stuf...

ChaikaOP•4/8/24, 5:52 PM

there was a nice blog post recently about that: https://blog.cloudflare.com/workers-environment-live-object-bindings

The Cloudflare Blog

Why Workers environment variables contain live objects

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

ChaikaOP•4/8/24, 5:53 PM

shouldn't be able to reach anything not assigned at all

Somepotato•4/8/24, 5:55 PM

In 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

ChaikaOP•4/8/24, 5:56 PM

and they've got a bunch of protections against that: https://developers.cloudflare.com/workers/reference/security-model/, but yea

CChaika there was a nice blog post recently about that: https://blog.cloudflare.com/work...

Somepotato•4/8/24, 5:56 PM

That also decries giving everything access to everything which is ironic given if you can edit the toml you can also access everythig

ChaikaOP•4/8/24, 5:57 PM

they 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

no, but why? You can only make bindings in the dash/via wrangler, and if someone has your dash login

Similar Threads

Similar Threads

Similar Threads