Hugging Face 如何为 AI 基础设施扩展机密管理

发布日期:2025 年 3 月 31 日
在 GitHub 上更新

Hugging Face 已成为大规模推进 AI 的代名词。随着 Hub 上超过 400 万开发者部署模型,平台的快速增长促使人们重新思考如何管理敏感配置数据——机密。

去年,工程团队着手改进其机密和凭据的处理方式。在评估了 HashiCorp Vault 等工具后,他们最终选择了 Infisical

本案例研究详细介绍了他们迁移到 Infisical 的过程,解释了他们如何集成其强大功能,并强调了它如何使工程师能够更高效、更安全地工作。

背景

随着 Hugging Face 的基础设施从纯 AWS 设置发展到包括 Azure 和 GCP 的多云环境,工程团队需要一种更灵活、更安全、更集中的方式来管理机密。他们没有重构旧系统或采用像 HashiCorp Vault 这样重量级的解决方案,而是转向 Infisical,因为其开发者友好的工作流、多云抽象和强大的安全功能。

他们面临的主要挑战是:

  • 由于跨环境管理不一致,"机密蔓延" 的风险增加。
  • 随着团队规模的扩大,权限管理变得复杂,需要与组织的 SSO (Okta) 集成的严格的基于角色的访问控制 (RBAC)。
  • 本地开发困难,传统的 .env 文件 既损害了安全性又降低了开发者生产力。
  • 手动机密轮换的负担,在涉及暴露凭据的安全事件后,这一点变得尤其明显。

此外,团队还需要一个遵循基础设施即代码实践、支持按项目机密管理,并在部署过程中实现自动化和手动控制之间平稳平衡的解决方案。

实施

Infisical 灵活的架构是一个理想的解决方案。工程团队抓住这个机会重新审视了他们的内部项目结构,将项目划分为不同的基础设施和应用领域。这使得他们能够更清晰地分离关注点并标准化机密轮换实践——这是最近发生安全事件后的首要任务。

通过利用之前用于从 AWS 配置创建 Kubernetes 机密的 Terraform,他们发现向 Infisical Kubernetes Operator 的过渡异常顺利。这种集成实现了安全改进,同时标准化了所有环境的机密管理。

Kubernetes 集成

Kubernetes 是 Hugging Face 生产环境的核心,Infisical 的 Kubernetes Operator 在自动化机密更新方面发挥了重要作用。该 Operator 持续监控 Infisical 中任何机密的变化,并确保这些更新传播到相应的 Kubernetes 对象。每当检测到更改时,它都可以自动重新加载相关的 Deployment,确保容器始终以最新的机密运行。

示例

应用程序在 Kubernetes 中运行需要一个新的机密。该机密可以通过 Infisical 的 CLI 或 web UI 创建,然后开发者在 Kubernetes 中创建 InfisicalSecret 资源,指定 Infisical 中的哪个机密应该被同步。

apiVersion: infisical.com/v1alpha1
kind: InfisicalSecret
metadata:
  name: my-app-secret
  namespace: production
spec:
  infisicalSecretId: "123e4567-e89b-12d3-a456-426614174000"
  targetSecretName: "my-app-k8s-secret"

一旦应用 CRD,Infisical Operator 将持续监视更新。当 Infisical 中检测到更改时,Operator 会自动更新 Kubernetes 机密 (my-app-k8s-secret)。

 Infisical secrets management flow in Kubernetes
使用 Infisical 的机密管理流程:当 Infisical 平台中的机密更新时,Infisical Operator 会自动将更改同步到引用的 Kubernetes 机密,然后该机密可供应用程序使用。

更好的是,由于应用程序的 Deployment 引用 my-app-k8s-secret 作为环境变量源或挂载卷,因此当机密更改时,Operator 可以自动触发容器重新加载。

实际上,尽管 Operator 能够自动触发容器重启,Hugging Face 的工程师们更倾向于等待手动重新部署。这一决定是出于对部署精确控制的需求,尤其是在涉及高流量(每分钟超过 1000 万请求)和大量副本的情况下。

本地开发

对于本地开发,Infisical 的 CLI 通过将机密直接注入开发环境来简化工作流程。这消除了对不安全的本地 .env 文件的需求,使本地配置与生产标准保持一致,并减少了入门阻力。

安全与访问管理

安全改进构成了本次迁移的基础。通过将 Infisical 与现有身份提供商(如 Okta)集成,Hugging Face 建立了一个细粒度的 RBAC 系统。权限自动从 Okta 组映射,确保开发人员对其项目拥有管理权限,而前端和后端团队则获得适当限制的读写访问权限。

此外,机密共享功能允许 Hugging Face 的 ML/AI 研究人员安全地共享凭据。集中的 Infisical 平台还简化了审计和管理机密轮换——这是以前安全事件突出显示的需求。

CI/CD 和基础设施集成

与 CI/CD 流水线的无缝集成进一步增强了整体安全态势。Infisical 通过 GitHub Actions,利用 OIDC 认证和 Terraform 集成,嵌入到部署流水线中。通过在安全环境中运行自托管的 Runner,每次部署都符合生产级别的安全标准。这种集成方法最大限度地降低了风险,并确保从本地开发到云部署的统一体验。

技术成果与见解

通过 Infisical 集中管理机密带来了显著的改进:

  • 工程师不再需要花费宝贵的时间手动配置环境机密。自助服务工作流程加速了入职和日常开发周期。
  • 自动化审计和细粒度访问控制实现了快速事件响应,并促进了“左移”安全方法。
  • 跨云提供商、Kubernetes 集群和 CI/CD 流水线的一致集成消除了机密管理中的差异,从而增强了基础设施的安全性和可靠性。

正如 Hugging Face 基础设施负责人 Adrien Carreira 所说:

“Infisical 提供了我们提升安全态势和节省工程时间所需的所有功能和安全设置。无论您是在本地工作、在生产环境中运行 Kubernetes 集群,还是在 CI/CD 流水线中操作机密,Infisical 都提供了一个无缝的预构建工作流程。”

结论

Hugging Face 迁移到 Infisical 的案例表明,以技术为主导、以工程为中心的跨多个云平台管理机密的方法能够带来显著的效益。要解决类似挑战,使用 Infisical 是一种实用方法,可以在保持强大安全性的同时提高工作效率。

当安全的路径变得最简单时,团队就可以专注于构建创新产品,而不必担心机密管理。

资源

对于有兴趣采用类似方法的团队:


本技术案例研究改编自发布于 infisical.com/customers/hugging-face 的原始案例研究。

社区

注册登录评论