# ArgoCD

ArgoCD is a Kubernetes-native continuous delivery (CD) tool that implements GitOps practices by using Git repositories as the single source of truth for application state.

Through this integration, Apono helps you discover ArgoCD roles and resources and securely manage just-in-time (JIT) access to them.

***

### Prerequisites

<table><thead><tr><th width="185.265625">Item</th><th>Description</th></tr></thead><tbody><tr><td><strong>Apono connector</strong></td><td><p>On-prem connection serving as a bridge between an ArgoCD instance and Apono:</p><ul><li><a href="/pages/U4HFH35XWDo3jyqhJqgQ">AWS</a></li><li><a href="/pages/ztAsRPKJcMNxeQKE2GNB">Azure</a></li><li><a href="/pages/xPrzAcLGsoliEpPJuozp">GCP</a></li><li><a href="/pages/p5PzUV4THznqePSTYgEH">Kubernetes</a></li></ul><p><br><span data-gb-custom-inline data-tag="emoji" data-code="26a0">⚠️</span> <strong>IMPORTANT</strong>: When the Apono connector is running in a different cluster than ArgoCD, the connector must have network access to the <strong>Kubernetes Server URL</strong>.</p><p><br>For Amazon EKS, <a href="https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html">update the cluster security group</a> to include a rule allowing the connector to connect to the cluster over <strong>TCP 442 (HTTPS)</strong>.</p></td></tr><tr><td><strong>Kubernetes Command Line Tool (kubectl)</strong></td><td><a href="https://kubernetes.io/docs/reference/kubectl/">Command-line tool</a> used for communicating with a Kubernetes cluster's control plane</td></tr><tr><td><strong>ArgoCD</strong></td><td>Instance installed and configured with your Identity Provider (IdP) for authentication</td></tr></tbody></table>

***

### Set up Apono in ArgoCD

The steps to set up Apono in ArgoCD depend on where the Apono Connector is running and what permissions it has. The connector’s location determines whether you need to create a new service account, bind roles, or provide a token secret.

Use the tabs below to follow the instructions that match your environment:

* **Same cluster (cluster-admin)**: The connector already has full permissions.
* **Same cluster (limited permissions)**: Grant the connector’s existing service account the minimal Role/RoleBinding it needs.
* **Different cluster**: Create a dedicated service account in the ArgoCD cluster and provide its token to Apono.

Follow these steps to set up Apono access in ArgoCD:

1. Open the `argocd-cm` ConfigMap in your default editor.

```sh
kubectl edit configmap argocd-cm -n argocd
```

2. Ensure email and group identity data are available and mapped in the authentication settings.

{% hint style="info" %}
This allows ArgoCD to map users by email, in addition to groups.

The following examples are edited ConfigMaps OIDC and SAML configurations.
{% endhint %}

{% code title="Example: OIDC configuration - Add email to both the OIDC scopes: requestedScopes and groupsClaim." %}

```
oidc.config: |
  name: Authentik
  issuer: https://my-issuer.com
  clientID: myclientid
  clientSecret: myclientsecret
  requestedScopes:
    - openid
    - profile
    - email
    - groups
    - offline_access
  insecureSkipVerify: true
  requestedIDTokenClaims:
    groups:
      essential: true
  groupsClaim: [groups, email]
```

{% endcode %}

{% code title="Example: SAML (Dex) configuration - Map the user’s email and group attributes in the Dex SAML connector configuration." %}

```
data:
  url: https://argocd.example.com
  dex.config: |
    connectors:
    - type: saml
      id: okta
      name: Okta
      config:
        ssoURL: https://your-org.okta.com/app/.../sso/saml
        caData: |
          <base64-encoded-ca-cert>
        redirectURI: https://argocd.example.com/api/dex/callback
        usernameAttr: email
        emailAttr: email
        groupsAttr: group
```

{% endcode %}

3. Define your ArgoCD roles.

{% hint style="info" %}
Add any global roles in the `argocd-rbac-cm` configmap's [policy.csv](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#policy-csv-composition) for cluster-wide access. Add any [project roles](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-roles) in the `spec.roles` of specific AppProject custom resource definitions (CRDs).

