GitHub Actions栽了：11分钟暴露AWS密钥后

去年3月，一次配置失误让我的团队暴露在巨大风险中——一个工作流密钥误配，AWS访问凭证在GitHub Actions里裸奔了11分钟才被扫描器捕获。什么都没发生，这次。但这个数字让我彻底重新思考CI和CD之间的安全边界。

两个月后，两个生产集群完成迁移：从纯GitHub Actions部署，转向ArgoCD主导的混合GitOps架构。这篇文章记录的不是"哪个更好"的站队，而是一个产品经理出身的工程师，在真实事故压力下的技术决策复盘。

GitOps的核心设定：让Git成为唯一入口

GitOps把Git当作集群状态的单一可信源。你在仓库里定义"应该存在什么"，ArgoCD或Flux这类代理持续将现实与定义对齐。没人SSH进生产环境，没人手动执行kubectl apply（Kubernetes命令行工具）。

安全模型很朴素：集群从Git拉取配置，代理在集群内部以最小权限运行。开发者永远不需要直接访问集群——提PR、过评审、合并代码，代理自动感知变更。

这是攻击面的断崖式收缩。传统CI/CD模式下，流水线需要凭证才能推送到集群；GitOps模式下，这些凭证始终留在集群内部，从不外泄。

一份基础的ArgoCD应用清单长这样：

repoURL指向配置仓库，server指向集群内部地址。selfHeal: true这个设置很关键——如果有人设法直接在集群内修改了资源，ArgoCD会将其回滚至Git定义的状态。漂移检测是附赠的。

但有个坑我见过太多团队踩：GitOps仓库的分支保护。ArgoCD配置得再完美，main分支敞开写权限，任何有仓库写入权的人都能部署任意代码。强制评审和状态检查不是可选项，是必选项。

GitHub Actions：强大但暴露

GitHub Actions是另一物种。事件驱动——代码推送、PR开启、定时触发，工作流随即执行。这种灵活性正是其安全软肋。

每个需要部署到生产的GitHub Actions工作流都需要某种凭证。即便使用OIDC联邦（你绝对应该用的），风险依然存在：第三方Action可能被攻陷，工作流文件可在特性分支被修改，Secrets可能通过步骤输出泄露。

典型部署工作流里，environment: production这行启用环境保护规则，部署需要人工审批。没这行，任何main分支推送直抵生产。我哪怕在小项目里也强制开启。

更深层的问题是：GitHub Actions工作流是指令式的。你在编写逐步执行的指令，跑在有网络访问权限的Runner上。对比GitOps的声明式——你只声明"应该存在什么"，由代理处理"如何达成"。

混合架构：我的实际落地方案

迁移后的架构分层清晰。GitHub Actions负责CI：构建镜像、跑测试、安全扫描、推送至仓库。ArgoCD负责CD：监听镜像仓库或Git变更，同步至集群。

关键隔离点：GitHub Actions从不直接接触集群凭证。它只推送镜像到仓库，ArgoCD从集群内部拉取并部署。凭证泄露的爆炸半径被锁死在镜像仓库层面。

具体配置中，ArgoCD的ApplicationSet按环境分片，每个团队有独立命名空间。Image Updater自动检测新镜像标签，但只更新非生产环境的Application。生产环境变更仍需人工审批——GitOps不等于全自动，它把审批权从流水线脚本转移到Git提交记录。

成本方面，ArgoCD运行在我们自管的集群上，没有按分钟计费的压力。GitHub Actions的Runner时间从每月约4000分钟降至800分钟——只跑CI，不跑CD。这笔账对25-40人的团队很实在。

安全细节：那些容易忽略的

密钥管理上，我们淘汰了长期有效的AWS密钥，全面转向IRSA（IAM Roles for Service Accounts，服务账户的IAM角色）。ArgoCD的Service Account绑定IAM角色，无需静态凭证。即便Pod被攻破，攻击者拿到的也只是临时Token，有效期1小时。

审计日志是另一个战场。GitHub Actions的日志默认公开（私有仓库除外），步骤输出可能意外泄露。ArgoCD的审计全在集群内部，与Git提交历史一一对应。复盘那次11分钟暴露事件时，GitOps的变更追溯让我省了至少3小时。

第三方Action的风险被低估了。我现在的规则：官方Action或经过验证的发布者，版本锁定到SHA而非标签，定期用Dependabot检查更新。一个被攻陷的Action可能窃取所有环境变量——这在2022年有真实案例，Codecov的Bash Uploader被篡改，持续数月。

什么时候该选哪个

纯GitHub Actions适合快速验证、单环境、团队规模小于5人的场景。配置简单，学习曲线平缓，GitHub Marketplace的生态丰富。但一旦涉及多环境、合规审计、或者"谁能在什么时候部署什么"的精细控制，它的指令式本质会成为负担。

GitOps的门槛在于心智转换：从"我执行部署"到"我提交期望状态"。初期会有挫败感——"为什么改了集群没生效？哦对，得等同步周期或手动刷新。"但三个月后，团队不再凌晨两点被叫起来处理部署故障，因为ArgoCD在自动修复漂移。

我的混合架构不是妥协，是边界划分。CI需要灵活——测试框架、构建工具、扫描器，经常变；CD需要稳定——部署路径、回滚策略、权限模型，尽量少动。GitHub Actions的灵活性留给CI，GitOps的稳定性守住CD。

那次11分钟的暴露事件后，我重新梳理了团队的部署权限矩阵。发现一个反直觉的事实：迁移前，有12个GitHub账号理论上可以触发生产部署；迁移后，这个数字降到3个——两个ArgoCD的Service Account，加一个紧急手动介入的Break-glass凭证，封存在HSM里。

攻击面从"12个可能泄露的入口"收缩到"3个受控的节点"，这个对比让我确信迁移的价值。不是GitOps本身多先进，是它强制你把安全决策显式化——每个变更必须经过Git，而Git的评审、分支保护、提交签名，都是成熟的基础设施。

现在我的ArgoCD仪表盘上，有一个Application专门监控GitOps仓库自身的变更。meta-gitops，或者说，看门狗的看门狗。上周它捕获了一次试图绕过评审的强制推送，触发PagerDuty告警。推送者是个资深工程师，只是想"快速修复一个配置笔误"。