> ## 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 an Argo CD connector

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

## Capabilities

| Resource | Sync | Provision | Deprovision |
| :- | :- | :- | :- |
| Accounts | <Icon icon="square-check" iconType="solid" color="#c937ae" /> | <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" /> | — |

The ArgoCD connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning).

When a new account is created by C1, the account's password will be sent to a [vault](/product/admin/vaults).

The connector also supports credential rotation for local accounts: C1 sets a new random password
and sends it to a vault. ArgoCD rejects every session and API token issued before a password
change, so rotation also cuts off the account's existing access.

## Connector actions

Connector actions are custom capabilities that extend C1 automations with app-specific operations.

| Automation step | Actions offered | How the target is selected |
| :- | :- | :- |
| Account lifecycle action | `enable_user`, `disable_user` | The step's own target-account selector — either the account in context or a specific account. C1 resolves `user_id` from that account. |
| [Perform connector action](/product/admin/automations-steps-reference#perform-connector-action) | `revoke_tokens` | Set `user_id` to the ArgoCD account name. |

| Action name | Additional fields | Description |
| :- | :- | :- |
| `disable_user` | `user_id` (string, required) | Disables an ArgoCD local account. ArgoCD rejects the account's password and API tokens while it is disabled. Reversible with `enable_user`. |
| `enable_user` | `user_id` (string, required) | Re-enables a disabled ArgoCD local account, restoring its existing password and API tokens. |
| `revoke_tokens` | `user_id` (string, required) | Revokes every API token issued to an ArgoCD local account. The account, its password and its enabled state are unchanged. Run it with `disable_user` when a re-enabled account must not get its old tokens back. |

## Account lifecycle

The connector manages ArgoCD **local accounts**. ArgoCD's Account API exposes no delete, disable
or enable endpoint, so the connector changes accounts through the Kubernetes API, using the
permissions described in [Gather ArgoCD credentials](#gather-argocd-credentials).

* **Disable / enable** (the `disable_user` and `enable_user` actions) are reversible. The account
  keeps its password and API tokens, which ArgoCD refuses while the account is disabled and
  accepts again once it is enabled.
* **Revoke API tokens** (the `revoke_tokens` action) removes the account's API tokens without
  touching the account itself.
* **Rotate password** (credential rotation) sets a new random password and invalidates every
  session and API token issued before it.
* **Delete** (account deprovisioning) is permanent. It revokes the account's API tokens, removes
  its role grants and direct permissions, removes the account, and purges its stored credentials,
  so an account created later with the same name inherits none of them.

Use `disable_user` to suspend access you may need to restore, and delete to remove the account
for good.

**Notes:**

* The built-in `admin` account cannot be disabled, enabled, rotated, stripped of its tokens or
  deleted. The connector also refuses to do any of these, except enable, to the account it
  authenticates as, since it would lock itself out of ArgoCD. SSO/Dex-managed identities are not
  local accounts, so there is nothing for the connector to manage for them.
* Disabling a disabled account, enabling an enabled account, revoking the tokens of an account
  that has none, or deleting an account that is already gone is reported as success. The actions
  and rotation fail with a not-found error for an account ArgoCD does not know.
* Account names may contain only alphanumerics, `-` and `_`. Names containing `.` are rejected,
  since ArgoCD cannot address them as accounts.
* Deleting an account rewrites `policy.csv` in `argocd-rbac-cm`, which removes its `#` comment lines.
* Revoking tokens and rotating another account's password need the `accounts, update` ArgoCD RBAC
  permission for the connector's account. Deleting accounts also requires the `secrets` Kubernetes
  permissions described below.

## Gather ArgoCD credentials

Configuring the connector requires you to pass in credentials generated in ArgoCD. Gather these credentials before you move on.

### Create a Role with required permissions

The connector needs permissions to read and modify ArgoCD ConfigMaps, and to read and patch the
ArgoCD Secret. Create a Role that grants access to the following objects:

* `argocd-rbac-cm` ConfigMap: Contains RBAC policies and role grants (needs read and write access)
* `argocd-cm` ConfigMap: Contains ArgoCD configuration including user accounts (needs write access for provisioning, deprovisioning and the enable/disable actions)
* `argocd-secret` Secret: Contains local accounts' password hashes and API token records (needs read and write access for account deletion)

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: baton-argo-cd
  namespace: argocd
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "patch", "update"]
  - apiGroups: [""]
    resources: ["secrets"]
    resourceNames: ["argocd-secret"]
    verbs: ["get", "patch"]
```

**Required Permissions Explained:**

* `get`: Read individual ConfigMaps (required to read `argocd-rbac-cm` and `argocd-cm`)
* `list`: List ConfigMaps in the namespace (required to discover and access the ConfigMaps)
* `patch`: Partially update ConfigMaps (used to modify RBAC policies and user accounts)
* `update`: Fully update ConfigMaps (used as an alternative to patch for modifying ConfigMaps)
* `get`/`patch` on `secrets`: Read and purge a deleted account's stored credentials in `argocd-secret`. Restricted to that one Secret by name, so the connector cannot read the repository and cluster credentials that also live in the `argocd` namespace. Only needed for account deletion; omit the rule entirely if you do not use it.

<Warning>
  The `argocd-secret` permissions are new. Existing deployments must re-apply this role before
  account deletion is used. Without them the credential-purge step fails with a `403` after the
  account has already been deleted, leaving its stored credentials in place.
</Warning>

Apply with:

```bash theme={null}
kubectl apply -f role.yaml
```

### Create a RoleBinding

Bind the Role to the ServiceAccount so the connector can use the permissions:

```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: baton-argo-cd
  namespace: argocd
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: baton-argo-cd
subjects:
  - kind: ServiceAccount
    name: baton-argo-cd
    namespace: argocd
```

Apply with:

```bash theme={null}
kubectl apply -f rolebinding.yaml
```

### Gather additional credentials

To set up the connector, you'll need:

<Steps>
  <Step>
    The username and password for your ArgoCD admin account, or for a dedicated service account you've set up.
    Make sure the account used to configure the connector has the relevant permissions:

    * To sync (read) users and roles: `get` and `list` permissions for users and roles
    * To provision (read-write) users and roles: `get` and `list` permissions for users and roles, plus `create` permission for users and `update` permission for user role assignments. The built-in `admin` role has these permissions, or you can create a custom role.
  </Step>

  <Step>
    Your ArgoCD API URL, which is the URL you use to access the ArgoCD UI.
  </Step>

  <Step>
    The `kubeconfig` path or file to connect to the cluster where ArgoCD is running.

    **The connector should be deployed in the same Kubernetes cluster as ArgoCD** (such as in the `argocd` namespace). This allows the connector to automatically use the in-cluster configuration from the pod's service account. No `kubeconfig` file is needed in this case. If one is provided, it will take precedence over in-cluster.

    Find [more information on setting up an in-cluster configuration](https://github.com/conductorone/baton-argo-cd/blob/main/docs/docs-info.md#kubernetes-deployment-in-cluster-configuration) in the connector repo.
  </Step>

  <Step>
    (Optional) If your ArgoCD instance uses a self-signed TLS certificate, you'll need one of the following:

    * **For testing/development**: Set `BATON_INSECURE_SKIP_VERIFY=true` to skip certificate verification.
    * **For production**: Obtain the CA certificate used to sign your ArgoCD server's TLS certificate and save it as a file. You'll pass its path as `BATON_CA_CERT_PATH`.
  </Step>
</Steps>

**Done.** Next, move on to the connector configuration instructions.

## Configure the ArgoCD connector

<Warning>
  **To complete this task, you'll need:**

  * The **Connector Administrator** or **Super Administrator** role in C1
  * Access to the set of ArgoCD 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.**

    This connector does not support cloud hosting.
  </Tab>

  <Tab title="Self-hosted">
    **Follow these instructions to use the ArgoCD 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-argo-cd): Access the source code, report issues, or contribute to the project.

    ### Step 1: Set up a new ArgoCD 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 ArgoCD connector deployment:

    #### Secrets configuration

    ```yaml expandable theme={null}
    # baton-argo-cd-secrets.yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: baton-argo-cd-secrets
    type: Opaque
    stringData:
      # C1 credentials
      BATON_CLIENT_ID: <C1 client ID>
      BATON_CLIENT_SECRET: <C1 client secret>

      # ArgoCD specific credentials
      BATON_USERNAME: <ArgoCD account username>
      BATON_PASSWORD: <ArgoCD account password>
      BATON_API_URL: <ArgoCD tenant API URL>

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

      # Optional: TLS configuration for ArgoCD servers using self-signed certificates
      # Use BATON_INSECURE_SKIP_VERIFY for development only (insecure)
      BATON_INSECURE_SKIP_VERIFY: "true"
      # Use BATON_CA_CERT_PATH in production to verify with a custom CA certificate
      BATON_CA_CERT_PATH: <path to CA certificate file>
    ```

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

    #### Deployment configuration

    ```yaml expandable theme={null}
    # baton-argo-cd.yaml
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: baton-argo-cd
      labels:
        app: baton-argo-cd
    spec:
      selector:
        matchLabels:
          app: baton-argo-cd
      template:
        metadata:
          labels:
            app: baton-argo-cd
            baton: true
            baton-app: argo-cd
        spec:
          containers:
          - name: baton-argo-cd
            image: public.ecr.aws/conductorone/baton-argo-cd:latest
            imagePullPolicy: IfNotPresent
            env:
            - name: BATON_HOST_ID
              value: baton-argo-cd
            envFrom:
            - secretRef:
                name: baton-argo-cd-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 ArgoCD connector to. ArgoCD data should be found on the **Entitlements** and **Accounts** tabs.
      </Step>
    </Steps>

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