Skip to main content

​
Capabilities

​
Access group rules

Cloudflare Access groups grant membership using three rule lists with different logic:
  • Include — OR. A user matches the group if at least one rule matches.
  • Require — AND. A user must also match every rule in this list.
  • Exclude — NOT. A user must not match any rule in this list.
Each list can contain several rule types (email, email domain, everyone, country, IP range, IdP group claim, a nested Access group, etc.). This connector can evaluate some of them and not others, and rules it cannot evaluate are skipped rather than treated as non-matching:

​
Why skipped rules do not narrow membership

Each list combines its rules with a boolean operator, and a skipped rule is treated as that operator’s neutral element so it cannot change the list’s answer: satisfied under Require’s AND, non-matching under Include’s OR and Exclude’s NOT. This matters most for Require. If a skipped rule were treated as “does not match”, a single one would make the whole AND fail and the group would report no members at all. A group with Include: email and Require: geo US really does grant access to that user, and C1 reports it.
A group whose Include list contains nothing this connector can evaluate reports no members at all. Include is an OR, and its neutral element is “no match”, so a list made up entirely of skipped rules — an IdP-group claim on its own, for example, which is a common Access setup — produces an empty result.That direction under-reports rather than over-reports, and an empty group in an access review reads as “nobody has access” rather than “this could not be determined”. The connector cannot tell the difference, and inventing members would be worse, so it logs every group in this state at sync time and lists the group’s rules on its resource profile. Check those groups in Cloudflare directly.
Contextual rules — country, IP range, mTLS certificate, device posture, authentication method — are never evaluated, and this is deliberate rather than a gap. They constrain the request: where it comes from and how it authenticated. They do not change who the policy grants access to, and Cloudflare evaluates them per request, so no connector can resolve them at sync time. C1 models who a policy grants access to, not the conditions under which that access applies.
Rules that name identities this connector cannot read may cause C1 to over-report membership. Nested Access groups referenced from Require/Exclude, email lists, IdP group claims (okta, gsuite, saml) and service tokens all name real identities, but in a directory this connector does not sync.Because they are skipped, a user who does not satisfy a Require rule — or who should be removed by an Exclude rule — may still be reported as a member of the group. In Include the effect runs the other way: a member admitted only by such a rule is not reported at all. Every group carrying such a rule is logged at sync time, and its rules are listed on the group’s profile in C1 under include_rules / require_rules / exclude_rules, so you can see exactly which conditions were not applied.For those groups, confirm membership in Cloudflare before relying on C1 for an access review.
A nested Access group referenced in Include is represented as an expandable grant on the referenced group’s own membership — so nested group membership (including further nesting) is reflected in C1 without this connector re-evaluating every member on every sync.
Nested Include membership is not reported when the same group also has Require or Exclude rules that this connector can evaluate. An expandable grant is a union: it pulls in everyone who holds the nested group’s membership, and the outer group’s Require/Exclude rules cannot be applied to the members it pulls in. A member excluded by the outer group would otherwise still be reported as a member of it.Rather than over-report access, the connector omits the nested membership for those groups and reports only the members matched directly by the outer group’s own email, email_domain and everyone rules. Rules that are skipped anyway — and a Require list consisting only of everyone — are not treated as restrictions, since they filter nothing. Affected groups are logged at sync time.

​
Granting and revoking group membership

C1 adds a member to an Access group by appending an email rule to the group’s Include list, and removes one by deleting that rule. Everything else about the group — its name and its Require and Exclude rules — is written back unchanged. Because membership is expressed as rules rather than as a member list, some requests cannot be carried out, and the connector refuses them rather than reporting a change it did not make: Membership that comes from a nested Access group cannot be revoked here either: the member belongs to the referenced group, not to this one.

​
Gather Cloudflare Zero Trust credentials

Configuring the connector requires you to pass in credentials generated in Cloudflare Zero Trust. Gather these credentials before you move on.
A user with Super Administrator access in Cloudflare Zero Trust must perform this task.

​
Locate your Cloudflare Account ID

1
Log into your Cloudflare Super Administrator account and select Workers from the left nav.
2
On the Workers page, find your Account ID on the right side of the page.
3
Copy and save the Account ID.

​
Create an API Token

Alternative credential option: If you do not want to generate and use an API token for the integration, Cloudflare Zero Trust also accepts authentication via an API key and the corresponding account’s email address. Find your API keys by navigating to My Profile > API Tokens.
1
Click the user icon and select My Profile.
2
Click API Tokens on the left side, then click Create Token.
3
At the bottom of the page, in the Custom Token area, click Get started.
4
Fill out the Create Custom Token page as follows:
  1. Give the API token a name, such as C1
  2. Set the appropriate permissions for the API token: If you want to use C1 to provision Cloudflare Zero Trust groups and roles, set:
    • Account -> Account Settings -> Read
    • Account -> Access: Organizations, Identity Providers, and Groups -> Edit
    • Account -> Access: Apps and Policies -> Read
    • Account -> Access: Audit Logs -> Read
    • Account -> Memberships -> Edit
    Otherwise, set:
    • Account -> Account Settings -> Read
    • Account -> Access: Organizations, Identity Providers, and Groups -> Read
    • Account -> Memberships -> Read
    • Account -> Access: Apps and Policies -> Read
    • Account -> Access: Audit Logs -> Read
  3. Click Continue to summary.
5
Click Create Token and copy the token generated for you.
Done. You should now have one of the following credentials sets:
  • Account ID
  • API token
OR
  • Account ID
  • The email address associated with your Cloudflare account
  • Global API key
Next, move on to the instructions for your chosen setup method.

​
Configure the Cloudflare Zero Trust connector

To complete this task, you’ll need:
  • The Connector Administrator or Super Administrator role in C1
  • Access to the set of Cloudflare Zero Trust credentials generated by following the instructions above
Follow these instructions to use a built-in, no-code connector hosted by C1.
1
In C1, navigate to Apps > Connectors and click Add connector.
2
Search for Cloudflare Zero Trust and click Add.
3
Choose where to add the connector: Create a new app, or Add to an existing app (then select the app).If you’re creating a new app, choose whether to link it to an application discovered from your identity provider: select Yes and pick the IdP application, or No to continue with just the connector.
4
Set the connector’s Name and, optionally, a Description.
5
Click the pencil icon next to Owners to choose who can configure and manage this connector.
6
Click Add. The connector is created and its configuration page opens.
7
Find the Settings area of the page and click Edit.
8
Choose how you’ll authenticate to Cloudflare Zero Trust:
  • Select API token, then enter the account ID into the Account ID field and paste the API token into the API token field.
  • Select Email + API key, then enter the account ID into the Account ID field, your email into the Email ID field, and your Global API key into the API key field.
9
Click Save.
10
The connector’s label changes to Syncing, followed by Connected. You can view the logs to ensure that information is syncing.
Done. Your Cloudflare Zero Trust connector is now pulling access data into C1.