Policies

Cloudflare Access determines who can reach your application by applying the Access policies you configure.

Every Access policy has four building blocks:

• Actions: What happens when a user matches the policy (Allow, Block, Bypass, or Service Auth)
• Rule types: How criteria are combined (Include, Require, or Exclude)
• Selectors: The attributes being checked (for example, email domain, country, or device posture)
• Values: The specific values to match against (for example, @example.com)

Actions let you grant or deny permission to a certain user or user group. You can set only one action per policy.

The Allow action in Cloudflare Access allows users that meet certain criteria to reach an application behind Access.

The following table shows an example Cloudflare Access Allow policy that lets any user with an @example.com email address, as validated against an IdP, reach the application:

You can add a Require rule in the same policy action to enforce additional checks. Finally, if the policy contains an Exclude rule, users meeting that definition are prevented from reaching the application.

For example, the following table shows an Allow policy with Require and Exclude rules. This configuration lets any user from Portugal with an @team.com email address, as validated against an IdP, reach the application, except for user-1 and user-2:

The Block action in Cloudflare Access prevents users who meet certain criteria from reaching an application. For example, the following table shows a Block policy that blocks requests from Russian source IPs that are not on your list of approved IPs.

Block policies are best used in conjunction with Allow policies as a way to carve out exceptions in those Allow policies. Since Access is deny by default, users who do not match a Block policy will still be denied access unless they explicitly match an Allow policy.

The Bypass action in Cloudflare Access disables Access enforcement for specific traffic.

The Bypass action disables any Access enforcement for traffic that meets the defined rule criteria. Bypass is typically used to enable applications that require specific endpoints to be public.

For example, some applications have an endpoint under the /admin route that must be publicly routable. In this situation, you could create an Access application for the domain test.example.com/admin/<your-url> and add the Bypass policy shown in the following table:

As part of implementing a Zero Trust security model, Cloudflare does not recommend using Bypass to grant direct permanent access to your internal applications. To enable seamless and secure access for on-network employees, use Cloudflare Tunnel to connect your private network and have users connect through the Cloudflare One Client.

Bypass policies which contain device posture check rules will not function when:

• Zaraz is enabled for the zone protected by Access
• A Worker intercepts the request

To work around these limitations and bypass Access, we recommend changing the policy action to Service Auth.

Service Auth rules in Cloudflare Access enforce authentication flows that do not require an identity provider IdP login, such as service tokens and mutual TLS.

The following table shows an example Cloudflare Access Service Auth policy configuration:

Rule types work like logical operators and determine how your criteria are combined to evaluate a user. All Access policies must contain at least one Include rule. This Include rule defines the initial pool of eligible users who can access an application. You can then add Exclude and Require rules to narrow the scope.

The Include rule in Cloudflare Access is similar to an OR logical operator. In case more than one Include rule is specified, users need to meet only one of the criteria.

The Exclude rule in Cloudflare Access works like a NOT logical operator. A user meeting any Exclusion criteria will not be allowed access to the application.

The Require rule in Cloudflare Access works like an AND logical operator. A user must meet all specified Require rules to be allowed access.

By default, any values added to a Require rule are concatenated by an AND operator. For example, let's say you want to grant access to an application to both the full-time employees and the contractors, and only the ones based in specific countries — say Portugal and the United States. If you set up a rule with the following configuration:

This policy requires the user to be in the United States AND Portugal simultaneously, and have an email ending in both @cloudflare.com AND @contractors.com. Therefore, nobody will have access to the application.

Solution: Use a rule group to convert AND logic to OR logic within a Require rule.

1. Create a rule group called Country requirements that includes users in Portugal OR the United States:

   Rule type	Selector	Value
   Include	Country	United States, Portugal

2. Create a policy that requires the rule group, and that also includes users with emails ending in either @cloudflare.com OR @contractors.com:

   Action	Rule type	Selector	Value
   Allow	Require	Rule group	Country requirements
   	Include	Emails ending in	@cloudflare.com, @contractors.com

When you add a rule to your Cloudflare Access policy, you will be asked to specify the criteria, or attributes, you want users to meet. These attributes are available for all Access application types, including SaaS, self-hosted, and non-HTTP applications.

Non-identity attributes are polled continuously, meaning they are evaluated with each new HTTP request for changes during the user session. If you have configured SCIM provisioning, you can force a user to re-attest all attributes with Access whenever you revoke the user in the IdP or update their IdP group membership.

¹ For SaaS applications, Access can only enforce policies at the time of initial sign on and when reissuing the SaaS session. Once the user has authenticated to the SaaS app, session management falls solely within the purview of the SaaS app.

Connection context settings allow you to control how users interact with an application after they have been granted access. While selectors determine who can access an application, connection context settings determine what actions users can take during their session. The available connection context settings depend on the application type.

Connection context is configured per policy, allowing you to grant different permissions to different groups of users. For example, you could allow full-time employees to copy data from a remote RDP session while restricting contractors to read-only access.

Cloudflare Access policies are evaluated based on their action type and order you set. Bypass and Service Auth policies are evaluated first, from top to bottom as shown in the UI. Then, Block and Allow policies are evaluated based on their order from top to bottom.

For example, if you have policies arranged as follows:

• Allow A
• Block B
• Service Auth C
• Bypass D
• Allow E

The policies will execute in this order: Service Auth C > Bypass D > Allow A > Block B > Allow E. Once a user matches an Allow or Block policy, evaluation stops and no subsequent policies can override the decision.

If you add any of the following rules to an Allow policy, anyone will be able to access your application.

The following table shows a Cloudflare Access policy that includes everyone:

The following table shows a Cloudflare Access policy that includes all users with valid email login methods:

API and Terraform provide programmatic ways to manage your Access policies and configurations.