如何在 Databricks 中管理密钥

发表于 2025 年 8 月 30 日星期六

MLOps 市场正在爆发式增长，预计到 2034 年将达到 390 亿美元；然而，在每个数据技术栈中都存在一种持续性的风险：Secrets。尽管各组织投入数百万美元建设数据基础设施，但只要有一个凭证被攻破，就可能引发连锁反应，导致灾难性的安全泄露，使这些努力付诸东流。

更具体地说，这也是一个规模问题——尤其是在数据工作流中。数据工作流通常需要 10 到 50 个甚至更多外部服务的凭证。随着数据保护支出预计显著增长，再加上 SOC 2、GDPR 和 HIPAA 等合规标准伴随严厉处罚，组织需要强大的 Secrets 管理策略，而不能仅停留在基本的凭证存储上。

Databricks 提供了自己的原生解决方案，本文将对此进行探讨。

基础知识

什么是 Secrets？

Secrets 是应用程序访问受保护资源所需的敏感认证凭证。在数据环境中，这些包括：

• 数据库凭证： PostgreSQL、MySQL、Snowflake 和企业数据仓库的连接字符串
• 云存储访问： AWS S3 密钥、Azure 存储账户、GCP 服务账户
• API 认证： Salesforce、外部数据提供方和 REST 端点的密钥
• 基础设施凭证： 服务主体、SSH 密钥、TLS 证书、容器镜像仓库Token

什么是 Databricks？

Databricks 是一个统一的分析平台，充当现代数据栈的中央处理引擎。Databricks 基于 Apache Spark 构建，并由 Unity Catalog 提供治理能力，几乎可以与现代数据生态中的所有组件集成，从 Fivetran 这样的数据摄取工具，到 Tableau 这样的可视化平台。

这种中心角色带来了广泛的凭证需求。Databricks 必须与数据源、云存储、API 以及下游分析工具进行认证，同时支持多个团队共享工作区和资源的协作工作流。

Databricks 原生 Secrets 管理

Databricks 通过“secret scopes”提供内置的 Secrets 管理方式，这些作用域是用于组织相关凭证的容器。此类由 Databricks 支持的 Secrets 存储在由 Databricks 管理的加密数据库中。

它是如何工作的

Secret scopes 会按环境、团队或应用程序对凭证进行组织。访问控制通过三种权限级别运作：

• MANAGE（完全控制）
• WRITE（读/写访问）
• READ（只读访问）

该平台会自动在 notebook 输出中对 secret 值进行脱敏，用 [REDACTED] 占位符替换，以防止意外泄露。

开发者通过 Databricks CLI 创建 scopes：

databricks secrets create-scope <scope-name>

之后，开发者可以使用 Databricks CLI 或其 SDK 插入 secrets：

databricks secrets put-secret --json '{
  "scope": "<scope-name>",
  "key": "<key-name>",
  "string_value": "<secret>"
}'

随后，这些 secrets 可以通过 Databricks CLI 执行 bash 脚本，并使用 get-secret 函数来读取：

databricks secrets get-secret <scope-name> <key-name> | jq -r .value | base64 --decode

关键限制

虽然对于基本用例来说已经够用，但 Databricks 的原生 Secrets 管理仍存在一些重要限制，可能会带来安全漏洞：

• Workspace 隔离： Secrets 不能在不同的 Databricks workspaces 之间共享，这会导致凭证重复配置，并增加多工作区部署的管理开销。
• 没有自动轮换： 该平台缺少原生的 secret rotation 功能，需要依赖人工流程，而这些流程往往会被延迟或遗忘，从而带来重大安全风险。
• 存储限制： 每个 workspace 最多只能有 100 个 secret scopes，每个 scope 最多 1,000 个 secrets，且单个 secret 上限为 128 KB。
• 有限的审计能力： 与企业级 Secrets 管理解决方案相比，其基础日志能力较弱，使合规与安全监控变得困难。
• 云厂商锁定： Azure Key Vault 集成会使其依赖 Microsoft 生态系统，这对于多云策略来说是个问题。

