1. Terraform密钥凭据安全导论
在基础设施即代码（IaC）实践中，Terraform 通过声明式配置把云资源、网络、数据库、Kubernetes 集群等对象纳入版本管理与自动化流水线。它带来的效率提升是显而易见的，但同时也把“凭据”推到了风险中心：Terraform 需要访问云平台 API、远程状态后端、私有模块仓库、CI/CD 系统以及第三方服务，每一次 terraform plan 或 terraform apply 背后都可能携带高权限密钥。一旦这些密钥泄露，攻击者不需要理解你的业务代码，就能直接创建、修改或删除真实基础设施。
本课程的目标不是简单罗列“不要把密钥写进代码”，而是建立一套可落地的密钥凭据安全工程能力：理解 Terraform 在认证、状态、变量、Provider、模块和流水线各环节的凭据暴露面；掌握从本地开发到 CI/CD 的密钥注入、隔离、轮换与审计方法；能够识别常见反模式并设计出可验证的防护方案。学完本课程，你应当能够回答三个问题：当前 Terraform 工作流中哪些位置存在凭据？这些凭据被谁、以什么权限、在什么时机使用？如何在不牺牲自动化效率的前提下，把泄露概率和影响半径压到可接受范围。
密钥凭据在 IaC 中的风险全景
Terraform 的凭据风险并不只存在于 .tf 文件里。它贯穿配置编写、状态存储、Provider 认证、模块调用、流水线执行和日志输出六个层面。下面这张图把常见凭据载体、暴露路径与典型后果放在同一视图中，便于建立整体风险地图。
图中六层并非孤立：配置层的硬编码会污染 Git 历史；状态层的明文会随远程后端扩散；Provider 层的长期密钥一旦被 CI 日志捕获，就会同时影响流水线和运行时。因此，安全设计必须按“凭据生命周期”而不是按“文件类型”来组织。
安全责任共担模型
在 Terraform 场景中，责任共担不是云厂商与用户之间的抽象口号，而是可以拆解到具体控制点的工程边界。云厂商负责物理设施、托管服务底层、API 可用性与平台侧身份系统；用户负责凭据的生成、存储、分发、轮换、权限收敛和审计。Terraform 本身作为客户端工具，既不托管你的密钥，也不替你决定权限边界，它只是忠实地把配置中的认证信息发送给目标 API。
这意味着一个常见误区需要纠正：把密钥放进 Terraform Cloud、GitHub Actions Secrets 或 Vault 并不等于“安全已经解决”。这些系统只解决“存储位置”问题，不解决“权限是否过大”“是否可轮换”“是否会被日志打印”“是否跨环境复用”。真正的责任共担模型要求你明确四个边界：谁可以创建凭据、谁可以读取凭据、凭据能操作哪些资源、凭据在什么条件下失效。
| 控制域 | 云平台 / 托管服务责任 | Terraform 使用者责任 |
|---|---|---|
| 身份与访问 | 提供 IAM、STS、OIDC 等认证机制 | 定义最小权限策略、角色信任关系、条件限制 |
| 凭据存储 | 保证密钥管理服务自身加密与高可用 | 选择存储位置、控制读取范围、禁止明文落盘 |
| 状态数据 | 提供加密对象存储与访问日志 | 启用服务端加密、限制后端权限、隔离环境 state |
| 审计与响应 | 提供 API 调用日志与异常检测 | 开启 CloudTrail / 审计日志、建立轮换与吊销流程 |
学习路径与实操起点
本课程后续章节会沿着“识别暴露面 → 建立安全注入 → 收敛权限 → 加密状态 → 审计与轮换”的路径展开。作为导论，先给出一个可立即执行的最小检查动作：用一条命令扫描当前 Terraform 工作目录中是否存在高风险明文凭据模式。这不是完整的安全评估，但能快速暴露最危险的反模式。
# 在 Terraform 项目根目录执行，仅作示例，实际规则需按团队规范调整
grep -RInE '(AKIA[0-9A-Z]{16}|aws_secret_access_key|password\s*=|token\s*=|private_key)' \
--include='*.tf' --include='*.tfvars' --include='*.auto.tfvars' .
# 检查 state 是否被 Git 跟踪
git ls-files | grep -E 'terraform\.tfstate(\.backup)?$'
# 检查环境变量中是否残留长期凭据
env | grep -E 'AWS_|ARM_|GOOGLE_|TF_VAR_' | sed 's/=.*/=<redacted>/'示例输出中如果出现 aws_secret_access_key = "..." 或 terraform.tfstate 被 Git 跟踪，就说明当前项目已经处于高风险状态。此时不要只删除文件后继续提交，因为 Git 历史、CI 缓存和远程 state 版本仍可能保留副本。正确顺序是：先吊销或轮换已暴露凭据，再清理历史与缓存，最后引入安全注入机制。