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
Roles			—

The ArgoCD connector supports automatic account provisioning and deprovisioning.

When a new account is created by C1, the account’s password will be sent to a vault.

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

• 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)

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.

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.

Apply with:

kubectl apply -f role.yaml

Create a RoleBinding

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

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:

kubectl apply -f rolebinding.yaml

Gather additional credentials

To set up the connector, you’ll need:

1. 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.
2. Your ArgoCD API URL, which is the URL you use to access the ArgoCD UI.

3. 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 in the connector repo.

4. (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.

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

Configure the ArgoCD connector

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

Cloud-hosted

Follow these instructions to use a built-in, no-code connector hosted by C1.

This connector does not support cloud hosting.

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: Access the source code, report issues, or contribute to the project.

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

Secrets configuration

# 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

# 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

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 ArgoCD connector to. ArgoCD data should be found on the Entitlements and Accounts tabs.

Done. Your ArgoCD connector is now pulling access data into C1.