Infisical：面向开发者的解决方案

对于认真对待数据安全的组织而言，有多种替代方案可以在提供企业级能力的同时解决 Databricks 的限制。Infisical 是一个颇具吸引力的现代替代方案，它直接针对 Databricks 的限制，同时优先考虑开发者体验：

• 云无关的灵活性： 支持在任意基础设施上进行 self-hosted 和云端部署，消除了云原生解决方案常见的厂商锁定问题。
• 以开发者为中心的设计： Infisical 从一开始就围绕开发者工作流设计，提供直观的界面和无缝集成，无需深厚的安全专业知识。
• 开源基础： MIT 许可确保透明性并消除厂商锁定，同时提供 self-hosted 和托管服务选项，以适应不同组织的需求。
• 企业级安全： 提供全面的审计日志、自动轮换、细粒度访问控制，以及满足合规要求的功能，均超过 Databricks 的原生能力。

要为 Databricks 设置 Infisical，开发者只需使用 Infisical 专门提供的 Databricks integration，可从产品的 Integrations 页面访问。

之后，开发者需要配置 Databricks environment、path 和 scope，以便将 secrets 集成进去。Infisical 将处理其余部分（包括 secrets rotation），并开始将 secrets 同步到 Databricks 中正确的 scopes。

实施最佳实践

立即的安全改进

• 消除硬编码 Secrets： 实施 pre-commit hooks 来检测并阻止凭证提交。使用自动化扫描工具识别代码仓库中现有的硬编码凭证。
• 实施最小权限访问： 仅授予必要的权限，并使用 groups 而非逐个分配，以提高可扩展性。定期进行访问审查可确保权限始终适当。
• 建立轮换计划： 为高价值凭证实施 30 到 90 天的 rotation 周期，并在可能的情况下采用自动化流程，以减少人工开销和人为错误。

组织策略

• Scope 组织： 为 environments（dev/staging/prod）、teams 和 applications 创建独立的 secret scopes。使用一致的命名规范，清晰标明用途和访问级别。
• 环境隔离： 严格区分 development、staging 和 production 凭证，以防止 production systems 被意外暴露。
• 监控和告警： 为所有 secret 操作实施全面日志记录，并针对异常访问模式建立告警。

合规性考虑

SOC 2、GDPR 和 HIPAA 等监管要求规定了特定控制措施，包括静态和传输中的加密、全面的审计轨迹以及文档化的访问控制。请选择能够提供合规就绪能力的解决方案，而不是自行构建定制化的合规能力。

为你的组织做出正确选择

战略建议

随着数据和 AI 工程在 2025 年逐步成熟，组织应当：

1. 从安全评估开始： 盘点现有凭证并识别当前流程中的安全漏洞。
2. 实施快速见效措施： 立即消除硬编码 secrets，并建立基本的 access controls。
3. 为规模化做计划： 选择能够随着组织成长而扩展的解决方案，而不是在需求变化时不得不迁移。
4. 优先考虑 Developer Experience： 选择能够提升而非阻碍开发工作流的工具。

随着 2025 年网络安全支出增长 12.2%，以及 MLOps 市场快速扩张，投资于强大的 Secrets 管理不再是可选项；它对于保护你的数据基础设施和保持竞争优势至关重要。

采取行动

在 Databricks 中成功进行 Secrets 管理的关键，在于认识到其原生能力虽然可用，但往往无法满足企业级安全要求。Infisical 凭借 developer-first 的方式和云无关的灵活性，使组织能够超越基础的凭证存储，实施真正端到端的 secrets 生命周期管理。

从评估你当前的 Secrets 管理实践开始，消除眼前的安全风险，并采用 Infisical，在安全要求与运营效率之间取得恰当平衡。主动进行 Secrets 管理的成本，与数据基础设施中基于凭证的安全泄露可能造成的影响相比，几乎微不足道。

随着 Databricks workloads 变得日益复杂，今天集成 Infisical 的组织将在未来几年中具备安全、可扩展增长的优势。

• 原文链接： infisical.com/blog/how-t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～