Additional Criteria options - Policy structure · Cloudflare Access docs

Feedback Product Requests
#1

Hi,

Cloudflare Access is a great product, however, it does lack some features which, once it’s there, it’ll open up a wider range of possibilities (and unlock some of the hurdles that I’m facing in adopting it).

Based on the knowledge that Cloudflare Access runs on Cloudflare Workers…

Needs additional criteria options

  1. Relative URL (this would avoid the need to create multiple ‘applications’ just to exclude some paths within an app) See: related issue
  2. URL Params
  3. Request Method
  4. HTTP Headers
  5. Cookies
  6. Form Data (with/out Regex) at the rules level, than having to create multiple ‘Applications’

Option to have JS functions to validate the criteria

For now, it’s mostly just, ‘criteria equals’ or ‘in criteria’. We should be able to use some safe JavaScript functions to validate each criteria. Like RegEx match.

If this then that (additional actions)

The rules seem to be essentially a set of ‘if statements’, so, in addition to the Allow/Block/Bypass options, there should be an additional set within the rule that allows for adding/modifying the request, like adding a cookie or header.

dataUri for logo_url

Needless to explain… This will be very useful! :wink:

Many thanks! Great work team, keep it up!

#2

Sorry can you provide some specific use cases you’d like to support and an explanation of why you’d prefer Access for those use cases vs a FW rule for example? While I think I could envision a scenario or two I’d hate to presuppose a use case.

#3

Apologies, if this is a novice question: Would a firewall rule feature bypassing Cloudflare Access login page?

#4

As for this… It avoid the “Chicken and egg conundrum”, whereby, the logo file is sometimes located within the domain that Cloudflare Access is authenticating for, so users won’t have access to the logo file until they authenticate (so, they won’t see it in the login page)! :slightly_smiling_face:

#5

Without understanding your use case I can’t comment. Lots of options today and more we are considering, that is why I’m trying to understand your specific use case to see if it maps to something we have solved or are considering solutions for.

#6

Cloudflare Access offer a bypass option which I believe would resolve that type of issue: https://developers.cloudflare.com/access/common-access-configurations/common-bypass

#7

Thanks for looking into this @cscharff

Apologies for the delay in response, it’s been quite hectic out here.

So, to elaborate on the use case, I’ll take the ‘Relative URL’ criteria as an example here, please share your thoughts and I’ll try to give similar example/use cases for the other requested criteria as well.

Relative URL Criteria

Let’s take your suggestion as an example:

  1. Eg Scenario 1: The whole sub/domain is behind Cloudflare Access, a new application would’ve to be created just to implement a single bypass rule on an image, imagine that for each asset (the wildcards could be made use of in some scenarios).
  2. Eg Scenario 2: Implementing Cloudflare Access to protect and restric access to key areas of WordPress on a public WP Site. An application would’ve to be created for /wp-admin, another one for /wp-login.php and potentially another one for /MySecretAdminAccessURL (as many WP sites have implemented), just for the sake of protecting the login areas.
    For the sake of thoroughness (required for security), we would’ve to put wp api endpoints behind Cloudflare Access as well.

From the Admin perspective: So, just for restricting access to key areas of one WP Site/Installation, a minimum of 3 different applications would’ve to be created and configured separately (without the bypass rules for assets). This would end up causing drift in configurations and make it harder to manage.
From the users’ perspective: Users will see all of these ‘applications’ in the https://test.cloudflareaccess.com app launcher, which would be a little messy.

In scenario 2 above, I guess it’s just a matter of deploying the same Cloudflare Worker for multiple routes? (since Cloudflare Access is running as a CF Worker).

Side note: I've actually had to create 6 different applications just to put 5 URL bypasses inplace! And it made the App Launcher look quite untidy, let alone the CF Teams Console.

Rethinking the CFA Architecture (Application level)

On a related note: Whilst thinking about this from an architeture perspective, it might be better to have the rules/rulesets independent of the application, so that a ‘ruleset’ could be deployed across multiple actual applications (not just URLs), and amended centrally without having to go to each application whenever a change has to be made to the rules.

Afterall, I guess, CFA does make use of KVs here. So, it might even help make the KV size smaller overall, when a common ruleset is used across multiple applications.

#8

after all, if we’re going to have Relative URL bypass options for an Application Firewall, I’m sure there’s a need for that for Application Authentication as well :wink:

#9

I see a part of this has been implemented on Cloudflare Workers, whereby, it’s now easier to reuse Access Groups. I’m not sure if this was already in the plans.

Would be nice to see the other stuff on it too… Especially, since we’re trying to roll out Cloudflare Workers across many clients.