权限最小化在CI/CD中需按角色分权、限制提权范围、禁用明文密钥、强化审计溯源，并严防策略静默失效。
权限最小化原则在CI/CD流水线中怎么落地
直接给运维人员 root 或 admin 权限跑流水线，等于把生产钥匙挂在自动门禁卡上——门一开，全进。真正可行的做法是按角色切分权限，并绑定到具体动作。
例如在 Jenkins 中，用 Role-based Authorization Strategy 插件定义三类角色：dev（只能触发测试分支构建）、release-manager（可操作 staging 和 prod 环境部署）、infra-admin（仅能调用 Terraform apply，且仅限 terraform apply -target 白名单模块）。所有角色都不具备直接 SSH 到节点或执行 sudo bash 的能力。
- 每个流水线 Job 必须显式声明
agent标签，并对应 Kubernetes ServiceAccount 或 Jenkins Node Label，避免权限继承污染 - 敏感操作（如数据库迁移、密钥轮转）必须走人工审批门禁，且审批人与执行人不能为同一账号（
separation-of-duties） - Terraform 执行时禁止使用
TF_VAR_*注入凭证，改用aws_role_arn或azurerm_workload_identity_certificate实现临时令牌交换
如何让 Ansible Playbook 不越权执行
Ansible 默认以当前用户身份运行，但很多人会加 become: yes 后就不管了，结果一个 copy src=/etc/shadow dest=/tmp/ 就把整台机器的密码哈希拖走。关键不是“能不能提权”，而是“提权后能碰哪些路径和命令”。
推荐在目标主机上预置 /etc/sudoers.d/ansible-restricted，内容如下：
ansible ALL=(ALL) NOPASSWD: /bin/systemctl start nginx, /usr/bin/tail -n 100 /var/log/nginx/access.log, /usr/local/bin/deploy-check.sh
然后在 Playbook 中强制指定 become_method: sudo 和 become_flags: "-n"（禁用交互），并配合 vars_prompt 对高危任务二次确认。
- 永远不要在
inventory中写ansible_become_pass；改用ansible-vault加密的group_vars/all/vault.yml -
delegate_to: localhost的任务也要检查本地执行用户权限，比如调用aws cli时是否用了--profile隔离凭证 - 用
ansible-lint检查shell模块调用，禁止出现rm -rf /、eval $()、curl | bash类模式
Secret 管理为什么不能只靠环境变量
把 AWS_ACCESS_KEY_ID 塞进 CI 系统的环境变量面板，看起来方便，但一旦日志被 set -x 或 debug: true 泄露，密钥就裸奔了。真实生产环境必须切断明文传递链路。
推荐组合方案：Vault Agent + 注入 + 动态 secret。例如在 GitHub Actions 中，不设 secrets.AWS_ACCESS_KEY_ID，而是用 hashicorp/vault-action@v2 获取短期 token，再通过 VAULT_TOKEN 调用 Vault 的 kv/read 接口读取加密后的值，最后由 Vault Agent sidecar 在容器内挂载为文件（如 /vault/secrets/aws-creds）。
- Kubernetes 中禁用
envFrom: secretRef，改用volumeMounts+subPath挂载单个 key，防止 Pod 内进程意外读取整个 Secret - 所有 secret path 必须带命名空间前缀，如
secret/data/prod/db/password，避免不同环境误读 - Vault 的
lease_duration设为 1h，配合应用层定期 renew，而不是依赖长期 token
谁在动生产配置？审计日志要能回溯到具体 PR 和提交人
很多团队开了 GitOps，却没配好审计闭环：Argo CD 显示 “Synced”，但没人知道这个变更来自哪个 PR、有没有经过 QA 签核、是不是某人绕过流程手动 kubectl apply。真正的权限管理，得让每一次变更都可证伪。
核心是打通三段日志：Git 提交元数据 → CI 流水线 trace ID → 目标集群审计日志。例如在 Argo CD 中启用 audit.log 并将 audit.config.level 设为 request，同时在 CI 的部署步骤里注入 ARGOCD_APP_SOURCE_REPO_URL 和 GITHUB_HEAD_REF 作为 annotation 写入 Application CR。
- Kubernetes audit policy 至少记录
requestReceived和responseStarted阶段，过滤掉get/list类低风险请求，聚焦create/update/delete - 所有
kubectl操作必须通过 wrapper 脚本（如safe-kubectl）强制添加--as=system:serviceaccount:ci:deployer和--as-group=system:authenticated，确保 user 字段可追溯 - ELK 或 Loki 中聚合日志时，用
trace_id关联 Git commit hash、流水线 job id、apiserver request ID，否则查一次故障就得翻三套系统
skip_asset_validation，导致新写的 module 绕过了 IAM 权限校验；又比如某位同事为了调试临时改了 Jenkins 的 script-security 全局设置，之后忘了还原。这些细节不会报错，但会让整套防线慢慢漏气。 
