LiteLLM Terraform Provider用 litellm_guardrails 数据源盘点网关上的全部护栏定义【免费下载链接】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_guardrails数据源文档展开它不接收任何参数一次性从 LiteLLM 代理同时覆盖配置文件与数据库中登记的护栏拉取全部护栏列表且刻意不暴露可能携带 API Key 的敏感参数。读完后你可以在 Terraform 配置中安全地输出护栏 ID、名称与定义位置并理解该数据源在 Provider 侧Go 源码与代理侧Python 端点的完整实现链路。数据源定位只读、无参、聚合双来源官方文档 guardrails.md 对该数据源的定义非常明确功能检索 LiteLLM 代理上配置的全部护栏guardrails来源同时包括config代理配置文件与DB通过 API/控制台注册到数据库的护栏安全边界敏感的litellm_params不会被暴露——因为护栏的litellm_params中可能存放第三方服务的 API Key如 Lakera、Presidio 等护栏后端凭证IaC 状态文件中不应出现这些值参数data litellm_guardrails资源不接收任何参数直接执行即可拉取全量列表典型场景跨环境dev/staging/prod比对护栏清单、在 Terraform 中做护栏存在性校验、将护栏 ID 作为输入传递给下游资源。Provider 侧通过 provider.go 将其注册为litellm_guardrails复数列表查询与单条查询数据源litellm_guardrail按guardrail_id读取并列两者共用同一套读取逻辑。快速上手完整可用示例以下是官方文档给出的示例用法补上 Provider 声明后即为可直接运行的配置Provider 声明方式参考 terraform/provider/README.mdterraform { required_providers { litellm { source BerriAI/litellm version ~ 1.99.0 # 与你代理运行的 LiteLLM 版本保持一致 } } } provider litellm { api_base var.litellm_api_base api_key var.litellm_api_key } # 拉取全部护栏config DB data litellm_guardrails all {} # 输出所有护栏 ID output guardrail_ids { value data.litellm_guardrails.all.ids } # 输出所有护栏名称 output guardrail_names { value [for g in data.litellm_guardrails.all.guardrails : g.guardrail_name] }两个输出分别利用了数据源的两个顶层属性ids是扁平的 ID 列表guardrails是结构化对象列表可用 Terraform 的for表达式进一步派生如按guardrail_definition_location过滤出配置文件中定义的护栏。版本约束提示README 明确说明 Provider 版本号与 LiteLLM 代理版本号一致例如代理跑1.99.0就 pin~ 1.99.0并且 CI 会用tools/endpointaudit/静态审计 Provider 调用的每个端点是否与代理生成的 OpenAPI schema 一致因此保持两者同版本可以避免接口漂移。参数与属性参考Argument Reference数据源不接受任何参数no arguments。调用data litellm_guardrails all {}即完成声明。Attribute Reference属性类型说明guardrailsList of object护栏列表每个元素包含下表 6 个字段guardrails[].guardrail_idString护栏的唯一标识guardrails[].guardrail_nameString护栏的可读名称guardrails[].guardrail_infoMap (String)护栏的附加元数据描述、类型说明等guardrails[].guardrail_definition_locationString护栏定义来源config或dbguardrails[].created_atString护栏创建时间戳guardrails[].updated_atString护栏最近更新时间戳idsList of String所有护栏 ID 的扁平列表所有属性均为Computed只读由 Provider 从代理 API 回填这一点可以从 data_source_guardrail.go 中的 Schema 定义得到确认——整个 Schema 里只有Computed: true的字段没有任何Required/Optional项。源码解析一次 GET /guardrails/list 的完整链路Provider 侧Go数据源实现在 data_source_guardrail.go 中核心是三个部分端点常量L11const endpointGuardrailList /guardrails/list列表查询走代理的/guardrails/list端点单条查询则使用/guardrails/{guardrail_id}/info风格的模板端点endpointGuardrailInfo。API 响应结构体L49-L56JSON 字段名与代理返回一一对应type guardrailListItemAPIResponse struct { GuardrailID string json:guardrail_id GuardrailName string json:guardrail_name GuardrailInfo map[string]interface{} json:guardrail_info GuardrailDefinitionLocation string json:guardrail_definition_location CreatedAt string json:created_at UpdatedAt string json:updated_at }Read 函数L139-L178通过MakeRequest(client, GET, endpointGuardrailList, nil)发起无参 GET 请求解析顶层{guardrails: [...]}后逐条映射进 Terraform 状态最终d.SetId(guardrails) // 数据源 ID 固定为 guardrails d.Set(guardrails, guardrails) d.Set(ids, ids)值得注意的是源码中单条查询函数末尾的注释L87// litellm_params is intentionally not exposed: it can carry API keys.这解释了为什么结构体里干脆没有litellm_params字段——即便 API 有返回Provider 也在解码结构层面将其排除在外与文档中“Sensitivelitellm_paramsare not exposed”的描述相互印证。代理侧PythonProvider 请求最终落在 guardrail_endpoints.py 定义的护栏 CRUD 路由上。从源码结构看列表响应的构造函数_get_guardrails_list_responseL99-L120在返回前会对每条护栏的litellm_params做掩码处理masked_params _get_masked_values( litellm_params, unmasked_length4, number_of_asterisks4, )也就是说存在双层防线代理 API 本身对litellm_params做掩码前 4 位可见、其余以 4 个星号代替Terraform Provider 则干脆不把该字段纳入状态。关于访问权限从 litellm/proxy/_types.py 的路由分组可以看到/guardrails/list及其 v2 变体/v2/guardrails/list被列入多组只读路由白名单其中包括面向管理/查看角色的分组注释明确写着 “Guardrails / Policies pages (read-only views)”。可以推断持有具备管理查看权限的 API Key 即可成功调用该数据源而创建/注册护栏的写端点如/guardrails/register则有更严格的团队/管理员级校验。测试验证Provider 的单元测试 data_source_guardrail_test.go 用httptest起了一个 mock 服务器来固化上述行为TestDataSourceGuardrailsRead断言 Provider 发出的请求必须精确为GET /guardrails/listmock 返回两条护栏一条db、一条config测试校验guardrails列表长度为 2、首条 ID/名称正确且ids输出为[gid-1, gid-2]单条数据源测试TestDataSourceGuardrailRead同样断言请求路径为/guardrails/gid-1/info并验证guardrail_definition_location与guardrail_info如description: pii guard被正确回填。这组测试也直观展示了两种guardrail_definition_location取值的真实样本同一代理实例上db来源的护栏经 API 注册与config来源的护栏写在代理配置里会混排在同一列表中这正是文档“from both config and DB”的含义。使用建议与注意事项区分 config 与 dbguardrail_definition_location为config的护栏由代理配置文件管理Terraform 只能通过本数据源读取它db来源的护栏才能配合 Provider 的litellm_guardrail资源做完整生命周期管理。做 IaC 盘点时可按此字段过滤避免误以为列表中的护栏都能被 Terraform 增删。不要把敏感信息写回状态本数据源不包含litellm_params因此不要试图用 Terraform 输出重建护栏的完整参数需要凭证时仍应走代理配置或 Secret Manager。版本对齐按 terraform/provider/README.md 的约定Provider 版本必须与代理版本同一发行线~ LiteLLM 版本旧版 Provider0.x序列与当前数据源行为不兼容~ 0.4之类的约束永远不会拿到新特性。只读语义该数据源每次plan/apply都会重新请求/guardrails/list代理侧护栏变更后 Terraform 状态会自动同步无需手动刷新。小结litellm_guardrails数据源以“零参数 全量只读”的方式解决了护栏盘点问题一个data块即可拿到全部护栏的 ID、名称、元数据、定义来源config/db与时间戳并在 Provider 与代理两层实现上共同屏蔽了可能泄露密钥的litellm_params。结合 data_source_guardrail.go 的读取逻辑、guardrail_endpoints.py 的掩码实现与 data_source_guardrail_test.go 的端点断言你可以完整复核这条从 HCL 到代理 API 的数据链路。【免费下载链接】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），仅供参考