Translated ['src/pentesting-ci-cd/argocd-security.md', 'src/pentesting-c

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

@@ -0,0 +1,219 @@
+# Argo CD Security
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Basic Information
+
+[Argo CD](https://argo-cd.readthedocs.io/) 是一个面向 Kubernetes 的 GitOps continuous delivery platform。它会监视 Git repositories，使用 Helm、Kustomize、Jsonnet 或 config management plugins 等工具渲染 Kubernetes manifests，并将 live cluster state 与存储在 Git 中的 desired state 进行 reconcile。
+
+从攻击者视角来看，应将 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。
+- 通过 trusted Git repositories、Argo CD applications 或 cache manipulation 非授权部署 Kubernetes objects。
+
+## Architecture & Interesting Components
+
+Common Kubernetes objects and services:
+```bash
+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`**: public API、web UI、CLI API、authentication 和 authorization。
+- **`argocd-application-controller`**: 比较 desired 和 live state，然后将 resources 应用到 Kubernetes。
+- **`argocd-repo-server`**: clones repositories，缓存 Git data，并运行 Helm/Kustomize/Jsonnet/plugins 以生成 manifests。默认 gRPC 端口是 **8081**。
+- **`argocd-redis`**: application、manifest 和 Git reference data 的 cache。默认 Redis 端口是 **6379**。
+- **`argocd-applicationset-controller`**: 从 Git、SCM、clusters 和 pull requests 等 generators 生成 Argo CD `Application` objects。
+
+从被 compromise 的 pod 或 internal network segment 中，检查 internal reachability：
+```bash
+nc -vz <argocd-server> 443
+nc -vz <argocd-repo-server> 8081
+nc -vz <argocd-redis> 6379
+```
+## Public API / UI 攻击
+
+如果你有 Argo CD credentials 或一个暴露的 instance，先从 normal API surface 开始：
+```bash
+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>
+```
+有用的 attack paths：
+
+- **Application write access**: 修改 `source.repoURL`、`source.path`、Helm values、Kustomize 选项、plugin settings 或 sync options，让 Argo CD 部署 attacker-controlled manifests。
+- **Project misconfiguration**: `AppProject` objects 可能允许过宽的 `sourceRepos`、过宽的 `destinations`、不安全的 `clusterResourceWhitelist`，或薄弱的 namespace restrictions。
+- **Repository credential abuse**: repository secrets、GitHub App credentials、SSH keys 和 tokens 可能允许向受信任的 repos 推送，或添加 malicious dependencies。
+- **Cluster credential abuse**: cluster secrets 可能包含 bearer tokens 或 exec-provider configuration，供 Argo CD 用于部署到 target clusters。
+- **Local admin / project tokens**: 长期有效的 Argo CD tokens 除非被 revoke 或 expired，否则可以通过 API 重用。
+
+当你拥有 cluster read access 时，枚举 Kubernetes 中的配置：
+```bash
+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
+
+如果你可以 push 到一个被 Argo CD trusted 的 repository，你通常可以影响部署内容。影响取决于 `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` objects 的 ApplicationSet generator files。
+
+检查 app 是否使用 automated sync、pruning、self-heal、sync windows 或 manual approvals：
+```bash
+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`
+
+不要假设公开的 Argo CD API 是唯一的攻击面。内部 Argo CD 组件通过 gRPC 与 `argocd-repo-server` 通信。若任意 pods 能够访问 repo-server，攻击者控制的内部请求可能绕过通常由 `argocd-server` 强制执行的检查。
+
+实际检查：
+```bash
+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
+```
+Interesting signs:
+
+- repo-server gRPC endpoint 可从非 Argo CD pods 访问。
+- NetworkPolicies 缺失，或只允许 allow-list egress 但未拒绝 ingress。
+- repo-server 可访问自定义 config management plugins、decryption tools，或来自多个 tenant 的 repository content。
+- Redis 可从非 Argo CD pods 访问；如果 credentials 可用或不需要，就可能进行 cache inspection 或 tampering。
+
+## 通过 Kustomize Options 实现未认证的 Repo-Server RCE
+
+在 2026 年 7 月，Synacktiv 披露了 Argo CD 的 `repo-server` 中一条未认证 code execution 链，当 attacker 能访问内部 gRPC service 时即可触发。该攻击滥用对 `/repository.RepoServerService/GenerateManifest` 的直接访问，以及 attacker-controlled 的 `KustomizeOptions`。
+
+危险的 primitive 是强制 repo-server clone attacker-controlled repository content，并在启用 Helm support 的情况下运行 Kustomize：
+```bash
+kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
+```
+触发 Helm 处理所需的最小恶意 Kustomize 输入：
+```yaml
+helmCharts:
+- name: pwn
+version: 0.0.1
+```
+为什么这可行：
+
+- `argocd-repo-server` 会在渲染之前先 clone 该 repository。
+- `--helm-command ./payload.sh` 会相对于已 clone 的 repository 来解析。
+- 如果 attacker 能控制被渲染的 repository 和 Kustomize build options，就不需要 shell metacharacter injection 也能实现 Code execution。
+
+在 Synacktiv 于 2026 年 7 月 1 日披露时，他们报告该问题没有官方修复或 CVE。应首先将其视为一个网络暴露问题：exploitation 需要能够访问内部的 repo-server gRPC 端口。
+
+## Redis Cache Poisoning to Deploy Manifests
+
+在 `argocd-repo-server` 中实现 Code execution 后，或者在使用有效凭据直接访问 Redis 后，检查 Redis-backed cache entries。Argo CD 通常会存储 gzip-compressed JSON values。
+
+有趣的 key prefixes：
+```text
+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 entry，以包含攻击者控制的 Kubernetes manifest。
+2. 修改相关的 `git-refs|...` mapping，让 Argo CD 认为 branch 已移动，然后再回滚到缓存的 revision。
+
+影响：
+
+- 启用 Auto Sync 时，Argo CD 可能会自动应用被污染的 cached manifest。
+- 未启用 Auto Sync 时，当用户手动 sync 该 application 时，payload 仍可能被应用。
+- 最终影响受目标 application 的 destination 以及 Argo CD 可用的 Kubernetes permissions 限制。
+
+## ApplicationSet Attacks
+
+ApplicationSet 尤其敏感，因为它会根据 generator output 创建或更新 `Application` objects。
+
+Review:
+```bash
+kubectl get applicationsets.argoproj.io -A -o yaml
+kubectl get appprojects.argoproj.io -A -o yaml
+```
+Interesting patterns:
+
+- Git generators reading attacker-writable files that control app names, paths, projects or destinations.
+- Pull request generators for public repositories where untrusted contributors can influence generated applications.
+- Template fields that allow broad destination clusters/namespaces.
+- AppProjects that permit `sourceRepos: ["*"]` or broad `destinations`.
+- Generated applications that inherit automated sync and pruning.
+
+## Post-Exploitation
+
+From an Argo CD pod shell, prioritize:
+```bash
+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 材料。
+- 从挂载的 secrets 或 Argo CD Kubernetes secrets 中提取 repository credentials。
+- 识别 Argo CD 使用的 cluster credentials。
+- 读取生成的 manifests 和可能包含注入 secrets 的 plugin output。
+- 检查 custom plugins、SOPS、Helm secrets、Vault plugins 或 cloud CLIs 是否暴露了 decryption keys 和 cloud credentials。
+
+## 检测与加固
+
+重要检查：
+
+- 通过 NetworkPolicies 限制 `argocd-repo-server` 端口 **8081** 和 Redis 端口 **6379**，确保只有预期的 Argo CD 组件可以访问它们。
+- 在 Helm deployments 中，确认 network policies 确实被创建。Argo CD Helm chart values 过去通常将组件 network policy creation 默认设为 disabled。
+- 将 `argocd-server` 保持为经过认证的入口点。内部服务不应能被任意 workloads 访问。
+- 禁用未使用的 config management tools 和 plugins。
+- 限制 `AppProject` 的 `sourceRepos`、`destinations`、namespace permissions 和 cluster-scoped resources。
+- 避免存储过于宽泛的 repository credentials，以免被低权限 Argo CD user 触发复用。
+- 监控 repo-server requests、Kustomize build options、plugin executions、Redis writes，以及对 `mfst|` / `git-refs|` keys 的异常访问。
+- 在发生 compromise 后，轮换 Argo CD local users、project tokens、repository credentials 和 cluster credentials。
+
+有用的命令：
+```bash
+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
+```
+## Static Analysis Note: Typed API Requests in CodeQL
+
+对于使用 gRPC/REST handlers 的 Go services，默认的 CodeQL remote sources 可能会在原始输入被 unmarshaled 成 typed request objects 之后漏掉 flows。对 Argo CD 风格的 services，一个有用的 model 是：
+
+- Receiver type 例如 `Server` 或 `Service`。
+- 第一个参数是 `context.Context`。
+- 第二个参数是 typed request object。
+
+把这个第二个参数建模为 remote source，并为 `exec.Command` / `exec.CommandContext` arguments 添加 custom sinks。这有助于发现从内部 API request fields 到 command execution helpers 的 flows。
+
+## References
+
+- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
+- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
+- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
+- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
+- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
+- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
+- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
+- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -6,51 +6,51 @@
 
 ## VCS
 
-VCS 代表 **Version Control System**，这个系统允许开发者 **管理他们的源代码**。最常见的是 **git**，你通常会发现公司在以下 **platforms** 之一中使用它：
+VCS 代表 **Version Control System**，这个系统允许开发者 **管理他们的源代码**。最常见的是 **git**，你通常会发现公司在以下 **platforms** 中使用它：
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
 - Gitblit
-- Cloud providers (they offer their own VCS platforms)
+- Cloud providers (他们提供自己的 VCS platforms)
 
 
 ## CI/CD Pipelines
 
-CI/CD pipelines 使开发者能够为各种目的 **自动执行代码**，包括构建、测试和部署应用程序。这些自动化工作流会被**特定操作触发**，例如代码 push、pull requests 或计划任务。它们有助于简化从开发到生产的流程。
+CI/CD pipelines 使开发者能够为各种目的 **自动执行代码**，包括构建、测试和部署应用程序。这些自动化工作流会被 **特定操作触发**，例如代码推送、pull requests，或定时任务。它们有助于简化从开发到生产的流程。
 
-然而，这些系统需要在某个地方**执行**，而且通常需要使用**特权凭证来部署代码或访问敏感信息**。
+然而，这些系统需要在 **某个地方执行**，而且通常需要 **特权凭证** 来部署代码或访问敏感信息。
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> 即使某些 VCS platforms 允许为这一节创建 pipelines，我们这里也只分析对源代码控制的潜在攻击。
+> 即使某些 VCS platforms 允许创建 pipelines，我们在这一部分也只分析对源代码控制的潜在攻击。
 
-包含项目源代码的平台包含敏感信息，且人们需要非常谨慎地管理在这个平台内授予的权限。以下是 attacker 可能利用的 VCS platforms 中一些常见问题：
+包含项目源代码的平台会包含敏感信息，因此人们必须非常谨慎地管理授予该平台内的权限。以下是攻击者可能利用的一些常见 VCS platform 问题：
 
-- **Leaks**: 如果你的代码在 commits 中包含 leaks，并且 attacker 可以访问 repo（因为它是公开的，或者因为他有访问权限），他就可能发现这些 leaks。
-- **Access**: 如果 attacker 能够 **访问 VCS platform 内的一个 account**，他就可以获得 **更多可见性和权限**。
-- **Register**: 一些平台会直接允许外部用户创建 account。
-- **SSO**: 一些平台不允许用户注册，但会允许任何拥有有效 SSO 的人访问（例如 attacker 可以用他的 github account 进入）。
-- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... 有多种 token 可被用户窃取，从而以某种方式访问 repo。
-- **Webhooks**: VCS platforms 允许生成 webhooks。如果它们**没有**用不可见的 secrets 保护，**attacker could abuse them**。
-- 如果没有 secret，attacker 可以滥用第三方平台的 webhook
-- 如果 secret 在 URL 中，情况也一样，而且 attacker 还能拿到这个 secret
-- **Code compromise:** 如果恶意行为者对 repos 拥有某种 **write** 权限，他可能尝试 **inject malicious code**。为了成功，他可能需要 **bypass branch protections**。这些动作可以基于不同目标执行：
-- 破坏 main branch 以 **compromise production**。
-- 破坏 main（或其他 branches）以 **compromise developers machines**（因为他们通常会在自己的机器上执行 test、terraform 或 repo 内的其他内容）。
-- **Compromise the pipeline**（查看下一节）
+- **Leaks**: 如果你的代码在 commits 中包含 leaks，并且攻击者能够访问 repo（因为它是公开的，或者因为他有访问权限），他就可以发现这些 leaks。
+- **Access**: 如果攻击者能够 **访问 VCS platform 中的一个账户**，他就可能获得 **更多可见性和权限**。
+- **Register**: 某些 platforms 允许外部用户直接创建账户。
+- **SSO**: 某些 platforms 不允许用户注册，但会允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账户进入）。
+- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... 有多种 token，用户可能会窃取这些 token 以某种方式访问 repo。
+- **Webhooks**: VCS platforms 允许生成 webhooks。如果它们 **没有** 使用不可见的 secrets 进行保护，**攻击者就可以滥用它们**。
+- 如果没有设置 secret，攻击者就可以滥用第三方 platform 的 webhook
+- 如果 secret 在 URL 中，情况也一样，而且攻击者还能拿到该 secret
+- **Code compromise:** 如果恶意行为者对 repos 拥有某种 **write** 访问，他可能会尝试 **注入恶意代码**。为了成功，他可能需要 **绕过 branch protections**。这些操作可能出于不同目的：
+- 破坏 main branch 以 **破坏生产环境**。
+- 破坏 main（或其他 branches）以 **破坏开发者机器**（因为他们通常会在自己的机器上在 repo 内执行测试、terraform 或其他内容）。
+- **破坏 pipeline**（见下一节）
 
 ## Pipelines Pentesting Methodology
 
-定义 pipeline 最常见的方式，是使用一个**托管在该 pipeline 所构建仓库中的 CI configuration file**。这个文件描述了执行 jobs 的顺序、影响流程的条件，以及 build environment settings。\
-这些文件通常有固定的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML files。触发后，pipeline job 会**从选定的 source 拉取代码**（例如 commit / branch），并针对该代码**运行 CI configuration file 中指定的 commands**。
+定义 pipeline 最常见的方法，是使用一个 **托管在 pipeline 构建的 repository 中的 CI configuration file**。这个文件描述已执行 jobs 的顺序、影响流程的条件，以及构建环境设置。\
+这些文件通常具有一致的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML files。被触发时，pipeline job 会从所选 source（例如 commit / branch）**拉取代码**，并针对该代码 **运行 CI configuration file 中指定的 commands**。
 
-因此，attacker 的最终目标是以某种方式**compromise 这些 configuration files** 或它们执行的**commands**。
+因此，攻击者的最终目标是以某种方式 **破坏这些 configuration files** 或 **它们执行的 commands**。
 
 > [!TIP]
-> 一些 hosted builders 允许贡献者选择 Docker build context 和 Dockerfile path。如果 context 可由 attacker 控制，你可以将其设置到 repo 之外（例如 ".."），从而在 build 过程中提取 host files 并 exfiltrate secrets。参见：
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
 >
 >{{#ref}}
 >docker-build-context-abuse.md
@@ -58,67 +58,68 @@ CI/CD pipelines 使开发者能够为各种目的 **自动执行代码**，包
 
 ### PPE - Poisoned Pipeline Execution
 
-Poisoned Pipeline Execution (PPE) 路径利用 SCM repository 中的权限来操纵 CI pipeline 并执行恶意 commands。具有必要权限的用户可以修改 CI configuration files 或 pipeline job 使用的其他文件，以包含恶意 commands。这样就会“poison” CI pipeline，并导致这些恶意 commands 被执行。
+Poisoned Pipeline Execution (PPE) 路径利用 SCM repository 中的权限来操纵 CI pipeline 并执行有害 commands。拥有必要权限的用户可以修改 CI configuration files 或 pipeline job 使用的其他 files，以包含恶意 commands。这样就“污染”了 CI pipeline，导致这些恶意 commands 被执行。
 
 要成功执行 PPE attack，恶意行为者需要能够：
 
-- 拥有对 VCS platform 的 **write access**，因为 pipeline 通常在 push 或 pull request 执行时触发。（查看 VCS pentesting methodology 以总结获取访问权限的方法）。
+- 在 VCS platform 上拥有 **write access**，因为通常 pipelines 会在 push 或 pull request 被执行时触发。（查看 VCS pentesting methodology 以了解获取访问权限的方式总结）。
 - 注意，有时 **external PR 也算作 "write access"**。
-- 即使他有 write permissions，他也需要确保自己能 **modify CI config file 或 config 依赖的其他文件**。
-- 为此，他可能需要能够 **bypass branch protections**。
+- 即使他有 write permissions，他也需要确保自己能够 **修改 CI config file 或 config 依赖的其他 files**。
+- 为此，他可能需要能够 **绕过 branch protections**。
 
-PPE 有 3 种变体：
+PPE 有 3 种形式：
 
-- **D-PPE**: 当行为者 **修改将要执行的 CI config** file 时，就发生 **Direct PPE** attack。
-- **I-DDE**: 当行为者 **修改** 将要执行的 CI config file **依赖** 的一个 **file** 时，就发生 **Indirect PPE** attack（例如 make file 或 terraform config）。
-- **Public PPE or 3PE**: 在某些情况下，pipeline 可能会被**没有 repo write access 的用户**（甚至可能不是 org 的一部分）触发，因为他们可以发送 PR。
-- **3PE Command Injection**: 通常，CI/CD pipelines 会基于 PR 的信息**设置 environment variables**。如果某个值能被 attacker 控制（比如 PR 的标题），并且在**危险位置**被**使用**（比如执行 **sh commands**），attacker 可能会在其中**inject commands**。
+- **D-PPE**: 当行为者 **修改** 将要执行的 CI config 文件时，会发生 **Direct PPE** attack。
+- **I-DDE**: 当行为者 **修改** 将要执行的 CI config file 所 **依赖** 的某个 **file** 时，会发生 **Indirect PPE** attack（例如 make file 或 terraform config）。
+- **Public PPE or 3PE**: 在某些情况下，pipelines 可以被 **没有 repo write access 的用户触发**（他们甚至可能不属于该 org），因为他们可以发送 PR。
+- **3PE Command Injection**: 通常，CI/CD pipelines 会 **设置 environment variables**，其中包含有关 PR 的 **信息**。如果该值可被攻击者控制（例如 PR 的标题），并且在 **危险位置** 被 **使用**（例如执行 **sh commands**），攻击者可能会在其中 **注入 commands**。
 
 ### Exploitation Benefits
 
-了解 poison pipeline 的 3 种变体后，看看成功利用后 attacker 能得到什么：
+了解污染 pipeline 的 3 种形式后，接下来看看攻击者在成功利用后可以获得什么：
 
-- **Secrets**: 如前所述，pipelines 运行它们的 jobs 需要**特权**（获取代码、构建、部署等），而这些特权通常会以 **secrets** 形式提供。这些 secrets 通常可通过 **env variables 或系统内文件**访问。因此 attacker 总会尝试尽可能多地 exfiltrate secrets。
-- 根据 pipeline platform 的不同，attacker **可能需要在 config 中指定 secrets**。这意味着如果 attacker 不能修改 CI configuration pipeline（例如 **I-PPE**），他就**只能 exfiltrate 该 pipeline 已有的 secrets**。
-- **Computation**: 代码在某处执行，取决于执行位置，attacker 可能进一步 pivot。
-- **On-Premises**: 如果 pipelines 在本地环境执行，attacker 可能最终进入一个**内部网络，并能访问更多资源**。
-- **Cloud**: attacker 可能访问 cloud 中的**其他机器**，同时也可能从中 **exfiltrate** IAM roles/service accounts **tokens**，以获得 cloud 内部的**进一步访问**。
-- **Platforms machine**: 有时 jobs 会在 **pipelines platform machines** 内执行，这些机器通常位于 cloud 中，但**没有更多访问权限**。
-- **Select it:** 有时 **pipelines platform 会配置多台机器**，如果你可以 **modify the CI configuration file**，你就可以 **indicate where you want to run the malicious code**。在这种情况下，attacker 很可能会在每台可能的机器上运行 reverse shell，以尝试进一步利用。
-- **Compromise production**: 如果你在 pipeline 内，而且最终版本是由它构建并部署的，你就可以 **compromise 将在 production 中运行的代码**。
+- **Secrets**: 如前所述，pipelines 的 jobs 需要 **权限**（检索代码、构建、部署等），而这些权限通常以 **secrets** 形式授予。这些 secrets 通常可以通过 **env variables 或系统内的 files** 访问。因此，攻击者总会尝试尽可能多地外传 secrets。
+- 根据 pipeline platform 的不同，攻击者 **可能需要在 config 中指定 secrets**。这意味着如果攻击者无法修改 CI configuration pipeline（例如 **I-PPE**），他就 **只能外传该 pipeline 已有的 secrets**。
+- **Computation**: 代码会在某处执行，根据执行位置，攻击者可能能够进一步 pivot。
+- **On-Premises**: 如果 pipelines 在本地环境执行，攻击者可能最终进入一个 **内部网络，并访问更多资源**。
+- **Cloud**: 攻击者不仅可以访问 cloud 中的 **其他 machines**，还可以从中 **外传** IAM roles/service accounts **tokens**，以获得 cloud 内部的进一步访问权限。
+- **Platforms machine**: 有时 jobs 会在 **pipelines platform machines** 内执行，这些机器通常位于一个 cloud 中，并且 **没有更多访问权限**。
+- **Select it:** 有时 **pipelines platform 会配置多台 machines**，如果你能 **修改 CI configuration file**，你就可以 **指定想要在哪台机器上运行恶意代码**。在这种情况下，攻击者很可能会在每一台可能的机器上运行 reverse shell，以尝试进一步利用它。
+- **Compromise production**: 如果你在 pipeline 中，并且最终版本是从那里构建和部署的，你就可以 **破坏最终会在 production 中运行的代码**。
 
 ### Dependency & Registry Supply-Chain Abuse
 
-攻陷 CI/CD pipeline 或从中窃取凭证，可能让 attacker 从 **pipeline execution** 进一步走向 **ecosystem-wide code execution**，方法是对 dependencies 或 release tooling 做后门植入：
+破坏 CI/CD pipeline 或从中窃取凭证，可能让攻击者通过后门化 dependencies 或 release tooling，从 **pipeline execution** 转向 **ecosystem-wide code execution**：
 
-- **Install-time code execution via package hooks**: 发布一个 package version，添加 `preinstall`、`postinstall`、`prepare` 或类似 hooks，使 payload 在 developer workstations 和 CI runners 上的 dependency installation 期间自动运行。
-- **Secondary execution paths**: 即使目标使用 `--ignore-scripts` 安装，恶意 package 仍可在 `bin` 字段中注册一个 **common CLI name**，这样 attacker 控制的 wrapper 会被 symlink 到 `PATH` 中，并在之后命令被使用时执行。
-- **Runtime bootstrapping**: 一个小型 installer 可以在安装期间下载第二个 runtime 或 toolchain（例如 Bun 或打包过的 interpreter），然后用它启动主 payload，从而避免本地依赖要求。
-- **Credential harvesting from build environments**: 一旦代码在 CI 中运行，检查 environment variables、`~/.npmrc`、`~/.git-credentials`、SSH keys、cloud CLI configs，以及诸如 `gh auth token` 的本地工具。在 GitHub Actions 上，也要查看 runner-specific secrets 和 artifacts。
-- **Workflow injection with stolen GitHub tokens**: 拥有 **`repo` + `workflow`** 权限的 token 足以创建 branch、在 `.github/workflows/` 中提交恶意文件、触发它、收集生成的 artifacts/logs，然后删除临时 branch/workflow run 以减少痕迹。
-- **Wormable registry propagation**: 被盗的 npm tokens 应验证是否具有 **publish** 权限，以及是否绕过 2FA。如果可以，就枚举可写 packages，下载它们的 tarballs，注入一个诸如 `setup.mjs` 的 loader，将 `preinstall` 设为执行它，提升 patch version，然后 republish。这样就能把一次 CI compromise 变成其他环境中的下游自动执行。
+- **Install-time code execution via package hooks**: 发布一个 package version，添加 `preinstall`、`postinstall`、`prepare` 或类似 hooks，使 payload 在 dependency installation 期间自动在开发者工作站和 CI runners 上运行。
+- **Secondary execution paths**: 即使目标使用 `--ignore-scripts` 安装，恶意 package 仍可在 `bin` 字段中注册一个 **common CLI name**，从而将攻击者控制的 wrapper 通过 symlink 放入 `PATH`，并在之后命令被使用时执行。
+- **Runtime bootstrapping**: 一个小型 installer 可以在安装期间下载第二个 runtime 或 toolchain（例如 Bun 或一个打包好的 interpreter），然后用它启动主 payload，从而避免本地依赖要求。
+- **Credential harvesting from build environments**: 一旦 code 在 CI 中运行，检查 environment variables、`~/.npmrc`、`~/.git-credentials`、SSH keys、cloud CLI configs，以及像 `gh auth token` 这样的本地工具。在 GitHub Actions 中，也要查找 runner-specific secrets 和 artifacts。
+- **Workflow injection with stolen GitHub tokens**: 拥有 **`repo` + `workflow`** permissions 的 token 足以创建一个 branch，在 `.github/workflows/` 中提交一个恶意文件，触发它，收集生成的 artifacts/logs，然后删除临时 branch/workflow run 以减少痕迹。
+- **Wormable registry propagation**: 被窃取的 npm tokens 应验证是否具有 **publish** 权限以及是否绕过 2FA。如果可以，枚举可写 packages，下载它们的 tarballs，注入一个类似 `setup.mjs` 的 loader，将 `preinstall` 设为执行它，提升 patch version，并重新发布。这样就会把一次 CI compromise 变成其他环境中的下游自动执行。
 
 #### Practical checks during an assessment
 
-- 审查 release automation 中是否存在添加到 `package.json` 的 package-manager hooks、意外的 `bin` entries，或只修改 release artifact 的 version bumps。
-- 检查 CI 是否将长期有效的 registry credentials 明文存储在如 `~/.npmrc` 这样的文件中，而不是使用短期 OIDC 或 trusted publishing。
+- 审查 release automation 是否在 `package.json` 中添加了 package-manager hooks、意外的 `bin` entries，或只修改 release artifact 的 version bumps。
+- 检查 CI 是否将长期存在的 registry credentials 以明文文件形式存储，例如 `~/.npmrc`，而不是使用短期 OIDC 或 trusted publishing。
 - 验证 CI 中可用的 GitHub tokens 是否能够写入 workflow files 或创建 branches/tags。
-- 如果怀疑某个 package 已被 compromise，请检查已发布的 tarball，而不只是 Git repository，因为恶意 loader/runtime 可能只存在于已发布 artifact 中。
-- 在 CI 中寻找意外的 package-manager execution，例如 `npm install` 而不是 `npm ci`、意外的 Bun downloads/execution，或由临时 branches 生成的新 workflow artifacts。
+- 如果怀疑某个 package 已被 compromise，请检查已发布的 tarball，而不仅仅是 Git repository，因为恶意 loader/runtime 可能只存在于已发布的 artifact 中。
+- 在 CI 中排查意外的 package-manager execution，例如使用 `npm install` 而不是 `npm ci`、意外的 Bun downloads/execution，或由临时 branches 生成的新 workflow artifacts。
+- 也要将 GitOps deployment engines 视为 CI/CD targets。Argo CD-specific enumeration、repo-server abuse 和 Redis cache poisoning attacks 在 [Argo CD Security](argocd-security.md) 中有介绍。
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一个开源工具，用于基于新的 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 审计软件 supply chain stack 的安全合规性。该审计关注整个 SDLC process，可揭示从 code time 到 deploy time 的风险。
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一个开源工具，用于根据新的 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 审计你的 software supply chain stack 的安全合规性。该审计关注整个 SDLC process，并能揭示从 code time 到 deploy time 的风险。
 
 ### Top 10 CI/CD Security Risk
 
-查看这篇关于根据 Cider 评出的前 10 个 CI/CD risks 的有趣文章：[**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+查看这篇有趣的文章，了解 Cider 评出的 CI/CD top 10 risks: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- 在每个平台上，如果你可以本地运行，你都会找到如何在本地启动它，以便你按需配置并测试它
+- 在每个平台上，如果你可以在本地运行，你都会找到如何在本地启动它的方法，这样你就可以按需配置它来进行测试
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools