I was a little confused about the Zero Trust model and how Access integrated with vanilla Tunnel. I think I get it now:
The act of creating the Application entry in Cloudflare Access is what puts the entire application behind the Zero Trust model, and without that entry, the site is just publicly tunneled like a normal public website would be. Is that correct?
If so, that doesn’t feel Zero Trust enough to me. For example, if I mistype the subdomain in the Application settings but then create the Tunnel CNAME in DNS correctly, I’ve now just exposed my internal application to the public internet. There is a warning in the Access UI for creating an application if the DNS record doesn’t exist, but that warning is perhaps even harmful because I SHOULD be creating the Application before I create the DNS record to prevent leaking the app.
My intuition, were things to be truly Zero Trust, would be that Access operated at the granularity of the entire zone (or possibly the named tunnel) and leaking an application to the internet would be exceptionally hard if not impossible, instead of a simple typo away. For example, once the zone (or tunnel) is marked as “Access-ified” I would expect DNS entries pointing to my tunnel to be blocked by default. The only way to expose them publicly would be to create an Access rule that explicitly lets public traffic in. (Right now, “Everyone” is a rule you can add, but that means “Everyone that can authenticate” not “Everyone from the unauthenticated public internet”).
What an absolutely amazing set of products by the way. Thank you so much for your excellent work.
One for the root (example.com) and one for the rest of the zone (*.example.com) and then unless you create an explicit policy for a host / path it would be closed by default.
That would work except that I can’t create an access policy of “fully public” as best as I can tell. Once I create the wildcard access policy I can no longer have public websites in my zone.
There is a difference between the allow rule that you are talking about and the bypass action that @cs-cf referred to. If you set the action to bypass, users should not need to login.
Aha, that was exactly what I was missing. That makes sense.
Can you give more details on how to actually accomplish this? When you say “Access policies” you mean applications in Access that have policies, right?
The documentation you linked to lays out what you said but it doesn’t look like I can make an application with a wildcard subdomain like *.example.com in Access:
Sure. Per your original post you want to have a default policy of no deny access unless explicitly allowed for the entire zone. That requires 2 policies as I said previously. Policy management · Cloudflare for Teams documentation
Rule: Allow - set whatever the most restrictive possible zero trust rule you’d allow for each.
For each new ingress rule you create, create a new Application/ Policy to either enforce an explicit zero trust rules appropriate to the app/policy or create a bypass rule for everyone to expose it to the public.
This worked for me despite the warning. In short, create the *.example.com and ignore the warning. I did not create the apex domain policy since I have a page redirect there to a public site that is now behind an explicit application. This is perfect.
I still recommend either making it clear that “Zero Trust” is at the granularity of an application and not the entire zone so no one leaks an application, and explain that you can have zero trust for the whole zone by creating those two Block policies.
Thanks again for all your help and this awesome product.
