Set up a Cloudflare Zero Trust connector

C1 provides identity governance for Cloudflare Zero Trust. Integrate your Cloudflare Zero Trust instance with C1 to run user access reviews (UARs) and enable just-in-time access requests.

Capabilities

Resource	Sync	Provision
Accounts
Access groups
Roles

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:

Rule type	Evaluated?	Effect on reported membership
email, email_domain, everyone	Yes	Fully enforced in all three lists.
group (nested Access group)	In Include only	Reported as an expandable grant — see below.
ip, ip_list, geo, certificate, device_posture, auth_method, login_method, auth_context, external_evaluation	No	None, by design.
email_list, IdP group claims (okta, gsuite, saml, …), service tokens	No	May over- or under-report — see below.

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:

Request	Result
Grant to someone a Require or Exclude rule keeps out	Refused. The rule would be written but would grant nothing, and C1 would never hold the grant, so the rule would stay in your policy unnoticed.
Grant to someone already admitted by a broad rule (everyone, email_domain)	No change. They already have access, and adding a rule naming them would only leave a redundant one behind.
Revoke from someone whose access comes from a broad rule	Refused. That rule governs other members too, so it cannot be edited on one person’s behalf. Change it in Cloudflare instead.
Revoke the last email rule in a group’s Include list	Refused. Cloudflare rejects a group with an empty Include list. Delete or edit the group in Cloudflare instead.
Revoke from someone who is not a member	No change.

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

Cloud-hosted

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.

Self-hosted

Follow these instructions to use the Cloudflare Zero Trust connector, hosted and run in your own environment.

When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.

Resources

• GitHub repository: Access the source code, report issues, or contribute to the project.

Step 1: Set up a new Cloudflare Zero Trust connector

1. In C1, navigate to Apps > Connectors and click Add connector.

2. Search for Baton 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. In the Settings area of the page, click Edit.

8. Click Rotate to generate a new Client ID and Secret.

   Carefully copy and save these credentials. We’ll use them in Step 2.

Step 2: Create Kubernetes configuration files

Create two Kubernetes manifest files for your Cloudflare Zero Trust connector deployment:

Secrets configuration

# baton-cloudflare-zero-trust-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: baton-cloudflare-zero-trust-secrets
type: Opaque
stringData:
  # C1 credentials
  BATON_CLIENT_ID: <C1 client ID>
  BATON_CLIENT_SECRET: <C1 client secret>
  
  # Cloudflare Zero Trust credentials, option 1
  BATON_ACCOUNT_ID: <Cloudflare Zero Trust account ID>
  BATON_API_TOKEN: <Cloudflare Zero Trust API token>

  # Cloudflare Zero Trust credentials, option 2
  BATON_ACCOUNT_ID: <Cloudflare Zero Trust account ID>
  BATON_API_KEY: <Cloudflare Zero Trust global API key>
  BATON_EMAIL: <Email address for your Cloudflare Zero Trust account>

  # Optional: include if you want C1 to provision access using this connector
  BATON_PROVISIONING: true

See the connector’s README or run --help to see all available configuration flags and environment variables.

Deployment configuration

# baton-cloudflare-zero-trust.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: baton-cloudflare-zero-trust
  labels:
    app: baton-cloudflare-zero-trust
spec:
  selector:
    matchLabels:
      app: baton-cloudflare-zero-trust
  template:
    metadata:
      labels:
        app: baton-cloudflare-zero-trust
        baton: true
        baton-app: cloudflare-zero-trust
    spec:
      containers:
      - name: baton-cloudflare-zero-trust
        image: public.ecr.aws/conductorone/baton-cloudflare-zero-trust:latest
        imagePullPolicy: IfNotPresent
        env:
        - name: BATON_HOST_ID
          value: baton-cloudflare-zero-trust
        envFrom:
        - secretRef:
            name: baton-cloudflare-zero-trust-secrets

Step 3: Deploy the connector

1. Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.

2. Check that the connector data uploaded correctly. In C1, click Apps. On the Managed apps tab, locate and click the name of the application you added the Cloudflare Zero Trust connector to. Cloudflare Zero Trust data should be found on the Entitlements and Accounts tabs.

Done. Your Cloudflare Zero Trust connector is now pulling access data into C1.