Use read-only access for Tunnel log streaming
Log streaming is one of the few private networking jobs that fits read access cleanly. A person looking at Tunnel logs needs to see what the connector is doing, not change where traffic goes, swap config, or open a wider path into the account. If the only job is diagnosis, write access is just extra surface area.
Keep diagnostics separate from tunnel control
A read-only role works best when it is treated as a viewing lane, not a half-way house to admin. Log streaming shows behaviour, failures, and timing. It does not need permission to rewrite policy or edit the Tunnel itself. Mixing those two jobs turns a narrow diagnostic task into an operator role by accident, which is usually how strange access creep begins.
Treat log viewers as observers, not operators
That boundary is more than tidy role design. If a viewer can stream logs from one Tunnel, they can confirm whether the path is healthy without touching the path. If they can also write, the same account can become a change tool by mistake. For private networking, that kind of “harmless” extra access often survives longer than the person who asked for it.
How Cloudflare’s resource-scoped roles narrow the blast radius
Cloudflare’s resource-scoped roles let access sit on individual Tunnel instances and Cloudflare Mesh nodes rather than on the entire account. That is a decent fit for Cloudflare Tunnel granular permissions because the permission follows the object, not the login. One resource can be read-only, another can be writable, and the rest stay out of reach.
Read access also affects what appears in listing endpoints. If a principal only has permission for one Tunnel, they should only see that Tunnel when the API returns resources. That keeps enumeration from becoming a quiet leak of every private networking object in the account.
Read access on one Tunnel without opening the account
A read-only policy on a single Tunnel is useful for diagnostics, audit work, and controlled support access. It lets someone inspect the Tunnel they need without exposing the rest of the private networking estate. For Cloudflare Mesh, the same idea applies, though write access maps to a specific node rather than an account-wide switch.
A single permission policy can target multiple Tunnels and Mesh nodes, which is handy and slightly dangerous in the usual way. The scope still matters more than the count of objects. Three named resources are still three named resources, not a licence to browse the account for sport.
Where account-level Zero Trust roles still override the neat bits
The older account-level Cloudflare Access and Cloudflare Zero Trust roles still carry write access to every Tunnel and Mesh node in the account. Granular permissions sit beside that model, not above it. A principal with either account-level or resource-scoped permission is authorised, so the broader role still wins in practice.
That keeps existing automation and tokens alive, which is sensible, but it also means the tidy new model has an asterisk. If someone already holds an account-level role, the neat resource boundary does not save you. The access check is additive, so the widest valid role still governs what that principal can do.
What to check before you hand this out in production
Do not trust the wording of the policy alone. Check the actual principal, the resource picker, and the endpoint behaviour before anyone starts using it for real work. Access control looks clean in a panel right up until a token with older rights turns up and ruins the mood.
Confirm the principal only sees the Tunnel it needs
Start with the object list. If the principal has read access to one Tunnel, listing should only return that Tunnel and nothing else. Do the same check for Mesh nodes where relevant. If the list is wider than expected, the policy is too loose or an account-level role is still in play.
That check matters because visibility and control are closely linked here. A principal that can see more than it should often has more effective access than the policy text suggests, which is a lovely little trap for production.
Test the log path, not the policy wording
Policy text can look perfect and still do nothing useful. Test whether log streaming actually works for the chosen Tunnel, then test that the same principal cannot write where it should not. The point is to verify the behaviour of the API and the resource filter, not to admire the sentence structure of the permission rule.
For Cloudflare Tunnel granular permissions, the real test is simple: one Tunnel, one role, one observed outcome. If the access leaks beyond that, the account-level role is still standing in the doorway.
