Skip to main content
Argo CD has undergone rigorous internal security reviews and penetration testing to satisfy PCI compliance 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:

API Server

Exposes gRPC/REST API for UI, CLI, and CI/CD systems. Handles authentication, RBAC enforcement, and credential management.

Repository Server

Internal service with no Kubernetes privileges. Maintains Git repository cache and generates manifests.

Application Controller

Kubernetes controller that monitors applications and reconciles desired state with live state.

​
Component Communication

All network communication between components is performed over TLS:

​
Authentication

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

​
Token Types

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
Admin tokens previously did not expire. See CVE-2021-26921 for details.
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
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

​
Authorization

1

Extract JWT Claims

Extract group membership from JWT’s groups claim
2

Evaluate RBAC Policy

Compare each group against RBAC policy rules
3

Grant or Deny

Any matched rule permits access to the API request

​
TLS Configuration

Argo CD enforces TLS for all communications: 
# For argocd-server
argocd-server --tlsminversion 1.2
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.

​
Cluster RBAC

By default, Argo CD uses cluster-admin level privileges. However, permissions can be fine-tuned:
Edit the argocd-manager-role ClusterRole on the managed cluster:
kubectl edit clusterrole argocd-manager-role
Limit write privileges to specific namespaces and resources that Argo CD should manage.
Use resource exclusion to deny Argo CD access to specific resource kinds.

​
Threat Model

​
Git Repository Trust Boundary

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

​
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
Disable unused config management tools via Tool Detection settings.

​
Remote Bases and Dependencies

Limitation

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.

​
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
Git history shows changes in Git, not necessarily what was synced to clusters or when.

​
Kubernetes Events

Argo CD emits Kubernetes Events with actor information: 
kubectl get events -n argocd

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
Persist events long-term using Event Exporter or Event Router.

​
Security Log Levels

Security-related logs are tagged with a security field:
LevelSeverityDescriptionExample
1LowUnexceptional eventsSuccessful access
2MediumPotential malicious eventsAccess denied
3HighLikely malicious, blockedOut of bounds symlinks
4CriticalExploitable with side effectsSecrets left on filesystem
5EmergencyActive attack indicatorsAccount brute forcing
Applicable logs include a CWE field with the Common Weakness Enumeration number.

​
ApplicationSet Security

Only admins should have permissions to create, update, or delete ApplicationSets.
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 for detailed considerations.

​
Resource Limits

​
Directory App Memory Protection

Available in versions >2.2.10, >2.1.16, >2.3.5
Directory-type Applications can consume significant repo-server memory. Set limits in argocd-cmd-params-cm: 
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'
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.
Grant App creation privileges carefully—malicious users can increase memory usage by creating additional Applications.

​
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

Network Policies

Implement network policies to restrict access to Argo CD components

Least Privilege

Fine-tune ClusterRole permissions for managed clusters

Secret Management

Use external secret operators instead of storing secrets in Git

Tool Restrictions

Disable unnecessary config management tools

Audit Logging

Export and persist Kubernetes events for compliance

TLS Enforcement

Enable strict TLS validation between components

Secrets Management

Best practices for managing secrets in Argo CD

TLS Configuration

Configure TLS for all Argo CD components

Signed Releases

Verify Argo CD release artifacts and container images

RBAC Configuration

Configure role-based access control

Build docs developers (and LLMs) love

Get started for freeTalk to us