OpenAI 发布官方 Terraform Provider：AI 网关团队期待已久的 IaC 治理方案

7 月 29 日，OpenAI 悄然发布了官方 Terraform provider，将企业级凭据管理变为可编程操作。此前需要在平台 UI 中手动管理的 API 项目、服务账户和速率限制，现在可以通过声明式 IaC 方式处理——这对推理路由网关消耗 OpenAI 容量的方式有着直接影响。

该 provider 使用 OpenAI 的 Administration API，支持完整的资源集：openai_project、服务账户、基于群组的 RBAC、按项目配置速率限制、模型与工具访问控制、支出告警，以及通过导入与核对实现的漂移检测。你需要的一切资源，都可以用代码声明路由拓扑，而不必在 UI 中逐个点击。

7 月 29 日的变化

官方 Terraform provider 现已以 openai/openai 的形式发布在 Terraform Registry 上。它需要 Terraform 1.0 或更高版本（import 示例需要 1.5+），以及一个 Admin API key——与你用于推理调用的 chat API key 不同。

该 provider 覆盖五类治理场景：

项目与访问控制。 为每个路由层级、环境或团队创建隔离项目。在项目级别以角色为基础给用户和群组分配访问权限。项目边界是 OpenAI 执行速率限制和模型控制的基本单元，因此 Terraform 的项目结构直接决定了路由容量上限。

服务账户。 为每个工作负载（CI 流水线、生产网关、预发布环境）创建机器身份，无需使用个人密钥。每个服务账户有自己的密钥，可通过现有的 scoped-key 接口指定权限范围。服务账户的生命周期与团队人员变动无关。

速率限制与支出管理。 将现有的按项目速率限制纳入 Terraform 状态，然后在代码中声明未来的限制和支出告警。当月度支出达到上限时，相关请求会返回 429。支出告警让你在流量中断之前收到通知。

模型、工具与数据控制。 在项目级别限制可访问的模型、可用的托管工具（网络搜索、代码解释器、文件搜索）以及适用的数据保留策略。这些控制不存在于 API 请求层——平台在路由请求之前就会执行它们。

导入与核对。 未被 Terraform 管理的现有资源可以导入状态。已声明配置与实际配置之间的漂移会在 terraform plan 输出中显示，无需编写自定义审计脚本即可发现带外变更（手动 UI 编辑、支持触发的配额提升）。

路由拓扑设计模式

对于运行推理路由的团队，该 provider 最有价值的应用是按层级划分项目的设计：每个路由层级或环境对应一个项目，服务账户作为认证边界。

Terraform 中的三层最小布局如下：

resource "openai_project" "production_high_priority" {
  name = "gateway-prod-high"
}

resource "openai_project" "production_batch" {
  name = "gateway-prod-batch"
}

resource "openai_project" "staging" {
  name = "gateway-staging"
}

resource "openai_service_account" "gateway_prod" {
  project_id = openai_project.production_high_priority.project_id
  name       = "gateway-prod-sa"
}

resource "openai_service_account" "gateway_batch" {
  project_id = openai_project.production_batch.project_id
  name       = "gateway-batch-sa"
}

每个项目有自己的速率限制配置。网关根据请求优先级将流量路由到对应的项目 API key。当高优先级项目达到支出上限或速率限制时，网关可以 fallback 到备用项目，而不是备用 provider——这是手动密钥管理无法以编程方式表达的能力。

这与 7 月发布的服务账户 key scoping（参见此前报道）存在结构性差异：scoped key 控制密钥被允许调用的内容；Terraform provider 控制的是平台配置，即整个项目的容量、模型访问权限和支出上限。

与 Anthropic 方案的对比

Anthropic 对应的治理层是工作负载身份联合（Workload Identity Federation），它用身份提供方颁发的短期 OIDC token 替代静态 API key，无需长期凭据轮换。

OpenAI 的 Terraform provider 采用了不同的路径：带 IaC 状态管理的 Admin API key。密钥仍是长期的，但 Terraform 工作流会捕捉轮换缺口，因为密钥生命周期体现在 Terraform 状态文件中。你仍需制定密钥轮换策略；Terraform 使库存可审计。

对于多 provider 网关团队，实际影响在于：Anthropic 路由在调用层面可以做到无密钥；OpenAI 路由仍依赖密钥，但现在有了 IaC 强制的项目边界和支出控制。如果你的路由策略需要在 fallback 到 Anthropic 或其他 provider 之前将 OpenAI 支出限定在声明的上限内，Terraform provider 中的支出告警和速率限制资源提供了平台层面的强制上限，而非网关侧的近似估算。

网关运营商应优先配置的资源

对于网关运营商，以下三个资源的即时价值最高：

1. 按项目速率限制 — 为每个项目声明明确的 RPM 和 TPM 上限。这些上限成为权威限制；缺少它们，平台默认值适用，且对网关的熔断逻辑不可见。

2. 支出告警 — 为每个项目设置月预算 80% 的通知阈值，配合支出上限，确保网关收到干净的 429 而非无上限的账单。

3. 模型控制 — 将每个项目锁定到其被授权调用的模型系列。生产项目若只应调用 gpt-5.6-sol，则应禁用非 sol 模型，使配置错误的网关请求在平台层面被拒绝，而不是路由到更昂贵或不符合策略的模型。

对于已在管理 OpenAI 服务账户 scoped key 的团队，下一步是将父项目配置——限制、模型控制、支出上限——纳入同一个 Terraform 根模块，使完整的治理面在同一处声明。

该 provider 现已在 registry.terraform.io/providers/openai/openai/latest 上线。所需的 Administration API key 是独立于推理 API key 的凭据，在组织设置下的平台中创建。