> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-luisinasantos-sync-coupa-v0-1-13-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | |
| Access groups | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |
| Roles | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <Icon icon="square-check" iconType="solid" color="#c937ae" /> |

## 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.

<Warning>
  **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.
</Warning>

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.

<Warning>
  **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.
</Warning>

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.

<Warning>
  **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.
</Warning>

### 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.

<Warning>
  A user with **Super Administrator** access in Cloudflare Zero Trust must perform this task.
</Warning>

### Locate your Cloudflare Account ID

<Steps>
  <Step>
    Log into your Cloudflare Super Administrator account and select **Workers** from the left nav.
  </Step>

  <Step>
    On the **Workers** page, find your Account ID on the right side of the page.
  </Step>

  <Step>
    Copy and save the Account ID.
  </Step>
</Steps>

### Create an API Token

<Warning>
  **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**.
</Warning>

<Steps>
  <Step>
    Click the user icon and select **My Profile**.
  </Step>

  <Step>
    Click **API Tokens** on the left side, then click **Create Token**.
  </Step>

  <Step>
    At the bottom of the page, in the **Custom Token** area, click **Get started**.
  </Step>

  <Step>
    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**.
  </Step>

  <Step>
    Click **Create Token** and copy the token generated for you.
  </Step>
</Steps>

**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

<Warning>
  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
</Warning>

<Tabs>
  <Tab title="Cloud-hosted">
    **Follow these instructions to use a built-in, no-code connector hosted by C1.**

    <Steps>
      <Step>
        In C1, navigate to **Apps** > **Connectors** and click **Add connector**.
      </Step>

      <Step>
        Search for **Cloudflare Zero Trust** and click **Add**.
      </Step>

      <Step>
        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.
      </Step>

      <Step>
        Set the connector's **Name** and, optionally, a **Description**.
      </Step>

      <Step>
        Click the pencil icon next to **Owners** to choose who can configure and manage this connector.
      </Step>

      <Step>
        Click **Add**. The connector is created and its configuration page opens.
      </Step>

      <Step>
        Find the **Settings** area of the page and click **Edit**.
      </Step>

      <Step>
        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.
      </Step>

      <Step>
        Click **Save**.
      </Step>

      <Step>
        The connector's label changes to **Syncing**, followed by **Connected**. You can view the logs to ensure that information is syncing.
      </Step>
    </Steps>

    **Done.** Your Cloudflare Zero Trust connector is now pulling access data into C1.
  </Tab>

  <Tab title="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](https://github.com/conductorone/baton-cloudflare-zero-trust): Access the source code, report issues, or contribute to the project.

    ### Step 1: Set up a new Cloudflare Zero Trust connector

    <Steps>
      <Step>
        In C1, navigate to **Apps** > **Connectors** and click **Add connector**.
      </Step>

      <Step>
        Search for **Baton** and click **Add**.
      </Step>

      <Step>
        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.
      </Step>

      <Step>
        Set the connector's **Name** and, optionally, a **Description**.
      </Step>

      <Step>
        Click the pencil icon next to **Owners** to choose who can configure and manage this connector.
      </Step>

      <Step>
        Click **Add**. The connector is created and its configuration page opens.
      </Step>

      <Step>
        In the **Settings** area of the page, click **Edit**.
      </Step>

      <Step>
        Click **Rotate** to generate a new Client ID and Secret.

        Carefully copy and save these credentials. We'll use them in Step 2.
      </Step>
    </Steps>

    ### Step 2: Create Kubernetes configuration files

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

    #### Secrets configuration

    ```yaml expandable theme={null}
    # 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

    ```yaml expandable theme={null}
    # 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

    <Steps>
      <Step>
        Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
      </Step>

      <Step>
        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.
      </Step>
    </Steps>

    **Done.** Your Cloudflare Zero Trust connector is now pulling access data into C1.
  </Tab>
</Tabs>