hacktricks-cloud/src/pentesting-ci-cd/argocd-security.md

Argo CD Security

{{#include ../banners/hacktricks-training.md}}

Basic Information

Argo CD 是一个用于 Kubernetes 的 GitOps continuous delivery platform。它监视 Git repositories，使用 Helm、Kustomize、Jsonnet 或 config management plugins 等工具渲染 Kubernetes manifests，并将 live cluster state 与 Git 中存储的 desired state 进行协调。

从攻击者的角度来看，应将 Argo CD 视为一个拥有 Kubernetes credentials 的 deployment engine。一次有效的 Argo CD compromise 可能导致：

• 访问 private Git repositories 和 repository credentials。
• 访问 Argo CD 使用的 Kubernetes cluster secrets。
• 在 argocd-repo-server 中执行 manifest generation code。
• 通过受信任的 Git repositories、Argo CD applications 或 cache manipulation，未经授权地部署 Kubernetes objects。

Architecture & Interesting Components

常见的 Kubernetes objects 和 services：

kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
kubectl get applications,appprojects,applicationsets -A 2>/dev/null
kubectl get secrets,configmaps -n argocd 2>/dev/null
kubectl get networkpolicy -n argocd 2>/dev/null

值得关注的服务：

• argocd-server：公共 API、web UI、CLI API、身份验证和授权。
• argocd-application-controller：比较期望状态和实际状态，然后将资源应用到 Kubernetes。
• argocd-repo-server：克隆仓库、缓存 Git 数据，并运行 Helm/Kustomize/Jsonnet/plugins 以生成 manifests。默认 gRPC 端口为 8081。
• argocd-redis：用于缓存 application、manifest 和 Git reference 数据。默认 Redis 端口为 6379。
• argocd-applicationset-controller：根据 Git、SCM、clusters 和 pull requests 等 generators 生成 Argo CD Application 对象。

从已被攻陷的 pod 或内部网络 segment 中，检查内部可达性：

nc -vz <argocd-server> 443
nc -vz <argocd-repo-server> 8081
nc -vz <argocd-redis> 6379

Public API / UI 攻击

如果你拥有 Argo CD credentials 或发现了暴露的实例，请从常规 API surface 开始：

argocd login <argocd-server>
argocd account get-user-info
argocd account list
argocd proj list
argocd app list
argocd repo list
argocd cluster list
argocd admin settings rbac can <subject> <action> <resource> <object>

有用的攻击路径：

• Application 写入权限：修改 source.repoURL、source.path、Helm values、Kustomize options、plugin settings 或 sync options，使 Argo CD 部署攻击者控制的 manifests。
• Project 配置错误：AppProject objects 可能允许宽泛的 sourceRepos、宽泛的 destinations、不安全的 clusterResourceWhitelist 或薄弱的 namespace restrictions。
• Repository credential abuse：repository secrets、GitHub App credentials、SSH keys 和 tokens 可能允许向受信任的 repos 推送内容或添加恶意 dependencies。
• Cluster credential abuse：cluster secrets 可能包含 bearer tokens 或 exec-provider configuration，供 Argo CD 部署到目标 clusters。
• Local admin / project tokens：长期有效的 Argo CD tokens 可通过 API 重用，除非已被 revoke 或过期。

当你拥有 cluster read access 时，从 Kubernetes 枚举 configuration：

kubectl get applications.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml
kubectl get applicationsets.argoproj.io -A -o yaml
kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml

Trusted Git Repository Abuse

如果你可以向 Argo CD 信任的 repository push，通常就能影响部署的内容。影响取决于 AppProject 的边界，以及 application controller 使用的 service account 权限。

常见的 payload 位置：

• application path 下的原始 Kubernetes YAML。
• Helm chart templates 和 values.yaml。
• Kustomize overlays、remote bases 和 generators。
• Jsonnet 或 config management plugin 的输入。
• 用于创建或更新 Application 对象的 ApplicationSet generator 文件。

检查应用是否使用 automated sync、pruning、self-heal、sync windows 或 manual approvals：

kubectl get applications.argoproj.io -A \
-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'

直接滥用 argocd-repo-server

不要假设 public Argo CD API 是唯一的攻击面。Argo CD 内部组件通过 gRPC 与 argocd-repo-server 通信。如果任意 pod 都能访问 repo-server，攻击者控制的内部请求可能绕过通常由 argocd-server 强制执行的检查。

实用检查：

kubectl get svc -n argocd argocd-repo-server -o yaml
kubectl get endpoints -n argocd argocd-repo-server -o wide
nc -vz <argocd-repo-server> 8081

值得关注的迹象：

• repo-server gRPC endpoint 可从非 Argo CD pods 访问。
• 缺少 NetworkPolicies，或仅允许 egress 白名单而未拒绝 ingress。
• repo-server 可访问 custom config management plugins、decryption tools，或来自多个 tenants 的 repository 内容。
• Redis 可从非 Argo CD pods 访问；如果凭据可用或不需要凭据，可能允许进行 cache inspection 或 tampering。

未认证的 Repo-Server RCE via Kustomize Options

2026 年 7 月，Synacktiv 披露了 Argo CD 中的一条未认证 code execution chain：当攻击者能够访问内部 gRPC service 时，可对 repo-server 发起攻击。该攻击滥用对 /repository.RepoServerService/GenerateManifest 的直接访问，以及由攻击者控制的 KustomizeOptions。

其中的危险 primitive 是强制 repo-server clone 由攻击者控制的 repository 内容，并运行带 Helm support 的 Kustomize：

kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh

最小恶意 Kustomize 输入需要触发 Helm 处理：

helmCharts:
- name: pwn
version: 0.0.1

为什么这能生效：

• argocd-repo-server 会在渲染前 clone repository。
• --helm-command ./payload.sh 会解析为相对于 cloned repository 的路径。
• 如果 attacker 能够控制 rendered repository 和 Kustomize build options，则无需注入 shell metacharacter 也能实现 code execution。

在 Synacktiv 于 2026 年 7 月 1 日披露时，他们报告称该问题尚无官方修复或 CVE。应首先将其视为 network-exposure issue：利用需要能够访问内部 repo-server gRPC port。

Redis Cache Poisoning to Deploy Manifests

在 argocd-repo-server 中实现 code execution 后，或使用有效 credentials 直接访问 Redis 后，检查 Redis-backed cache entries。Argo CD 通常会存储 gzip-compressed JSON values。

Interesting key prefixes:

mfst|...       # cached rendered manifests
git-refs|...   # Git branch/ref to commit mappings
app|...        # application resource/cache data
cluster|...    # cluster cache information

Synacktiv 描述的 cache poisoning attack 滥用了两部分状态：

1. 修改相关的 mfst|... manifest cache 条目，使其包含攻击者控制的 Kubernetes manifest。
2. 修改相关的 git-refs|... 映射，使 Argo CD 认为分支已发生移动，然后重新 reconcile 到缓存的 revision。

影响：

• 启用 Auto Sync 时，Argo CD 可能会自动应用被污染的缓存 manifest。
• 未启用 Auto Sync 时，用户手动 sync application 仍可能应用 payload。
• 最终影响受目标 application 的 destination 以及 Argo CD 可用的 Kubernetes 权限限制。

ApplicationSet Attacks

ApplicationSet 尤其敏感，因为它会根据 generator 输出创建或更新 Application 对象。

检查：

kubectl get applicationsets.argoproj.io -A -o yaml
kubectl get appprojects.argoproj.io -A -o yaml

有趣的模式：

• Git generators 读取 attacker-writable files，而这些文件可控制 app names、paths、projects 或 destinations。
• 面向 public repositories 的 Pull request generators，其中 untrusted contributors 可以影响生成的 applications。
• 允许使用 broad destination clusters/namespaces 的 Template fields。
• 允许 sourceRepos: ["*"] 或 broad destinations 的 AppProjects。
• 继承 automated sync 和 pruning 的 Generated applications。

Post-Exploitation

从 Argo CD pod shell 中，优先检查：

env
cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
mount | grep -E 'secret|token|config'

有用的目标：

• 窃取 REDIS_PASSWORD 或 Redis TLS/client material。
• 从挂载的 secrets 或 Argo CD Kubernetes secrets 中提取 repository credentials。
• 识别 Argo CD 使用的 cluster credentials。
• 读取生成的 manifests 和 plugin output，其中可能包含注入的 secrets。
• 检查 custom plugins、SOPS、Helm secrets、Vault plugins 或 cloud CLIs 是否暴露 decryption keys 和 cloud credentials。

Detection & Hardening

重要检查项：

• 使用 NetworkPolicies 限制 argocd-repo-server 端口 8081 和 Redis 端口 6379，确保只有预期的 Argo CD 组件可以访问它们。
• 在 Helm deployments 中，确认确实创建了 network policies。Argo CD Helm chart 的 values 长期以来默认将 component network policy creation 设置为 disabled。
• 保持 argocd-server 作为经过认证的入口点。内部服务不应被任意 workloads 访问。
• Disable 未使用的 config management tools 和 plugins。
• 限制 AppProject 的 sourceRepos、destinations、namespace permissions 和 cluster-scoped resources。
• 避免将 broad repository credentials 存储在低权限 Argo CD user 可以促使其复用的位置。
• 监控 repo-server requests、Kustomize build options、plugin executions、Redis writes，以及对 mfst| / git-refs| keys 的异常访问。
• 在发生 compromise 后，rotate Argo CD local users、project tokens、repository credentials 和 cluster credentials。

有用的命令：

kubectl get networkpolicy -n argocd
kubectl get networkpolicy -A | grep -i argocd
kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null

CodeQL 中的 Static Analysis Note：Typed API Requests

对于使用 gRPC/REST handlers 的 Go services，当 raw input 被 unmarshaled 到 typed request objects 后，默认的 CodeQL remote sources 可能会遗漏 flows。对于 Argo CD-style services，一个有用的 model 是：

• Receiver type，例如 Server 或 Service。
• First parameter 是 context.Context。
• Second parameter 是 typed request object。

将 second parameter model 为 remote source，并为 exec.Command / exec.CommandContext arguments 添加 custom sinks。这有助于发现从 internal API request fields 流向 command execution helpers 的 flows。

References

• Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL
• Argo CD docs - Security considerations
• Argo CD docs - High Availability
• Argo CD docs - repo-server command reference
• Argo CD - repo-server NetworkPolicy manifest
• Argo CD docs - metrics
• Argo Helm - chart values reference
• Kustomize - Helm chart generator example {{#include ../banners/hacktricks-training.md}}