Cloudflare Access First Impressions

Last week we had a trial of Cloudflare for Teams via account management teams (the company I work for is an Enterprise customer).

While work weren’t really interested at the moment, it’s come in really handy for a personal project, so I’ve been giving it a try and first impressions were mixed:

  • Setting things up in the WebUI were fairly easy (GREAT)
  • Configuring a tunnel from a Linux machine and assigning it a subdomain was easy (GREAT)
  • When all configured, on visiting the subdomain, you get a redirect loop after logging in (NOT SO GREAT)
  • The semi-default policy (ALLOW, an email address, type “Include”) didn’t work as expected (REALLY SCARILY BAD).

So let me explain that last one:

I’ve configured “Google” authentication (not G Suite / Workspace, just standard Google authentication for Gmail accounts).

I then created an allow rule in the policy section, based on what was being suggested in the Wizard, as above (ALLOW, an email address, type “Include”)… My expectation (based on how Google’s zero-trust IAP works on GCP) was that this would allow that single email and by default, block everyone else.

This last assumption was wrong and boy am I glad I checked it to make sure!

It allowed anyone to sign in with a Google account & access my sensitive application… Now I have zero-trust in both the platform & myself, great :).

FYI you have to create that allow rule, than a “DENY” rule for “Everybody” below it, to have that effect, which really isn’t what I’d have expected at all.

Between this & the redirect loop, it’s still ok for a free product, but I certainly won’t be pushing my company towards it instead of GCP’s alternative, as unless I’m really missing something obvious, I don’t have a lot of confidence that is has been thoroughly thought through or tested.


The default behavior of an Access rule where one exists it to deny all requests that do not match. A rule which has an allow for [email protected] will deny any non matching email address attempt to log in by default. .

It is possible to configure a rule incorrectly or too broadly or incorrectly and have unintended users able to authenticate.

That’s not the case. I’m not sure what was configured incorrectly with regards to your initial rule, but once an Access policy exists, it’s not a default allow everyone.

Without knowing more about the application and error, I don’t think this is Access related specifically.

Access is a > 4 year old product used by a large number of organizations. Sorry you appear to have had some issues in the configuration of the product and it may not be an appropriate solution for your organization’s use case (great thing is there are lots of tools/ solutions in the marketplace).

1 Like

Thanks for the response, appreciate you taking the time to look!

My rule matched your screenshot (albeit with my own email listed), so I’m really not sure what went wrong.

I’ll do some more testing when I get time and see if I can replicate it.

1 Like

Think I’ve spotted it, had an “additional rule” as part of the main rule, configured for “Login Methods” = “Google”:

I assumed this meant the user had to match the email & be logging in via Google, turns out it meant it can be an email match or anyone logging in via “Google”, oops…

Redirect loop also looks like this, until Chrome refuses to display the page.

Occasionally you get a Cloudflare Access branded 500 page.

Weirdly if you remove all the path & query string from the URL and try again once it starts redirecting, you can then access the app fine, so the login session has been successful.

Yes, technically you control login methods allowed on another tab. It can indeed be confusing if you’re not familiar with the permissions model (have heard this feedback, other design models have similar potential challenges… right long term answer… TBD).

I’d file a support ticket with a HAR file attached (perhaps on your ENT account). Not 100% what is happening here, haven’t seen this behavior before so I suspect it is something weird in the underlying calls that would be exposed in a HAR). Maybe a page rule or one of the backed out URLs looks the same, but isn’t because… subtle weirdness/ bug.

Would love to have CF Access with a policy simulator/tester similar to AWS IAM one Testing IAM policies with the IAM policy simulator - AWS Identity and Access Management :slight_smile:

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.