LiteLLM 安全加固与配置指南

当您在企业内部署自托管的大模型网关时，它往往会迅速成为整个基础设施中最敏感的节点。它存储了团队使用的所有模型提供商的 API 密钥，从 OpenAI、Anthropic 到运行在 vLLM 上的本地端点。然而，自托管设置中的几个开箱即用默认配置常常让管理员感到意外，并暴露出关键的攻击面。为了帮助开发者和平台工程师保护其部署，本指南直接整理了 LiteLLM 官方文档、源码以及近期安全公告中的核心要点。如果您正在管理多个企业级大模型端点，并希望在保持高可用性的同时确保强大的安全性，那么将工作负载与像 n1n.ai 这样可靠的聚合器相结合，可以显著降低管理原始提供商密钥的运维开销。

理解近期安全漏洞

标准的漏洞扫描器严重依赖 CVE 标识符。然而，近期针对自托管大模型基础设施的安全披露表明，仅依赖 CVE 数据库远远不够。以下发现的两个关键问题凸显了主动加固的必要性：

1. GHSA-7hp6-4w63-5g45 (CVSS 9.9)： 影响从 1.91.0 到 1.100.4 版本（以及特定的 1.101、1.102 和 1.103 版本）。该漏洞允许任何拥有 internal_user 角色的用户将自己提升为代理管理员。其根本原因在于代理使用同一个密钥来加密存储的机密并生成会话令牌，导致您要求其加密的“机密”返回时变成了一个有效的管理员令牌。
2. GHSA-g5ff-637f-6q2m (高危)： 在 1.95.0 版本之前，被赋予只读 internal_user_viewer 角色的用户可以通过 vertex_ai_credentials 读取代理主机上的本地文件。

由于这类架构缺陷在早期的标准 pip-audit 运行中经常被忽略，因此手动进行配置加固是不可妥协的。

第一步：修复主密钥与管理界面重叠问题

默认情况下，LiteLLM 的管理界面 /ui 使用 UI_USERNAME（默认为 admin）和 UI_PASSWORD 进行登录。如果未设置 UI_PASSWORD，系统会接受主密钥本身作为密码，并且以这种方式登录的任何人都会自动成为代理管理员。LiteLLM 将这种共享的明文凭据称为仅用于引导的凭据。

要关闭此安全漏洞，请严格按照以下步骤操作：

1. 登录管理界面，创建一个专用的 proxy_admin 用户并为其设置独立的强密码。
2. 验证您是否可以使用该用户成功登录。
3. 更新您的配置文件以禁用环境变量凭据登录：

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  disable_env_credential_login: true

专业提示： 如果在设置 disable_env_credential_login: true 之前跳过了用户创建步骤，您将把自己永久锁定在管理界面之外。

第二步：隔离盐值密钥 (Salt Key)

LiteLLM 会加密存储在其内部数据库中的提供商 API 密钥，包括在 UI 中添加的模型、凭据以及模型上下文协议 (MCP) 服务器凭据。在源码中，get_salt_key() 会读取 LITELLM_SALT_KEY，如果未设置则会回退到主密钥。

• 对于新安装： 在添加任何模型之前生成这两个环境变量。
• 对于已经运行且没有盐值密钥的实例： 切勿在此之后补加盐值密钥。这样做会导致之前存储的所有凭据变得无法读取，因为解密机制会寻找加密时并未使用的专用盐。

要在生产环境中生成安全的密钥，请在主机上运行以下命令：

printf 'LITELLM_MASTER_KEY=sk-%s
LITELLM_SALT_KEY=sk-%s
' "$(openssl rand -hex 32)