Protect Worker with Zero Trust
How can I protect a worker with zero trust?
Service tokens provide a client ID and secret, but unless we go over the zero trust fabric, they’re not automagically converted to a JWT.
I’ve got code that can validate a JWT, that isn’t a problem; but how to I get the JWT from the ID and secret?
16 Replies
Strictly speaking, you don't. The JWT doesn't come frrom the ID/Secret. Access manages public/private keys for your team and signs JWTs when a request passes through Access. The Service Token is just a "password" you send to Access for it to validate you.
but unless we go over the zero trust fabricWhy not? Use Service Tokens and a "Service auth" action in a policy, in front of your Worker, and Access will issue you a jwt for passing it like normal
Will that work for workers on workers.dev, or will it need a custom domain for that policy to work?
Custom domain, and you'd create a self-hosted Access Application, with a policy containing Service Auth Action / include: Service Token
Cool. That makes sense. Thank you.
I’ve often wondered how Access policies get in front of my domain, is this done automagically? Does it add page rules? Should I not care? 😀
It's just done by creating the self-hosted Access Application,
When you create one you specify the application domain, with a specific subdomain/domain/path
Oh. Yeah. I know that part.
Part of the request flow for proxied request is checking those
ah ok, well then yea it's just automagical then lol
Ahh
I hadn’t seen that request flow before
That really helps
It's on the right side of certain pages like the WAF if your screen has enough width
Because in my head the worker with the custom route and the access setup are two completely separate things.
But if every request has this flow, I get it
Super helpful. Thank you
Hey @chaika.me, I'm using a service binding and including the headers cf-access-client-id and cf-access-client-secret, but they're not converted to a JWT.
Do service bindings also use this same request flow?
I'm using a service binding because of this bug:
https://github.com/cloudflare/workerd/issues/787
GitHub
🐛 BUG: Worker <-> Worker request over
custom_domain returns insta...Which Cloudflare product(s) does this pertain to? Workers/Other What version of Wrangler are you using? 2.9.0 What operating system are you using? Mac Describe the Bug Same zone worker <-> wo...
The request immediately invokes the downstream Worker, reducing latency as compared to a request to a third-party service. You can invoke other Workers directly from your code. This makes it possible to communicate with shared services managed by other teams with differing test and release processes. Those services do not need to be hooked up to publicly accessible endpoints. Service bindings facilitate private services to communicate with one another.I'm assuming not 😦
If you're trying to verify a worker to worker via service bindings request:
If you can, disable all triggers for the Service Bound Worker (so nothing else can invocate it), and you can pass a special property in request.cf (Service Bindings don't modify request.cf, they just pass it through), like request.cf.MySecret and then just check for it to exist/to be a certain value, and you'd know you are calling it securely from another worker.
Or you could do something more standard and just add a custom header "My-Secret" and verify it on the other end
Thanks
When in doubt, try and change the other project 🙂
https://github.com/hashicorp/terraform/pull/33520
GitHub
feat: allow custom headers for http backend by rawkode · Pull Reque...
This change makes it possible to add arbitrary HTTP headers when using the HTTP backend.
This makes it possible to use Cloudflare Workers as a state backend, which can be protected via Cloudflare Z...