Configuring Access Policies

Access policies allow you to protect an entire website or a particular URI (the Application Resource). Policies also define the users or groups who can, or cannot, access the Application Resource.

You can configure an access policy for an apex domain, a particular subdomain, or all subdomains using a wildcard policy.

Configuring Access Policy

Similarly, you can apply an access policy to an entire website or protect a specific path. If you want to protect the entire website, leave the PATH field empty. You can also specify paths, for example /admin as shown in the example above.

Access does not support overlapping definitions. For example, if you set policies for /admin and /admin/specific separately, /admin/specific will not inherit the policy set for /admin.

Access does not support port numbers in the URL. Requests to URLs with port numbers will be redirected to the URL with the port number stripped.

Types of Policy Decisions

Cloudflare Access enforcement consists of two tiers: policies and rules. Policies define how a decision will be enforced. Rules define who meets the criteria of a policy decision.

Allow

Allow policies provide access to a user or group to the application. Users who meet the criteria in the Rules defined for a given Allow policy will be granted permission to reach the application.

Allow policies can contain Exclude and Require rules to enforce more granular controls.

Example: An Allow policy contains an Include rule that defined as “Emails Ending In: @example.com”. Any user with an @example.com email address, as validated against an IdP, will be permitted to reach the application. Adding a Require rule in the same policy will enforce additional checks. If the Require rule defines a set of IP Ranges, then a user must be both a member of “@example.com” and their request must originate from the IP range defined. Finally, if the policy also contains an Exclude rule, users who meet that definition will be prevented from reaching the application. If the Exclude rule defines a single email, “[email protected]”, then all users who are in @example.com and in the IP range will be granted access except for “[email protected]”.

Deny

Deny policies explicity prevent users from reaching an application behind Access. Deny policies enforce similar behavior to Allow policies that contain an Exclude rule without the need to allow specific users.

Example: A Deny policy that contains an Include rule defined as “Everyone” will restrict access to any requests that attempt to reach the application.

Bypass

This policy is used to bypass Access for a specific path of the application or for the entire application. Bypass policies disable any Access enforcement on the given path.

Example: You have a website secured with Access. However, a third-party service needs access to a specific endpoint. You can configure traffic to bypass Access to hit that particular endpoint. You can whitelist a range of IP addresses to bypass Access or allow all traffic by setting the policy to include “Everyone”.

If the service does not publish its IP range, or they change periodically, you can include “Everyone” in the bypass policy to allow traffic from any request to bypass Access and hit the specified path.

When configuring bypass to allow request to a specific page, while the entire site or other pages are protected, be sure to store your assets in the path to be bypassed. Otherwise, Access will allow traffic to that page but will not retrieve assets stored in protected locations.

Note: When a bypass policy is applied, the security settings revert to the defaults configured for the zone and any page rules applied. If “Always use HTTPS” is enabled for the site, then traffic to the bypassed destination will continue to be HTTPS. If it is not, or you have applied page rules to disable it, traffic will be HTTP.

Non Identity

Non Identity policies enforce authentication flows that do not require an identity provider login, like service tokens and mutual TLS.

Types of Rule Decisions

Include
  • The include policy works like an OR logical operator.
  • Example: A policy contains two Include rules: “Email Ending In: @example.com” and “Emails: [email protected]”. In this configuration, any user who is a member of “@example.com” or who has the email address “[email protected]” will be allowed access. Users do not need to meet both criteria.
  • Ex: Include everyone who has email ending in @company.com or belongs to the engineering group.
  • Every access group and an application policy should have at least one include access rule.

Exclude

  • The exclude policy works like a NOT logical operator
  • Example: A policy contains an Exclude rule: “Emails: [email protected]”. A user with that email address will be excluded from any Include rules defined and will not be permitted access to the application.

Require

  • The require policy works like an AND logical operator.
  • Example: A policy contains a Require rule: “IP Ranges: 192.168.100.142”. Users will be required to send requests from this IP range, in addition to meeting at least one criteria in an Include rule, to reach the application.

Policy ordering

Access policies trigger in an order based on their position in policy table in the UI, with the exception of bypass policies - Access will evaluate Bypass policies first.

For Allow and Deny policies, Access will enforce the decision starting at the top of your list and moving down. You can modify the order by dragging and dropping individual policies in the UI.

Policy ordering and paths

You can create unique policies for parts of your application that share a root path. When multiple policies are set for a common path root, they do not inherit rules. Instead, the more specific policy takes precedence.

For example:

  • Your application is deployed at dashboard.com/eng.
  • You create “Policy A” that restricts access to that path to only members of your engineering team.
  • You also have a tool deployed at dashboard.com/eng/exec that only your executive team should be able to reach.
  • If you only use “Policy A”, then this path will inherit the rules from “Policy A” and members of your engineering team will be able to reach it. You can instead create a second policy, “Policy B”, that restricts access to your executive team.
  • If you apply “Policy B” to dashboard.com/eng/exec the more specific policy takes precedence. The /exec path will be gated by “Policy B” instead of relying on the rules in “Policy A.”

Wildcard Policies

Cloudflare Access can secure any subdomain of your apex domain using a wildcard policy. To create a wildcard policy, input an “*” in the subdomain field in the policy generator.

The wildcard subdomain does not cover the apex domain itself. For example, a policy that controls access in the following format:

“*.example.com”

This format will cover “alpha.example.com”, “beta.example.com”, but not “example.com”. However, you must create a separate policy for the apex domain.