Apono will sync ArgoCD roles (both project and global) from the `argocd-rbac-cm` ConfigMap. Apono policies can then be applied to grant or revoke Just-In-Time (JIT) access to ArgoCD resources.
{% endhint %}

{% tabs %}
{% tab title="Example: policy.csv" %}

```csv
# Example in argocd-rbac-cm
policy.csv: |
  p, role:readonly, applications, get, */*, allow
  p, role:deployer, applications, sync, */*, allow
```

{% endtab %}

{% tab title="Example: spec.roles" %}
{% code overflow="wrap" %}

```csv
# Example in an AppProject CRD
roles:
  - name: deployer
    description: Can sync apps in this project
    policies:
      - p, proj:team-a:deployer, applications, sync, team-a/*, allow
```

{% endcode %}
{% endtab %}
{% endtabs %}

4. Restart the ArgoCD API server for the changes to take effect.

```sh
kubectl rollout restart deployment argocd-server -n argocd
```

Follow these steps to set up Apono access in ArgoCD:

1. Copy and save the following snippet as **apono-argocd-sa.yaml**.

{% hint style="info" %}
This manifest does two things:

* Grants the service account a role with permission to update the `argocd-rbac-cm` ConfigMap (global roles) and AppProject custom resource definitions (project roles).
* Binds that role to the service account so Apono can discover and manage ArgoCD roles.
  {% endhint %}

<details>

<summary><strong>apono-argocd-sa.yaml</strong></summary>

