Cloudflare Access - Wildcards to the right of sub-domains are not effective + need wildcards on the left of the application domain

I have this on my Cloudflare for Teams (Access) policy for a specific application:

It seems that no requests are getting an authentication request to login via GitHub (my only authentication method) and everything is just being let through, for example - to https://staging-go.tallyfy.com

Note that the domains staging-* (a few sub-domains) already exist, and are proxied through Cloudflare.

Why is this?

So it’s worth reviewing the application pathing documentation here:

https://developers.cloudflare.com/cloudflare-one/policies/zero-trust/app-paths#protect-multi-level-paths

The box at the bottom marked Important explains what you are encountering:

Important

You cannot use wildcards to partially match subdomain and path names. Using asterisks in any way other than the ones outlined above will cause the wildcard to be invalidated . This means your application won’t be effective, and neither will be any rules you may try to enforce on it at a later time.

Entry Does NOT cover
example.com/cat-* example.com/cat , example.com/cat-food
*ing.example.com ing.example.com , engineering.example.com

So you’d need to define an application for each subdomain you want to protect - or use *.example.com which would cover any/all subdomains

1 Like

So - this is inconvenient and doesn’t really work in real-life.

I don’t see why a simple wildcard has to have all these restrictions, as most naming conventions use some part of the domain as a top-level indicator e.g.

dev-*.domain.com

Given the fact that sub-sub-level domains have problems e.g. a.b.domain.com - the above seems to be the only way out. I cannot possibly sub-domain everything as *.domain.com in a single rule.

Please look into expanding/fixing this.

1 Like

Thanks for the feedback - would you mind raising a suggestion in Product Requests - Cloudflare Community - others can vote on this and I’ll share it with the product team.

Also can you explain a bit more about the multi-level subdomain issues? What issues are you having using those?

2 Likes

The core problem is that wildcards are highly restricted, and they need to be usable anywhere in a string that expressed either a path or any level of sub-domain. We can’t auto-provision new developers with their own dev environment if we have to manually make new rules for each sub-domain inside Access/Teams, while also reconnecting other parts of our system which are sub-domain-sensitive to the new client URL’s. Our app isn’t just a single URL, it’s various components that rely on endpoints with a predictable schema, ideally under a single sub-domain. As an example - we can’t just restrict *.tallyfy.com without exceptions because these are public URL’s that must be left open:

support.tallyfy.com > our support manual
go.tallyfy.com > our production client UI

I also don’t see any way of declaring exceptions to an overall rule.

There should be no technical reason from the Cloudflare side that you cannot do *.developers.example.com unless I’m missing something - but I understand it might not be ideal depending on your organisation and your own code / infrastructure.

Your feedback makes perfect sense - please do raise something that expresses this in the Product Requests category: Product Requests - Cloudflare Community others can then vote on it and it will help Product decide what to build next.

On your note about exceptions - there is also request in flight already on something similar that you might want to upvote and comment on: Access: Bypass rule by URL

2 Likes

sure - just posted here:

1 Like

Perfect - thankyou - I will be sure to flag these up internally to the Teams… ahem… Team :slight_smile:

1 Like

@simon to illustrate this - see this example. If we have 20 developers - we are not going to add 20 separate applications, if we can just do this (which doesn’t work):

Assuming there is a certificate on Cloudflare’s edge to cover the *.dev.subdomain.example.com this should work just fine.

1 Like

Unfortunately, on the specific rule, for the specific application above, I always get a Cloudflare Access “Forbidden” error when accessing something like this:

https://person.dev.subdomain.tallyfy.com

(person and subdomain are not real as I don’t want to make them public - but illustrate the point)

I also purchased the extra SSL certs for the wildcard under this subdomain, and added those under the section “Edge Certificates”