DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载Atlantis 的本质是在它所在的服务器上直接执行terraform plan/terraform apply因此它与你本地运行 Terraform 一样必须为所使用的云厂商 Provider 提供凭据。本文基于 runatlantis.io/es/docs/provider-credentials.md仓库内还保留英文原版 runatlantis.io/docs/provider-credentials.md展开说明向 Atlantis 注入 Provider 凭据的各类方式并深入讲解 AWS 多账户场景下的共享凭据文件、Assume Role、动态 Session Name 命名机制以及 Terraform 0.12 前后行为差异的原因。读完本文你将能为 Atlantis 实例配置可审计、可追溯、可多账户切换的云厂商凭据体系。为什么 Atlantis 需要 Provider 凭据Atlantis 不会替你去调度 Terraform它的运行模型极其朴素在托管它的服务器上直接执行terraform plan和terraform apply命令对应源码见 server/core/runtime/plan_step_runner.go 中buildPlanCmd对terraform plan ...参数列表的组装。因此凡是本地运行 Terraform 需要凭据的场景Atlantis 同样需要——只是凭据的获取渠道、存放位置由你决定。通用经验法则如果你能ssh或exec进入 Atlantis 所在服务器并且能像本地一样直接运行 Terraform 命令那么 Atlantis 就能正常工作。也就是说凭据配置正确与否的判断标准就是服务器上能否手动跑通 Terraform。凭据提供的四种主流方式你可以根据部署环境从以下方式中选择可组合使用使用官方部署机制的凭据方案Atlantis 的 Helm Chart 与 AWS Fargate Module 各自内置了 Provider 凭据注入机制请直接阅读它们的文档。利用云厂商的实例级身份如果 Atlantis 直接运行在某朵云上大多数云都允许云上应用直接获得云 API 访问权限例如AWS EC2 RolesIAM Instance Profile搜索 EC2 RoleGCE Instance Service Accounts搜索相关 provider 参考文档。 这种方式无需在 Atlantis 内保存任何密钥凭据由云平台自动轮换是长期运行实例的最优解之一。设置环境变量很多用户直接在 Atlantis 运行环境中导出环境变量例如AWS_ACCESS_KEY、AWS_SECRET_ACCESS_KEY等具体变量名以对应 Provider 文档为准。环境变量方式适合单账户、单身份的场景。创建配置文件在 Atlantis 所在服务器上放置 Provider 读取的配置文件例如~/.aws/credentials共享凭据文件。使用 HashiCorp Vault Provider让 Terraform 通过 HashiCorp Vault Provider 动态获取 Provider 凭据凭据不出现在 Atlantis 服务器的静态文件中适合对凭据生命周期有更高安全要求的团队。无论选哪种原则都是让运行 Atlantis 的进程/服务器拥有读取目标云资源所需的最小权限身份。AWS 多账户支持Atlantis 本身不区分 AWS 账户它完全依赖 Terraform 的 AWS 认证链搜索 Authentication来解析凭据。因此多账户能力取决于你如何在服务器上组织这些认证信息。共享凭据文件Shared Credentials File如果使用~/.aws/credentials共享凭据文件必须保证Atlantis 服务器上存在对应的凭据文件且运行 Atlantis 的进程对该文件有读取权限文件内为每个 AWS 账户准备独立的[profile]段Terraform 配置中通过profile参数或AWS_PROFILE环境变量选择账户。Assume Roledefault 配置文件的职责如果使用 Assume Role 进行跨账户访问请确保凭据文件中的default配置档profile有权限 assume 所有需要的角色。因为 Atlantis 面对多个项目时无法预知每个项目要 assume 哪个角色它只会以默认身份去执行terraform plan真正切换角色的逻辑发生在 Terraform Provider 的assume_role块内——如果default档没有足够的 sts:AssumeRole 权限跨账户计划会直接失败。多环境变量为什么行不通使用多组环境变量来支持多账户不会生效服务器上同一时刻只能存在一组AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY而 Atlantis 在并发处理不同仓库、不同账户的 Pull Request 时无法知道该用哪一组环境变量去执行 Terraform。这正是共享凭据文件 profile/assume_role 方案能胜出的原因凭据按配置文件组织Terraform 配置本身决定用哪一份。Assume Role Session Name 的动态命名Atlantis 注入的 5 个 Terraform 变量在 Terraform 0.12时Atlantis 执行terraform plan会自动注入 5 个-var变量源码见 server/core/runtime/plan_step_runner.go 的tfVars函数用于把每次 plan 关联到具体的 VCS 用户与 Pull Request-var参数示例值说明atlantis_userlkysowlkysow执行 plan 命令的 VCS 用户名atlantis_reporunatlantis/atlantisrunatlantis/atlantisPR 所在仓库全名。注意该值含/不能用于 AWS session nameatlantis_repo_ownerrunatlantisrunatlantisPR 所在仓库的owneratlantis_repo_nameatlantisatlantisPR 所在仓库名atlantis_pull_num200200Pull Request 编号源码实现要点tfVars返回形如[-var, atlantis_user..., -var, atlantis_repo..., ...]的扁平参数列表刻意不用 map 是为了保持测试中的参数顺序并在buildPlanCmd中与-inputfalse -refresh -out planfile、extra_args、CommentArgs、env/{workspace}.tfvars等参数一起拼入最终命令。对应测试见 server/core/runtime/plan_step_runner_test.go其中断言了-var atlantis_userusername等 5 组参数按序出现。在 Provider 配置中你可以用这些变量动态构造 session name从而在 CloudWatch / CloudTrail 中把每一次通过 Atlantis 发出的 API 调用回溯到具体用户和仓库provider aws { assume_role { role_arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME session_name ${var.atlantis_user}-${var.atlantis_repo_owner}-${var.atlantis_repo_name}-${var.atlantis_pull_num} } }例如用户lkysow在runatlantis/atlantis仓库的 PR #200 上执行 plan生成的 session name 即为lkysow-runatlantis-atlantis-200可据此在 CloudWatch 中快速定位某次 API 调用的发起人。配合 S3 Backend 时的 role_arn若同时使用assume_role与 S3 Backend必须在 backend 块中显式添加role_arn否则 backend 初始化即读取/写入 state仍会以默认身份执行terraform { backend s3 { bucket mybucket key path/to/my/key region us-east-1 role_arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME # 注意backend 配置中不允许插值 # 因此 session_name ${var.atlantis_user} 在这里不生效 } }代码中的注释明确指出session_name ${var.atlantis_user}不可行因为 Terraform 的 backend 配置不支持变量插值。为什么 Terraform 0.12 不再自动注入变量自 Terraform 0.12 起如果-var指定的变量在配置中未被实际使用Terraform 会直接报错拒绝执行。Atlantis 无法预知你的配置是否使用了这些atlantis_*变量因此从安全与兼容性出发它干脆不再设置任何-var标志。这一点在源码中有明确注释server/core/runtime/plan_step_runner.gotfVersion.GreaterThanOrEqual(0.12.0)时tfVars直接返回nil。对应测试 server/core/runtime/plan_step_runner_test.go 也专门验证了使用 0.12 时不设置可选的-var atlantis_*标志这一行为。0.12 的替代方案extra_args 手动传参在 Terraform 0.12 中你仍可以自己通过extra_args配置把这些变量传进去前提是你的配置确实声明并使用了这些变量否则 Terraform 会报错。例如在 atlantis.yaml 或 server-side repo config 中workflows: myworkflow: plan: steps: - plan: extra_args: - -var - atlantis_user${ATLANTIS_USER}需要说明extra_args的几个关键行为出自仓库西班牙语文档 runatlantis.io/es/docs/custom-workflows.md 的说明英文对应 runatlantis.io/docs/custom-workflows.mdextra_args中的每一项都会被作为一个独立参数传给 Terraform不经过 shell 解释——因此;、、|、重定向、globbing、单词切分统统不生效但环境变量引用如$WORKSPACE、$DIR、$ATLANTIS_TERRAFORM_VERSION仍会展开如果你确实需要 shell 行为请改用run步骤它会按设计以 shell 执行。从配置解析层看extra_args是内置命令步骤init/plan/apply/policy_check/import 等的可选键解析实现位于 server/core/config/raw/step.goExtraArgsKey extra_args其 YAML 形态支持- plan: {extra_args: [-var-filestaging.tfvars]}这种 map 形式见 server/core/config/raw/step.go也会被校验为内置步骤只允许一个extra_args键相关错误信息见 server/core/config/raw/step_test.go。常见问题与排查思路plan 报 AWS 认证失败先 ssh 进 Atlantis 服务器手动对目标目录执行terraform plan若能成功则问题多半出在凭据未正确传递如default档缺 assume 权限、环境变量未导出给 Atlantis 进程。跨账户 plan 时用了哪组凭据多账户必须走共享凭据文件 profile/assume_role不要依赖环境变量原因见上文多环境变量为什么行不通。CloudWatch 里看不到是谁触发的 API 调用确认使用的是 Terraform 0.12或通过extra_args手动注入变量且 provider 的assume_role块中设置了session_name。S3 backend 用 assume_role 仍报权限错误检查 backend 块是否遗漏role_arn。相关阅读想进一步定制 Atlantis 行为阅读 Configuring Atlantis英文版runatlantis.io/docs/configuring-atlantis.md准备实际使用 Atlantis 执行 plan/apply阅读 Using Atlantis英文版runatlantis.io/docs/using-atlantis.md自定义工作流与extra_args的完整语法参考 Custom Workflows部署层面如何注入凭据Helm Chart / AWS Fargate参考 Deployment。赞分享DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载相关推荐Atlantis Provider Credentials 完整指南为 Terraform Provider 配置云凭据的多种方式与 AWS Assume Role 深度实践Atlantis Provider Credentials 完整指南为 Terraform Provider 配置云凭据的多种方式与 AWS Assume RDevOpsCI/CD基础设施Atlantis革命性的 Terraform Pull Request 自动化工具Atlantis革命性的 Terraform Pull Request 自动化工具 Atlantis 是一款专为 Terraform 设计的革命性基础设施即代DevOpsCI/CD基础设施Atlantis Autoplanning 详解Pull Request 自动执行 Terraform Plan 的完整机制与配置指南Atlantis Autoplanning 详解Pull Request 自动执行 Terraform Plan 的完整机制与配置指南 导读 本文围绕 AtDevOpsCI/CD基础设施上一篇Kafka UI Docker Compose 全场景部署指南从单集群到 TLS/SASL/JMX 安全加固的配置解析下一篇pass.in未来规划活动管理系统的演进路线和技术趋势创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Atlantis Provider Credentials 完全指南：为 Terraform Pull Request 自动化配置云厂商凭据
DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载Atlantis 的本质是在它所在的服务器上直接执行terraform plan/terraform apply因此它与你本地运行 Terraform 一样必须为所使用的云厂商 Provider 提供凭据。本文基于 runatlantis.io/es/docs/provider-credentials.md仓库内还保留英文原版 runatlantis.io/docs/provider-credentials.md展开说明向 Atlantis 注入 Provider 凭据的各类方式并深入讲解 AWS 多账户场景下的共享凭据文件、Assume Role、动态 Session Name 命名机制以及 Terraform 0.12 前后行为差异的原因。读完本文你将能为 Atlantis 实例配置可审计、可追溯、可多账户切换的云厂商凭据体系。为什么 Atlantis 需要 Provider 凭据Atlantis 不会替你去调度 Terraform它的运行模型极其朴素在托管它的服务器上直接执行terraform plan和terraform apply命令对应源码见 server/core/runtime/plan_step_runner.go 中buildPlanCmd对terraform plan ...参数列表的组装。因此凡是本地运行 Terraform 需要凭据的场景Atlantis 同样需要——只是凭据的获取渠道、存放位置由你决定。通用经验法则如果你能ssh或exec进入 Atlantis 所在服务器并且能像本地一样直接运行 Terraform 命令那么 Atlantis 就能正常工作。也就是说凭据配置正确与否的判断标准就是服务器上能否手动跑通 Terraform。凭据提供的四种主流方式你可以根据部署环境从以下方式中选择可组合使用使用官方部署机制的凭据方案Atlantis 的 Helm Chart 与 AWS Fargate Module 各自内置了 Provider 凭据注入机制请直接阅读它们的文档。利用云厂商的实例级身份如果 Atlantis 直接运行在某朵云上大多数云都允许云上应用直接获得云 API 访问权限例如AWS EC2 RolesIAM Instance Profile搜索 EC2 RoleGCE Instance Service Accounts搜索相关 provider 参考文档。 这种方式无需在 Atlantis 内保存任何密钥凭据由云平台自动轮换是长期运行实例的最优解之一。设置环境变量很多用户直接在 Atlantis 运行环境中导出环境变量例如AWS_ACCESS_KEY、AWS_SECRET_ACCESS_KEY等具体变量名以对应 Provider 文档为准。环境变量方式适合单账户、单身份的场景。创建配置文件在 Atlantis 所在服务器上放置 Provider 读取的配置文件例如~/.aws/credentials共享凭据文件。使用 HashiCorp Vault Provider让 Terraform 通过 HashiCorp Vault Provider 动态获取 Provider 凭据凭据不出现在 Atlantis 服务器的静态文件中适合对凭据生命周期有更高安全要求的团队。无论选哪种原则都是让运行 Atlantis 的进程/服务器拥有读取目标云资源所需的最小权限身份。AWS 多账户支持Atlantis 本身不区分 AWS 账户它完全依赖 Terraform 的 AWS 认证链搜索 Authentication来解析凭据。因此多账户能力取决于你如何在服务器上组织这些认证信息。共享凭据文件Shared Credentials File如果使用~/.aws/credentials共享凭据文件必须保证Atlantis 服务器上存在对应的凭据文件且运行 Atlantis 的进程对该文件有读取权限文件内为每个 AWS 账户准备独立的[profile]段Terraform 配置中通过profile参数或AWS_PROFILE环境变量选择账户。Assume Roledefault 配置文件的职责如果使用 Assume Role 进行跨账户访问请确保凭据文件中的default配置档profile有权限 assume 所有需要的角色。因为 Atlantis 面对多个项目时无法预知每个项目要 assume 哪个角色它只会以默认身份去执行terraform plan真正切换角色的逻辑发生在 Terraform Provider 的assume_role块内——如果default档没有足够的 sts:AssumeRole 权限跨账户计划会直接失败。多环境变量为什么行不通使用多组环境变量来支持多账户不会生效服务器上同一时刻只能存在一组AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY而 Atlantis 在并发处理不同仓库、不同账户的 Pull Request 时无法知道该用哪一组环境变量去执行 Terraform。这正是共享凭据文件 profile/assume_role 方案能胜出的原因凭据按配置文件组织Terraform 配置本身决定用哪一份。Assume Role Session Name 的动态命名Atlantis 注入的 5 个 Terraform 变量在 Terraform 0.12时Atlantis 执行terraform plan会自动注入 5 个-var变量源码见 server/core/runtime/plan_step_runner.go 的tfVars函数用于把每次 plan 关联到具体的 VCS 用户与 Pull Request-var参数示例值说明atlantis_userlkysowlkysow执行 plan 命令的 VCS 用户名atlantis_reporunatlantis/atlantisrunatlantis/atlantisPR 所在仓库全名。注意该值含/不能用于 AWS session nameatlantis_repo_ownerrunatlantisrunatlantisPR 所在仓库的owneratlantis_repo_nameatlantisatlantisPR 所在仓库名atlantis_pull_num200200Pull Request 编号源码实现要点tfVars返回形如[-var, atlantis_user..., -var, atlantis_repo..., ...]的扁平参数列表刻意不用 map 是为了保持测试中的参数顺序并在buildPlanCmd中与-inputfalse -refresh -out planfile、extra_args、CommentArgs、env/{workspace}.tfvars等参数一起拼入最终命令。对应测试见 server/core/runtime/plan_step_runner_test.go其中断言了-var atlantis_userusername等 5 组参数按序出现。在 Provider 配置中你可以用这些变量动态构造 session name从而在 CloudWatch / CloudTrail 中把每一次通过 Atlantis 发出的 API 调用回溯到具体用户和仓库provider aws { assume_role { role_arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME session_name ${var.atlantis_user}-${var.atlantis_repo_owner}-${var.atlantis_repo_name}-${var.atlantis_pull_num} } }例如用户lkysow在runatlantis/atlantis仓库的 PR #200 上执行 plan生成的 session name 即为lkysow-runatlantis-atlantis-200可据此在 CloudWatch 中快速定位某次 API 调用的发起人。配合 S3 Backend 时的 role_arn若同时使用assume_role与 S3 Backend必须在 backend 块中显式添加role_arn否则 backend 初始化即读取/写入 state仍会以默认身份执行terraform { backend s3 { bucket mybucket key path/to/my/key region us-east-1 role_arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME # 注意backend 配置中不允许插值 # 因此 session_name ${var.atlantis_user} 在这里不生效 } }代码中的注释明确指出session_name ${var.atlantis_user}不可行因为 Terraform 的 backend 配置不支持变量插值。为什么 Terraform 0.12 不再自动注入变量自 Terraform 0.12 起如果-var指定的变量在配置中未被实际使用Terraform 会直接报错拒绝执行。Atlantis 无法预知你的配置是否使用了这些atlantis_*变量因此从安全与兼容性出发它干脆不再设置任何-var标志。这一点在源码中有明确注释server/core/runtime/plan_step_runner.gotfVersion.GreaterThanOrEqual(0.12.0)时tfVars直接返回nil。对应测试 server/core/runtime/plan_step_runner_test.go 也专门验证了使用 0.12 时不设置可选的-var atlantis_*标志这一行为。0.12 的替代方案extra_args 手动传参在 Terraform 0.12 中你仍可以自己通过extra_args配置把这些变量传进去前提是你的配置确实声明并使用了这些变量否则 Terraform 会报错。例如在 atlantis.yaml 或 server-side repo config 中workflows: myworkflow: plan: steps: - plan: extra_args: - -var - atlantis_user${ATLANTIS_USER}需要说明extra_args的几个关键行为出自仓库西班牙语文档 runatlantis.io/es/docs/custom-workflows.md 的说明英文对应 runatlantis.io/docs/custom-workflows.mdextra_args中的每一项都会被作为一个独立参数传给 Terraform不经过 shell 解释——因此;、、|、重定向、globbing、单词切分统统不生效但环境变量引用如$WORKSPACE、$DIR、$ATLANTIS_TERRAFORM_VERSION仍会展开如果你确实需要 shell 行为请改用run步骤它会按设计以 shell 执行。从配置解析层看extra_args是内置命令步骤init/plan/apply/policy_check/import 等的可选键解析实现位于 server/core/config/raw/step.goExtraArgsKey extra_args其 YAML 形态支持- plan: {extra_args: [-var-filestaging.tfvars]}这种 map 形式见 server/core/config/raw/step.go也会被校验为内置步骤只允许一个extra_args键相关错误信息见 server/core/config/raw/step_test.go。常见问题与排查思路plan 报 AWS 认证失败先 ssh 进 Atlantis 服务器手动对目标目录执行terraform plan若能成功则问题多半出在凭据未正确传递如default档缺 assume 权限、环境变量未导出给 Atlantis 进程。跨账户 plan 时用了哪组凭据多账户必须走共享凭据文件 profile/assume_role不要依赖环境变量原因见上文多环境变量为什么行不通。CloudWatch 里看不到是谁触发的 API 调用确认使用的是 Terraform 0.12或通过extra_args手动注入变量且 provider 的assume_role块中设置了session_name。S3 backend 用 assume_role 仍报权限错误检查 backend 块是否遗漏role_arn。相关阅读想进一步定制 Atlantis 行为阅读 Configuring Atlantis英文版runatlantis.io/docs/configuring-atlantis.md准备实际使用 Atlantis 执行 plan/apply阅读 Using Atlantis英文版runatlantis.io/docs/using-atlantis.md自定义工作流与extra_args的完整语法参考 Custom Workflows部署层面如何注入凭据Helm Chart / AWS Fargate参考 Deployment。赞分享DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载相关推荐Atlantis Provider Credentials 完整指南为 Terraform Provider 配置云凭据的多种方式与 AWS Assume Role 深度实践Atlantis Provider Credentials 完整指南为 Terraform Provider 配置云凭据的多种方式与 AWS Assume RDevOpsCI/CD基础设施Atlantis革命性的 Terraform Pull Request 自动化工具Atlantis革命性的 Terraform Pull Request 自动化工具 Atlantis 是一款专为 Terraform 设计的革命性基础设施即代DevOpsCI/CD基础设施Atlantis Autoplanning 详解Pull Request 自动执行 Terraform Plan 的完整机制与配置指南Atlantis Autoplanning 详解Pull Request 自动执行 Terraform Plan 的完整机制与配置指南 导读 本文围绕 AtDevOpsCI/CD基础设施上一篇Kafka UI Docker Compose 全场景部署指南从单集群到 TLS/SASL/JMX 安全加固的配置解析下一篇pass.in未来规划活动管理系统的演进路线和技术趋势创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考