{% code overflow="wrap" %}

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: apono-argocd-editor
  namespace: argocd
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["argocd-rbac-cm"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: ["argoproj.io"]
    resources: ["appprojects"]
    verbs: ["get", "list", "watch", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: apono-argocd-editor-binding
  namespace: argocd
subjects:
  - kind: ServiceAccount
    name: <existing-connector-service-account-name>
    namespace: argocd
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: apono-argocd-editor
```

{% endcode %}

</details>

2. At the shell prompt, apply the file to your ArgoCD cluster.

```sh
kubectl apply -f apono-argocd-sa.yaml
```

3. Open the `argocd-cm` ConfigMap in your default editor.

```sh
kubectl edit configmap argocd-cm -n argocd
```

4. Ensure email and group identity data are available and mapped in the authentication settings.

{% hint style="info" %}
This allows ArgoCD to map users by email, in addition to groups.

The following examples are edited ConfigMaps OIDC and SAML configurations.
{% endhint %}

{% code title="Example: OIDC configuration

Add email to both the OIDC scopes: requestedScopes and groupsClaim. " %}

```
oidc.config: |
  name: Authentik
  issuer: https://my-issuer.com
  clientID: myclientid
  clientSecret: myclientsecret
  requestedScopes:
    - openid
    - profile
    - email
    - groups
    - offline_access
  insecureSkipVerify: true
  requestedIDTokenClaims:
    groups:
      essential: true
  groupsClaim: [groups, email]
```

{% code title="Example: SAML (Dex) configuration

Map the user’s email and group attributes in the Dex SAML connector configuration. " %}

```
data:
  url: https://argocd.example.com
  dex.config: |
    connectors:
    - type: saml
      id: okta
      name: Okta
      config:
        ssoURL: https://your-org.okta.com/app/.../sso/saml
        caData: |
          <base64-encoded-ca-cert>
        redirectURI: https://argocd.example.com/api/dex/callback
        usernameAttr: email
        emailAttr: email
        groupsAttr: group
```

5. Define your ArgoCD roles.

{% hint style="info" %}
Add any global roles in the `argocd-rbac-cm` configmap's [policy.csv](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#policy-csv-composition) for cluster-wide access. Add any [project roles](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-roles) in the `spec.roles` of specific AppProject custom resource definitions (CRDs).

Apono will sync ArgoCD roles (both project and global) from the `argocd-rbac-cm` ConfigMap. Apono policies can then be applied to grant or revoke Just-In-Time (JIT) access to ArgoCD resources.
{% endhint %}

{% tabs %}
{% tab title="Example: policy.csv" %}

```csv
# Example in argocd-rbac-cm
policy.csv: |
  p, role:readonly, applications, get, */*, allow
  p, role:deployer, applications, sync, */*, allow
```

{% endtab %}

{% tab title="Example: spec.roles" %}
{% code overflow="wrap" %}

```csv
# Example in an AppProject CRD
roles:
  - name: deployer
    description: Can sync apps in this project
    policies:
      - p, proj:team-a:deployer, applications, sync, team-a/*, allow
```

{% endcode %}
{% endtab %}
{% endtabs %}

6. Restart the ArgoCD API server for the changes to take effect.

```sh
kubectl rollout restart deployment argocd-server -n argocd
```

{% hint style="warning" %}
When using the **Different cluster** setup, the connector must have network access to the **Kubernetes Server URL**.

\
For Amazon EKS, ensure the cluster security group allows the connector to [connect over **TCP 442 (HTTPS)**](#prerequisites) before proceeding.
{% endhint %}

Follow these steps to set up Apono access in ArgoCD:

1. Copy and save the following snippet as **apono-argocd-sa.yaml**.

{% hint style="info" %}
This manifest does three things:

* Creates the `apono-argocd-sa` service account in the `argocd` namespace.
* Grants the service account a role with permission to update the `argocd-rbac-cm` ConfigMap (global roles) and AppProject custom resource definitions (project roles).
* Binds that role to the service account so Apono can discover and manage ArgoCD roles.
  {% endhint %}

<details>

<summary><strong>apono-argocd-sa.yaml</strong></summary>

{% code overflow="wrap" %}

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: apono-argocd-sa
  namespace: argocd
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: apono-argocd-editor
  namespace: argocd
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["argocd-rbac-cm"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: ["argoproj.io"]
    resources: ["appprojects"]
    verbs: ["get", "list", "watch", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: apono-argocd-editor-binding
  namespace: argocd
subjects:
  - kind: ServiceAccount
    name: apono-argocd-sa
    namespace: argocd
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: apono-argocd-editor
```

{% endcode %}

</details>

2. At the shell prompt, apply the file to your ArgoCD cluster.

```sh
kubectl apply -f apono-argocd-sa.yaml
```

3. Open the `argocd-cm` ConfigMap in your default editor.

```sh
kubectl edit configmap argocd-cm -n argocd
```

4. Ensure email and group identity data are available and mapped in the authentication settings.

{% hint style="info" %}
This allows ArgoCD to map users by email, in addition to groups.

The following examples are edited ConfigMaps OIDC and SAML configurations.
{% endhint %}

{% code title="Example: OIDC configuration

Add email to both the OIDC scopes: requestedScopes and groupsClaim. " %}

```
oidc.config: |
  name: Authentik
  issuer: https://my-issuer.com
  clientID: myclientid
  clientSecret: myclientsecret
  requestedScopes:
    - openid
    - profile
    - email
    - groups
    - offline_access
  insecureSkipVerify: true
  requestedIDTokenClaims:
    groups:
      essential: true
  groupsClaim: [groups, email]
```

{% code title="Example: SAML (Dex) configuration

Map the user’s email and group attributes in the Dex SAML connector configuration. " %}

```
data:
  url: https://argocd.example.com
  dex.config: |
    connectors:
    - type: saml
      id: okta
      name: Okta
      config:
        ssoURL: https://your-org.okta.com/app/.../sso/saml
        caData: |
          <base64-encoded-ca-cert>
        redirectURI: https://argocd.example.com/api/dex/callback
        usernameAttr: email
        emailAttr: email
        groupsAttr: group
```

5. Define your ArgoCD roles.

{% hint style="info" %}
Add any global roles in the `argocd-rbac-cm` configmap's [policy.csv](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#policy-csv-composition) for cluster-wide access. Add any [project roles](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-roles) in the `spec.roles` of specific AppProject custom resource definitions (CRDs).

Apono will sync ArgoCD roles (both project and global) from the `argocd-rbac-cm` ConfigMap. Apono policies can then be applied to grant or revoke Just-In-Time (JIT) access to ArgoCD resources.
{% endhint %}

{% tabs %}
{% tab title="Example: policy.csv" %}

```csv
# Example in argocd-rbac-cm
policy.csv: |
  p, role:readonly, applications, get, */*, allow
  p, role:deployer, applications, sync, */*, allow
```

{% endtab %}

{% tab title="Example: spec.roles" %}
{% code overflow="wrap" %}

```csv
# Example in an AppProject CRD
roles:
  - name: deployer
    description: Can sync apps in this project
    policies:
      - p, proj:team-a:deployer, applications, sync, team-a/*, allow
```

{% endcode %}
{% endtab %}
{% endtabs %}

6. Restart the ArgoCD API server for the changes to take effect.

```sh
kubectl rollout restart deployment argocd-server -n argocd
```

7. Generate the service account token.

{% hint style="warning" %}
Make sure you are using a Kubernetes version **≥1.24**.

On earlier versions, you may need to retrieve the token from the service account’s Secret.
{% endhint %}

```sh
kubectl -n argocd create token apono-argocd-sa
```

8. [Create a secret](/docs/connectors-and-secrets/apono-integration-secret.md) with the token from step **7**. Use the following key-value pair structure when generating the secret. Be sure to replace `#K8_SERVICE_TOKEN` with the actual value.

```
"k8s_token":"#K8_SERVICE_TOKEN"
```

{% hint style="success" %}
You can also input the token directly into the Apono UI during the integration process.
{% endhint %}

You can now Integrate ArgoCD.

***

### Integrate ArgoCD

{% hint style="success" %}
You can also use the steps below to integrate with Apono using Terraform.

In step **11**, instead of clicking **Confirm**, follow the **Are you integrating with Apono using Terraform?** guidance.
{% endhint %}

Follow these steps to complete the integration:

1. On the [**Catalog**](https://app.apono.io/catalog?search=argocd) tab, click **ArgoCD**. The **Connect Integration** page appears.
2. Under **Discovery**, click one or more resource types to sync with Apono.

{% hint style="info" %}
Apono automatically discovers and syncs all the instances in the environment. After syncing, you can manage Access Flows to these resources.
{% endhint %}

3. Click **Next**. The **Apono connector** section expands.
4. From the dropdown menu, select a connector. Choosing a connector links Apono to all the services available on the account where the connector is located.

{% hint style="success" %}
If the desired connector is not listed, click **+ Add new connector** and follow the instructions for creating a connector ([AWS](/docs/aws-environment/apono-connector-for-aws.md), [Azure](/docs/azure-environment/apono-connector-for-azure.md), [GCP](/docs/gcp-environment/apono-connector-for-gcp.md), [Kubernetes](/docs/kubernetes-environment/apono-connector-for-kubernetes.md)).
{% endhint %}

5. Click **Next**. The **Integration Config** section expands.
6. Define the **Integration Config** settings.

   <table><thead><tr><th width="229">Setting</th><th>Description</th></tr></thead><tbody><tr><td><strong>Integration Name</strong></td><td>Unique, alphanumeric, user-friendly name used to identify this integration when constructing an access flow</td></tr><tr><td><strong>ArgoCD UI URL</strong></td><td><p>Public URL of your ArgoCD instance</p><p><strong>Example</strong>: <em>https://argocd.my-domain.com</em></p></td></tr><tr><td><strong>ArgoCD Namespace</strong></td><td>Kubernetes namespace where ArgoCD is installed<br><strong>Default</strong>: <em>argocd</em></td></tr><tr><td><strong>Kubernetes Server URL</strong></td><td><p>(Optional) API server endpoint of the Kubernetes cluster hosting ArgoCD</p><p>Provide the URL only when connecting to an external Kubernetes API server.</p><p>Leave this field blank when Apono’s connector is running in the same cluster.</p></td></tr><tr><td><strong>Kubernetes Certificate Authority</strong></td><td><p>(Optional) Certificate Authority (CA) bundle used to validate the Kubernetes API server certificate</p><p>Provide the CA file if connecting to an external cluster with a custom CA.</p><p>Leave this field blank when Apono's connector is running in the same cluster.</p></td></tr></tbody></table>
7. Click **Next**. The **Secret Store** section expands.
8. (Different cluster) [Associate the secret or credentials](/docs/connectors-and-secrets/apono-integration-secret.md).

{% hint style="info" %}
This step is **not necessary** when the Apono connector is in the same cluster as ArgoCD.

If you select the **Apono** secret manager, enter the following value:

* **Kubernetes Service Account Token**: Enter the service account token value from step **7** of the [previous section](#different-cluster) on the **Different cluster** tab.
  {% endhint %}

9. Click **Next**. The **Get more with Apono** section expands.
10. Define the **Get more with Apono** settings.

    <table><thead><tr><th width="205">Setting</th><th>Description</th></tr></thead><tbody><tr><td><strong>Credential Rotation</strong></td><td><p>(Optional) Number of days after which the database credentials must be rotated</p><p>Learn more about the <a href="/pages/UsMtClaCM1SlvPsARUsM">Credentials Rotation Policy</a>.</p></td></tr><tr><td><strong>User cleanup after access is revoked (in days)</strong></td><td><p>(Optional) Defines the number of days after access has been revoked that the user should be deleted</p><p>Learn more about <a href="/pages/zJwQEG15iEhbPYg9hpqp">Periodic User Cleanup &#x26; Deletion</a>.</p></td></tr><tr><td><strong>Custom Access Details</strong></td><td><p>(Optional) Instructions explaining how to access this integration's resources</p><p>Upon accessing an integration, a message with these instructions will be displayed to end users in the User Portal. The message may include up to <strong>400 characters</strong>.</p><p>To view the message as it appears to end users, click <strong>Preview</strong>.</p></td></tr><tr><td><strong>Integration Owner</strong></td><td><p>(Optional) Fallback approver if no <a href="/pages/Ey4wuziyr2BzKYQnd5am">resource owner</a> is found<br><br>Follow these steps to define one or several integration owners:</p><ol><li>From the <strong>Attribute</strong> dropdown menu, select <strong>User</strong> or <strong>Group</strong> under the relevant identity provider (IdP) platform.</li><li>From the <strong>Value</strong> dropdown menu, select one or multiple users or groups.</li></ol><p><br><strong>NOTE</strong>: When <strong>Resource Owner</strong> is defined, an <strong>Integration Owner</strong> must be defined.</p></td></tr><tr><td><strong>Resource Owner</strong></td><td><p>(Optional) Group or role responsible for managing access approvals or rejections for the resource<br><br>Follow these steps to define one or several <a href="/pages/Ey4wuziyr2BzKYQnd5am">resource owners</a>:</p><ol><li>Enter a <strong>Key name</strong>. This value is the name of the tag created in your cloud environment.</li><li>From the <strong>Attribute</strong> dropdown menu, select an attribute under the IdP platform to which the key name is associated.<br><br>Apono will use the value associated with the key (tag) to identify the resource owner. When you update the membership of the group or role in your IdP platform, this change is also reflected in Apono.</li></ol><p><br><strong>NOTE</strong>: When this setting is defined, an <strong>Integration Owner</strong> must also be defined.</p></td></tr></tbody></table>
11. Click **Confirm**.

<details>

<summary>💡Are you integrating with Apono using Terraform?</summary>

If you want to integrate with Apono using Terraform, follow these steps instead of clicking **Confirm**:

1. At the top of the screen, click **View as Code**. A modal appears with the completed Terraform configuration code.
2. Click to copy the code.
3. Make any additional edits.
4. Deploy the code in your Terraform.

Refer to [Integration Config Metadata](https://docs.apono.io/metadata-for-integration-config/integration-metadata/argocd) for more details about the schema definition.

</details>

Now that you have completed this integration, you can [create access flows](/docs/access-flows/access-flows.md) that grant permission to your ArgoCD resources.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.apono.io/docs/additional-integrations/development-tools/argocd.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.