2026/9/9 23:25:48
FEATURED · 精选文章 
LiteLLM Terraform Provider 实战litellm_unified_access_group 数据源使用与源码解析【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm本文围绕 LiteLLM 仓库中 Terraform Provider 的litellm_unified_access_group数据源Data Source展开说明如何通过 IaC 方式按 ID 查询一个已存在的 LiteLLM 统一访问组Unified Access Group及其授予的模型、MCP 服务器、Agent以及其绑定的团队与 Key。读完本文你将掌握该数据源的完整字段语义、Terraform 声明式用法并理解其背后的 HTTP 调用链与 Go SDK 实现从而把访问权限查询可靠地纳入你的基础设施编排流程。Unified Access Group一次授权、多处生效在 LiteLLM Proxy 的权限模型里统一访问组是一组访问权限的聚合体。一个访问组可以把能调哪些模型access_model_names、能连哪些 MCP 服务器access_mcp_server_ids、能使用哪些 Agentaccess_agent_ids打包在一起再整体分配给团队team和虚拟 Keykey。这种设计避免了在 Team 或 Key 上重复维护一长串模型清单让权限在 Proxy 侧集中定义、批量复用。Proxy 侧对访问组的管理集中在一组管理端点上仓库中对应的实现在 访问组管理端点。围绕访问组仓库还提供了三套独立的同步器分别负责把访问组绑定同步到模型、团队和 Keyaccess_group_model_sync.pyaccess_group_team_sync.pyaccess_group_key_sync.py从这些源码结构可以看出访问组不仅是静态标签其与 Team/Key 的绑定变更会被幂等地同步_sync_add_access_group_to_teams、_sync_remove_access_group_from_teams、_sync_add_access_group_to_keys等均以如果尚未包含则追加/删除的方式实现幂等。这也解释了为什么在 Terraform 里查询一个访问组时会同时看到assigned_team_ids、assigned_key_ids这类反向关联字段它们来自 Proxy 返回的实时数据而非 HCL 中的静态声明。Terraform Provider 正是在 Proxy 的这些管理端点之上封装了 Resource管理生命周期与 Data Source只读查询两类访问组抽象。本文聚焦 Data Source 形态的文档 unified_access_group.md。数据源定位只读查询单个访问组litellm_unified_access_group数据源用于按 ID 获取一个已存在的统一访问组并暴露其全部属性供 HCL 中其他资源引用。它不创建、不修改任何东西属于纯只读的查询抽象。Example Usage完整示例原文档给出了最小可运行示例——按access_group_id查询一个名为 engineering 的访问组并把其可访问模型列表输出为outputdata litellm_unified_access_group engineering { access_group_id b6e5f9d0-... } output engineering_models { value data.litellm_unified_access_group.engineering.access_model_names }在此基础上数据源的返回属性可被任意 Terraform 表达式引用例如把访问组的 MCP 服务器 ID 传给下游资源、根据归属团队做条件渲染等# 访问组授予了哪些 MCP 服务器可用于与 litellm_mcp_server 资源对照审计 output engineering_mcp_servers { value data.litellm_unified_access_group.engineering.access_mcp_server_ids } # 该访问组当前被分配给了哪些团队便于校验权限漂移 output engineering_teams { value data.litellm_unified_access_group.engineering.assigned_team_ids }Argument Reference入参参数必需类型说明access_group_id✅ Requiredstring要查询的统一访问组 ID。该 ID 与 Terraform 资源/数据源的id、access_group_id属性同源均对应 Proxy 侧访问组记录的主键注意该数据源只接收这一个入参其余字段全部由服务端返回并写入 Terraform State。Attribute Reference导出属性数据源按 ID 命中后会导出以下全部属性属性类型语义idstring统一访问组 IDaccess_group_idstring统一访问组 ID与id等价access_group_namestring访问组的显示名称descriptionstring访问组描述若存在access_model_nameslist(string)该访问组授予访问权限的模型名列表access_mcp_server_idslist(string)该访问组授予访问权限的 MCP 服务器 ID 列表access_agent_idslist(string)该访问组授予访问权限的 Agent ID 列表assigned_team_idslist(string)被分配了该访问组的团队 ID 列表assigned_key_idslist(string)被分配了该访问组的 Keytoken 哈希ID 列表created_atstring访问组的创建时间戳created_bystring创建该访问组的用户updated_atstring访问组最近一次更新时间戳updated_bystring最近一次更新该访问组的用户前置条件与适用范围使用该数据源之前需要满足以下条件已运行 LiteLLM Proxy 服务并启用访问组相关的管理能力已配置 Terraform Provider 与 Proxy 的连接Base URL 与访问凭证Provider 侧连接初始化逻辑位于 provider.go待查询的访问组已在 Proxy 侧通过管理端 API、管理 UI 或 unified_access_group 资源 创建完成。数据源的适用场景是读取存量配置并与期望状态对比例如在terraform plan前审计某访问组当前授予了哪些模型、是否还绑定了已下线的团队。若你需要的是创建/修改/删除访问组则应使用对应的 unified_access_group Resource而非本数据源。从源码看数据源的真实调用链理解了查什么之后再看怎么查。数据源的完整 Go 实现在 data_source_unified_access_group.go。Schema 定义Computed 化 单一必填入参dataSourceLiteLLMUnifiedAccessGroup()的 Schema 由两部分组成源码 L67-L79复用unifiedAccessGroupComputedSchema()把access_group_name、description、access_model_names、access_mcp_server_ids、access_agent_ids、assigned_team_ids、assigned_key_ids、created_at、created_by、updated_at、updated_by全部声明为Computed: true即这些值只能由服务端响应写入不允许用户在 HCL 里覆盖追加access_group_id类型为TypeString、Required: true作为查询的唯一定位键。这种1 个 Required 11 个 Computed的 Schema 组合是 Terraform Data Source 的典型形态用户只负责描述要查哪个其余字段全部由 Provider 的 Read 函数回填。Read 函数一次只读 GET 请求dataSourceLiteLLMUnifiedAccessGroupRead源码 L81-L108的实现非常直观从ResourceData取出用户声明的access_group_id通过客户端MakeRequest发起GET /v1/unified_access_group/{groupID}若 HTTP 返回404则直接以错误结束unified access group {id} not found其余非 2xx 响应交由handleResponse统一处理把响应体JSON解码到unifiedAccessGroupResponse结构体d.SetId(...)写入资源 ID随后调用setUnifiedAccessGroupFields把响应字段逐一写回ResourceData。unifiedAccessGroupResponse结构体定义在 resource_unified_access_group.go通过 JSON tag 映射了 Proxy 返回的全部字段其中Description、CreatedBy、UpdatedBy是指针类型*string表示这些字段在服务端可能是缺失的对应的回填逻辑setUnifiedAccessGroupFieldsL123-L142在写回前都做了nil判断避免把空指针写进 State。这是 Go 侧对可空响应字段的标准防御式处理也解释了为何description/created_by/updated_by在 Attribute 表中标注为若存在。端点与数据结构小结HTTP 方法/路径GET /v1/unified_access_group/{access_group_id}单查GET /v1/unified_access_group列表查询请求/响应均为 JSON字段名与 Terraform 属性名一一对应下划线命名数据源是只读的永远不发起 POST / PUT / DELETE。错误处理与可用性语义该数据源对查不到的处理是直接报错区别于资源读取时404 则从 State 中摘除的收敛语义。测试用例对这一点做了明确的断言data_source_unified_access_group_test.go 中TestUnifiedAccessGroupDataSourceReadNotFound用httptest返回404随后断言 Read 必须返回错误L49-L63与之对照resource_unified_access_group_test.go 中的TestUnifiedAccessGroupReadNotFound断言资源在 404 时清空 ID 且不报错L126-L142。这种差异是刻意的数据源代表被引用的存量事实目标对象不存在时下游引用它的资源应当 fail fast 而非静默拿到空数据而资源代表期望状态目标被外部删除时收敛为空 State 并等待下次 apply 重建是更稳妥的选择。组合使用单查 列表 资源如果不知道确切的访问组 ID可以先使用列表数据源litellm_unified_access_groups一次性拉取全部访问组文档见 unified_access_groups.md其导出access_groups数组每项字段与本数据源一致和ids所有访问组 ID 列表data litellm_unified_access_groups all {} output unified_access_group_ids { value data.litellm_unified_access_groups.all.ids }而需要管理访问组生命周期创建、改名、增减绑定、删除时则使用管理资源。资源侧同时支持terraform import将存量访问组纳入管理资源文档terraform import litellm_unified_access_group.engineering access-group-id一个常见的端到端模式是先用资源声明访问组的期望权限再用数据源在plan/apply之间校验实际生效值resource litellm_unified_access_group engineering { access_group_name engineering-access description Models and tools for the engineering org access_model_names [gpt-4, claude-3-sonnet] access_mcp_server_ids [litellm_mcp_server.github.id] assigned_team_ids [litellm_team.engineering.id] } data litellm_unified_access_group engineering_check { access_group_id litellm_unified_access_group.engineering.id } output audited_model_access { value data.litellm_unified_access_group.engineering_check.access_model_names }测试与验证方式Provider 为访问组数据源提供了基于net/http/httptest的单元测试不依赖真实 Proxy 即可验证 HTTP 契约TestUnifiedAccessGroupDataSourceReadmockGET /v1/unified_access_group/uag-123断言id、access_group_name、description、access_model_names、assigned_team_ids等字段被正确写入测试源码 L12-L47TestUnifiedAccessGroupsDataSourceReadmock 列表端点返回两条访问组记录断言access_groups数量、嵌套字段及ids汇总正确L65-L112。测试夹具unifiedAccessGroupJSON产出的响应 JSON 覆盖了全部字段含access_mcp_server_ids、access_agent_ids、assigned_key_ids等列表字段与时间戳可在编写本地 Provider 用例时作为响应格式参考。小结litellm_unified_access_group是访问组场景里读的那一半只接收access_group_id一个必填参数返回模型、MCP 服务器、Agent、团队、Key 授权及审计时间戳等全部只读属性。它的底层不过是对 Proxy 管理端点GET /v1/unified_access_group/{id}的封装但 Data Source 的 Schema全 Computed与错误语义404 即报错让它天然适合作为 IaC 状态校验与审计引用的可靠来源。需要完整管理访问组时请搭配 litellm_unified_access_group 资源 使用。相关源码与文档索引本文主文档terraform/provider/docs/data-sources/unified_access_group.md数据源 Go 实现data_source_unified_access_group.go资源与响应结构体实现resource_unified_access_group.go数据源测试data_source_unified_access_group_test.go资源测试resource_unified_access_group_test.go列表数据源文档terraform/provider/docs/data-sources/unified_access_groups.md资源文档terraform/provider/docs/resources/unified_access_group.mdProxy 侧访问组管理端点access_group_endpoints.py访问组与团队/Key 同步逻辑access_group_team_sync.py、access_group_key_sync.py【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LiteLLM Terraform Provider 实战：litellm_unified_access_group 数据源使用与源码解析
LiteLLM Terraform Provider 实战litellm_unified_access_group 数据源使用与源码解析【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm本文围绕 LiteLLM 仓库中 Terraform Provider 的litellm_unified_access_group数据源Data Source展开说明如何通过 IaC 方式按 ID 查询一个已存在的 LiteLLM 统一访问组Unified Access Group及其授予的模型、MCP 服务器、Agent以及其绑定的团队与 Key。读完本文你将掌握该数据源的完整字段语义、Terraform 声明式用法并理解其背后的 HTTP 调用链与 Go SDK 实现从而把访问权限查询可靠地纳入你的基础设施编排流程。Unified Access Group一次授权、多处生效在 LiteLLM Proxy 的权限模型里统一访问组是一组访问权限的聚合体。一个访问组可以把能调哪些模型access_model_names、能连哪些 MCP 服务器access_mcp_server_ids、能使用哪些 Agentaccess_agent_ids打包在一起再整体分配给团队team和虚拟 Keykey。这种设计避免了在 Team 或 Key 上重复维护一长串模型清单让权限在 Proxy 侧集中定义、批量复用。Proxy 侧对访问组的管理集中在一组管理端点上仓库中对应的实现在 访问组管理端点。围绕访问组仓库还提供了三套独立的同步器分别负责把访问组绑定同步到模型、团队和 Keyaccess_group_model_sync.pyaccess_group_team_sync.pyaccess_group_key_sync.py从这些源码结构可以看出访问组不仅是静态标签其与 Team/Key 的绑定变更会被幂等地同步_sync_add_access_group_to_teams、_sync_remove_access_group_from_teams、_sync_add_access_group_to_keys等均以如果尚未包含则追加/删除的方式实现幂等。这也解释了为什么在 Terraform 里查询一个访问组时会同时看到assigned_team_ids、assigned_key_ids这类反向关联字段它们来自 Proxy 返回的实时数据而非 HCL 中的静态声明。Terraform Provider 正是在 Proxy 的这些管理端点之上封装了 Resource管理生命周期与 Data Source只读查询两类访问组抽象。本文聚焦 Data Source 形态的文档 unified_access_group.md。数据源定位只读查询单个访问组litellm_unified_access_group数据源用于按 ID 获取一个已存在的统一访问组并暴露其全部属性供 HCL 中其他资源引用。它不创建、不修改任何东西属于纯只读的查询抽象。Example Usage完整示例原文档给出了最小可运行示例——按access_group_id查询一个名为 engineering 的访问组并把其可访问模型列表输出为outputdata litellm_unified_access_group engineering { access_group_id b6e5f9d0-... } output engineering_models { value data.litellm_unified_access_group.engineering.access_model_names }在此基础上数据源的返回属性可被任意 Terraform 表达式引用例如把访问组的 MCP 服务器 ID 传给下游资源、根据归属团队做条件渲染等# 访问组授予了哪些 MCP 服务器可用于与 litellm_mcp_server 资源对照审计 output engineering_mcp_servers { value data.litellm_unified_access_group.engineering.access_mcp_server_ids } # 该访问组当前被分配给了哪些团队便于校验权限漂移 output engineering_teams { value data.litellm_unified_access_group.engineering.assigned_team_ids }Argument Reference入参参数必需类型说明access_group_id✅ Requiredstring要查询的统一访问组 ID。该 ID 与 Terraform 资源/数据源的id、access_group_id属性同源均对应 Proxy 侧访问组记录的主键注意该数据源只接收这一个入参其余字段全部由服务端返回并写入 Terraform State。Attribute Reference导出属性数据源按 ID 命中后会导出以下全部属性属性类型语义idstring统一访问组 IDaccess_group_idstring统一访问组 ID与id等价access_group_namestring访问组的显示名称descriptionstring访问组描述若存在access_model_nameslist(string)该访问组授予访问权限的模型名列表access_mcp_server_idslist(string)该访问组授予访问权限的 MCP 服务器 ID 列表access_agent_idslist(string)该访问组授予访问权限的 Agent ID 列表assigned_team_idslist(string)被分配了该访问组的团队 ID 列表assigned_key_idslist(string)被分配了该访问组的 Keytoken 哈希ID 列表created_atstring访问组的创建时间戳created_bystring创建该访问组的用户updated_atstring访问组最近一次更新时间戳updated_bystring最近一次更新该访问组的用户前置条件与适用范围使用该数据源之前需要满足以下条件已运行 LiteLLM Proxy 服务并启用访问组相关的管理能力已配置 Terraform Provider 与 Proxy 的连接Base URL 与访问凭证Provider 侧连接初始化逻辑位于 provider.go待查询的访问组已在 Proxy 侧通过管理端 API、管理 UI 或 unified_access_group 资源 创建完成。数据源的适用场景是读取存量配置并与期望状态对比例如在terraform plan前审计某访问组当前授予了哪些模型、是否还绑定了已下线的团队。若你需要的是创建/修改/删除访问组则应使用对应的 unified_access_group Resource而非本数据源。从源码看数据源的真实调用链理解了查什么之后再看怎么查。数据源的完整 Go 实现在 data_source_unified_access_group.go。Schema 定义Computed 化 单一必填入参dataSourceLiteLLMUnifiedAccessGroup()的 Schema 由两部分组成源码 L67-L79复用unifiedAccessGroupComputedSchema()把access_group_name、description、access_model_names、access_mcp_server_ids、access_agent_ids、assigned_team_ids、assigned_key_ids、created_at、created_by、updated_at、updated_by全部声明为Computed: true即这些值只能由服务端响应写入不允许用户在 HCL 里覆盖追加access_group_id类型为TypeString、Required: true作为查询的唯一定位键。这种1 个 Required 11 个 Computed的 Schema 组合是 Terraform Data Source 的典型形态用户只负责描述要查哪个其余字段全部由 Provider 的 Read 函数回填。Read 函数一次只读 GET 请求dataSourceLiteLLMUnifiedAccessGroupRead源码 L81-L108的实现非常直观从ResourceData取出用户声明的access_group_id通过客户端MakeRequest发起GET /v1/unified_access_group/{groupID}若 HTTP 返回404则直接以错误结束unified access group {id} not found其余非 2xx 响应交由handleResponse统一处理把响应体JSON解码到unifiedAccessGroupResponse结构体d.SetId(...)写入资源 ID随后调用setUnifiedAccessGroupFields把响应字段逐一写回ResourceData。unifiedAccessGroupResponse结构体定义在 resource_unified_access_group.go通过 JSON tag 映射了 Proxy 返回的全部字段其中Description、CreatedBy、UpdatedBy是指针类型*string表示这些字段在服务端可能是缺失的对应的回填逻辑setUnifiedAccessGroupFieldsL123-L142在写回前都做了nil判断避免把空指针写进 State。这是 Go 侧对可空响应字段的标准防御式处理也解释了为何description/created_by/updated_by在 Attribute 表中标注为若存在。端点与数据结构小结HTTP 方法/路径GET /v1/unified_access_group/{access_group_id}单查GET /v1/unified_access_group列表查询请求/响应均为 JSON字段名与 Terraform 属性名一一对应下划线命名数据源是只读的永远不发起 POST / PUT / DELETE。错误处理与可用性语义该数据源对查不到的处理是直接报错区别于资源读取时404 则从 State 中摘除的收敛语义。测试用例对这一点做了明确的断言data_source_unified_access_group_test.go 中TestUnifiedAccessGroupDataSourceReadNotFound用httptest返回404随后断言 Read 必须返回错误L49-L63与之对照resource_unified_access_group_test.go 中的TestUnifiedAccessGroupReadNotFound断言资源在 404 时清空 ID 且不报错L126-L142。这种差异是刻意的数据源代表被引用的存量事实目标对象不存在时下游引用它的资源应当 fail fast 而非静默拿到空数据而资源代表期望状态目标被外部删除时收敛为空 State 并等待下次 apply 重建是更稳妥的选择。组合使用单查 列表 资源如果不知道确切的访问组 ID可以先使用列表数据源litellm_unified_access_groups一次性拉取全部访问组文档见 unified_access_groups.md其导出access_groups数组每项字段与本数据源一致和ids所有访问组 ID 列表data litellm_unified_access_groups all {} output unified_access_group_ids { value data.litellm_unified_access_groups.all.ids }而需要管理访问组生命周期创建、改名、增减绑定、删除时则使用管理资源。资源侧同时支持terraform import将存量访问组纳入管理资源文档terraform import litellm_unified_access_group.engineering access-group-id一个常见的端到端模式是先用资源声明访问组的期望权限再用数据源在plan/apply之间校验实际生效值resource litellm_unified_access_group engineering { access_group_name engineering-access description Models and tools for the engineering org access_model_names [gpt-4, claude-3-sonnet] access_mcp_server_ids [litellm_mcp_server.github.id] assigned_team_ids [litellm_team.engineering.id] } data litellm_unified_access_group engineering_check { access_group_id litellm_unified_access_group.engineering.id } output audited_model_access { value data.litellm_unified_access_group.engineering_check.access_model_names }测试与验证方式Provider 为访问组数据源提供了基于net/http/httptest的单元测试不依赖真实 Proxy 即可验证 HTTP 契约TestUnifiedAccessGroupDataSourceReadmockGET /v1/unified_access_group/uag-123断言id、access_group_name、description、access_model_names、assigned_team_ids等字段被正确写入测试源码 L12-L47TestUnifiedAccessGroupsDataSourceReadmock 列表端点返回两条访问组记录断言access_groups数量、嵌套字段及ids汇总正确L65-L112。测试夹具unifiedAccessGroupJSON产出的响应 JSON 覆盖了全部字段含access_mcp_server_ids、access_agent_ids、assigned_key_ids等列表字段与时间戳可在编写本地 Provider 用例时作为响应格式参考。小结litellm_unified_access_group是访问组场景里读的那一半只接收access_group_id一个必填参数返回模型、MCP 服务器、Agent、团队、Key 授权及审计时间戳等全部只读属性。它的底层不过是对 Proxy 管理端点GET /v1/unified_access_group/{id}的封装但 Data Source 的 Schema全 Computed与错误语义404 即报错让它天然适合作为 IaC 状态校验与审计引用的可靠来源。需要完整管理访问组时请搭配 litellm_unified_access_group 资源 使用。相关源码与文档索引本文主文档terraform/provider/docs/data-sources/unified_access_group.md数据源 Go 实现data_source_unified_access_group.go资源与响应结构体实现resource_unified_access_group.go数据源测试data_source_unified_access_group_test.go资源测试resource_unified_access_group_test.go列表数据源文档terraform/provider/docs/data-sources/unified_access_groups.md资源文档terraform/provider/docs/resources/unified_access_group.mdProxy 侧访问组管理端点access_group_endpoints.py访问组与团队/Key 同步逻辑access_group_team_sync.py、access_group_key_sync.py【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
