> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/argoproj/argo-cd/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Overview

> Argo CD security architecture, threat model, and core security principles

Argo CD has undergone rigorous internal security reviews and penetration testing to satisfy [PCI compliance](https://www.pcisecuritystandards.org) requirements. This page covers the security architecture, threat model, and implementation details of Argo CD.

## Architecture Overview

Argo CD consists of three main components, each with distinct security boundaries:

<CardGroup cols={3}>
  <Card title="API Server" icon="server">
    Exposes gRPC/REST API for UI, CLI, and CI/CD systems. Handles authentication, RBAC enforcement, and credential management.
  </Card>

  <Card title="Repository Server" icon="code-branch">
    Internal service with no Kubernetes privileges. Maintains Git repository cache and generates manifests.
  </Card>

  <Card title="Application Controller" icon="rotate">
    Kubernetes controller that monitors applications and reconciles desired state with live state.
  </Card>
</CardGroup>

### Component Communication

All network communication between components is performed over TLS:

```mermaid theme={null}
graph LR
    A[argocd-server] -->|TLS gRPC| B[argocd-repo-server]
    C[argocd-application-controller] -->|TLS gRPC| B
    A -->|HTTPS| D[argocd-dex-server]
    E[argocd-applicationset-controller] -->|TLS gRPC| B
```

## Authentication

Authentication to Argo CD API server is performed exclusively using [JSON Web Tokens](https://jwt.io) (JWTs). Username/password bearer tokens are not used.

### Token Types

<AccordionGroup>
  <Accordion title="Admin User Tokens">
    For the local `admin` user, credentials are exchanged for a JWT using the `/api/v1/session` endpoint.

    * **Signed by**: Argo CD API server
    * **Expiration**: 24 hours
    * **Storage**: Password stored as bcrypt hash in `argocd-secret`
    * **Revocation**: All admin tokens revoked when password is updated

    <Note>
      Admin tokens previously did not expire. See [CVE-2021-26921](https://github.com/argoproj/argo-cd/security/advisories/GHSA-9h6w-j7w4-jr52) for details.
    </Note>
  </Accordion>

  <Accordion title="Single Sign-On (SSO) Tokens">
    Users complete an OAuth2 login flow to a configured OIDC identity provider.

    * **Signed by**: Identity Provider (IDP)
    * **Expiration**: Managed by IDP (Dex tokens expire after 24 hours)
    * **Delegation**: Via bundled Dex provider or direct OIDC provider
    * **Revocation**: Handled by the identity provider
  </Accordion>

  <Accordion title="Automation Tokens (Project Tokens)">
    Generated for specific project roles using `/api/v1/projects/{project}/roles/{role}/token`.

    * **Signed by**: Argo CD API server
    * **Scope**: Limited to project resources only
    * **Expiration**: Configurable per token
    * **Revocation**: Delete JWT reference ID from project role
  </Accordion>
</AccordionGroup>

## Authorization

<Steps>
  <Step title="Extract JWT Claims">
    Extract group membership from JWT's `groups` claim
  </Step>

  <Step title="Evaluate RBAC Policy">
    Compare each group against [RBAC policy](/security/rbac) rules
  </Step>

  <Step title="Grant or Deny">
    Any matched rule permits access to the API request
  </Step>
</Steps>

## TLS Configuration

Argo CD enforces TLS for all communications:

<CodeGroup>
  ```bash Enforce TLS 1.2 theme={null}
  # For argocd-server
  argocd-server --tlsminversion 1.2
  ```

  ```bash Disable Insecure Mode theme={null}
  # Ensure TLS is enabled (default)
  argocd-server --insecure=false
  ```
</CodeGroup>

<Info>
  Service-to-service communication between all three components uses TLS by default. Redis communication uses plain HTTP by default but can be configured with TLS.
</Info>

## Cluster RBAC

By default, Argo CD uses cluster-admin level privileges. However, permissions can be fine-tuned:

<Tabs>
  <Tab title="Managed Clusters">
    Edit the `argocd-manager-role` ClusterRole on the managed cluster:

    ```bash theme={null}
    kubectl edit clusterrole argocd-manager-role
    ```

    Limit write privileges to specific namespaces and resources that Argo CD should manage.
  </Tab>

  <Tab title="Local Cluster">
    Edit ClusterRoles where Argo CD is running:

    ```bash theme={null}
    kubectl edit clusterrole argocd-server
    kubectl edit clusterrole argocd-application-controller
    ```
  </Tab>
</Tabs>

<Tip>
  Use [resource exclusion](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#resource-exclusioninclusion) to deny Argo CD access to specific resource kinds.
</Tip>

## Threat Model

### Git Repository Trust Boundary

<Warning>
  Gaining unauthorized write access to a git repository trusted by Argo CD has serious security implications.
</Warning>

#### Unauthorized Deployments

An attacker with write access to a trusted git repository can:

* Deploy malicious container images
* Modify resource configurations
* Delete resources (causing pruning in live environment)

#### Tool Command Invocation

Argo CD executes config management tools (`helm template`, `kustomize build`) to generate manifests. Malicious charts or kustomizations could:

* Attempt to read files out-of-tree
* Access adjacent git repositories
* Read files on the repo-server itself

<Tip>
  Disable unused config management tools via [Tool Detection](https://argo-cd.readthedocs.io/en/stable/user-guide/tool_detection/) settings.
</Tip>

#### Remote Bases and Dependencies

<Card title="Limitation" icon="triangle-exclamation">
  Argo CD's repository allow-list only restricts the initial repository. Both Kustomize and Helm can reference additional repositories:

  * Kustomize remote bases
  * Helm chart dependencies

  These referenced repositories may not be in the allow-list and may not be easily auditable.
</Card>

### Sensitive Information Protection

Argo CD never returns sensitive data from its API and redacts all sensitive data in payloads and logs:

* Cluster credentials
* Git credentials
* OAuth2 client secrets
* Kubernetes Secret values

## Auditing

### Git Audit Trail

Git commit history provides a natural audit log:

* **What**: Changes to application configuration
* **When**: Commit timestamps
* **Who**: Commit authors

<Note>
  Git history shows changes in Git, not necessarily what was synced to clusters or when.
</Note>

### Kubernetes Events

Argo CD emits Kubernetes Events with actor information:

```bash theme={null}
kubectl get events -n argocd
```

<CodeGroup>
  ```text Sample Events theme={null}
  LAST SEEN   TYPE      REASON              SOURCE                          MESSAGE
  1m          Normal    ResourceCreated     argocd-server                   admin created application
  1m          Normal    OperationStarted    argocd-server                   admin initiated sync to HEAD
  1m          Normal    OperationCompleted  argocd-application-controller   Sync operation succeeded
  ```
</CodeGroup>

<Tip>
  Persist events long-term using [Event Exporter](https://github.com/GoogleCloudPlatform/k8s-stackdriver/tree/master/event-exporter) or [Event Router](https://github.com/heptiolabs/eventrouter).
</Tip>

### Security Log Levels

Security-related logs are tagged with a `security` field:

| Level | Severity  | Description                   | Example                    |
| ----- | --------- | ----------------------------- | -------------------------- |
| 1     | Low       | Unexceptional events          | Successful access          |
| 2     | Medium    | Potential malicious events    | Access denied              |
| 3     | High      | Likely malicious, blocked     | Out of bounds symlinks     |
| 4     | Critical  | Exploitable with side effects | Secrets left on filesystem |
| 5     | Emergency | Active attack indicators      | Account brute forcing      |

<Info>
  Applicable logs include a `CWE` field with the [Common Weakness Enumeration](https://cwe.mitre.org/) number.
</Info>

## ApplicationSet Security

<Warning>
  **Only admins should have permissions to create, update, or delete ApplicationSets.**
</Warning>

ApplicationSets have elevated privileges:

* Can create Applications under arbitrary Projects
* Can quickly create/delete many Applications
* Can reveal privileged information (e.g., reading Secrets via git generator)

See [ApplicationSet Security](/security/applicationsets) for detailed considerations.

## Resource Limits

### Directory App Memory Protection

<Note>
  Available in versions >2.2.10, >2.1.16, >2.3.5
</Note>

Directory-type Applications can consume significant repo-server memory. Set limits in `argocd-cmd-params-cm`:

```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  # Limit combined size of JSON/YAML files per app
  reposerver.max.combined.directory.manifests.size: '3M'
```

<Accordion title="Memory Calculation Example">
  For a repo-server with 10G memory limit and 10 directory Applications:

  ```
  10G / (300 * 10) = 3M per app
  ```

  The 300x ratio assumes worst-case memory growth for maliciously-crafted manifests.
</Accordion>

<Warning>
  Grant [App creation privileges](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/) carefully—malicious users can increase memory usage by creating additional Applications.
</Warning>

## WebHook Security

Webhook payloads are treated as untrusted:

* Argo CD only examines the payload to identify involved applications
* Triggers the same refresh that occurs at regular 3-minute intervals
* No privileged operations are performed based on webhook content

## Best Practices

<CardGroup cols={2}>
  <Card title="Network Policies" icon="shield">
    Implement network policies to restrict access to Argo CD components
  </Card>

  <Card title="Least Privilege" icon="user-lock">
    Fine-tune ClusterRole permissions for managed clusters
  </Card>

  <Card title="Secret Management" icon="key">
    Use external secret operators instead of storing secrets in Git
  </Card>

  <Card title="Tool Restrictions" icon="wrench">
    Disable unnecessary config management tools
  </Card>

  <Card title="Audit Logging" icon="list-check">
    Export and persist Kubernetes events for compliance
  </Card>

  <Card title="TLS Enforcement" icon="lock">
    Enable strict TLS validation between components
  </Card>
</CardGroup>

## Related Resources

<CardGroup cols={2}>
  <Card title="Secrets Management" icon="vault" href="/security/secrets-management">
    Best practices for managing secrets in Argo CD
  </Card>

  <Card title="TLS Configuration" icon="certificate" href="/security/tls">
    Configure TLS for all Argo CD components
  </Card>

  <Card title="Signed Releases" icon="file-signature" href="/security/signed-releases">
    Verify Argo CD release artifacts and container images
  </Card>

  <Card title="RBAC Configuration" icon="users" href="/configuration/rbac">
    Configure role-based access control
  </Card>
</CardGroup>
