该集成由三个完全由你掌控的部分构成:一个 Databricks service principal、通过环境蓝图安装的 Databricks CLI,以及 (可选的) Databricks 技能 plugin。Databricks、其 workspace 及所有权限始终保留在你的账户中。
选择 Devin 的身份验证方式
Devin 以 service principal 身份向 Databricks 进行身份验证,有两种方式。两者使用相同的 service principal、由蓝图安装的 CLI 以及 Unity Catalog 授权,区别仅在于所用的凭据。
如果你希望今天就让 Devin 跑通 Databricks,请从方案 A 开始。后续可随时改用方案 B,无需改动 service principal 及其授权。
为什么要将 Devin 连接到 Databricks?
- Devin 直接在你的数据平台上干活。 Databricks 上的工作大多不只是在代码仓库里编辑笔记本,还包括排查 job 为什么失败、查看表的 schema、对数据仓库执行 query,或检查流水线。把 CLI 交给 Devin,这些原本要找人解答的问题,就变成了 Devin 自己就能搞定的事。
- 单一可审计身份。 Devin 以你创建的 service principal 身份执行操作,因此每一次 API call、query 和 job 运行都会以该身份记录在 Databricks 的 audit logs 和 Unity Catalog 血缘中,而不是挂在某位工程师的个人令牌名下。
- Devin 能碰什么由 Unity Catalog 说了算。 OAuth 决定 Devin 能否通过身份验证;Unity Catalog 的授权和 workspace 权限则决定它能读取或更改什么。你可以先在生产环境中以 read-only 起步,给 Devin 一个 sandbox catalog 用于构建,等看清它的行为表现后再放宽作用域。
- 通向零存储 secrets 的路径。 采用 OIDC 令牌联合 (方案 B) 时,Devin 完全不存储 Databricks 令牌或客户端密钥。每个会话都会用一个有效期 60 秒的 Devin 身份令牌换取一个 short-lived 的 Databricks OAuth 令牌。
概述
Databricks 技能 plugin 是第五层,可选:它在 CLI 之上,让 Devin 掌握 Databricks 特有的工作流程 (Asset Bundles、jobs、SQL、Unity Catalog) 。
前置条件
Databricks- 一个位于 AWS、Azure 或 GCP 上的 Databricks 账户,且执行配置的人员拥有 account admin 访问权限。创建 service principal、OAuth secrets 和联合策略都在账户级别完成。
- 一个或多个启用了 Unity Catalog 的 workspace。本指南假设 Devin 需要访问的数据由 Unity Catalog 管控。
- 在 admin 自己的 machine 上安装 Databricks CLI,用于执行下文的账户级别命令,任意较新版本均可。Devin 所用的副本会在步骤 2 中单独安装。
- 编辑你的组织的环境蓝图 (Settings > Environment > Blueprints) 的权限。
- 若采用方案 A,需要添加 Devin Secrets 的权限。
- 若采用方案 B,需要你的 Devin OIDC 签发方 URL 和 organization ID。步骤 2 将说明如何从 Devin 会话内的令牌中读取这两项。相关背景请参阅 Cloud Authentication with OIDC。
- Devin 会话必须能通过 HTTPS 访问你的 workspace 主机 (例如
https://dbc-xxxx.cloud.databricks.com、https://adb-xxxx.azuredatabricks.net或https://xxxx.gcp.databricks.com) 。如果你的组织启用了 Devin 网络策略,请将该 workspace 主机加入放行范围;若要执行账户级别命令,还需加入账户主机 (accounts.cloud.databricks.com、accounts.azuredatabricks.net或accounts.gcp.databricks.com) 。 - 若采用方案 B,Databricks 必须能通过公共互联网访问
https://<your-devin-host>/.well-known/jwks.json获取 Devin 的 JWKS,以验证令牌签名。
步骤 1:创建 service principal
请为 Devin 单独创建一个 service principal,不要复用其他自动化所依赖的主体。专用主体能让审计日志和权限审查保持清晰。 在一台已登录 Databricks 账户 (而非 workspace) 的机器上执行:
然后,将该 service principal 分配给 Devin 需要使用的每个 workspace。你可以在 account console 的 User management → Service principals 中操作,也可以使用 CLI:
USER,而非 ADMIN。Devin 不需要 workspace admin 权限。
步骤 2:将 Devin 连接到 service principal
请按下面两个选项中的其中一个操作。每个选项都可单独完成:它会通过 Settings > Environment > Blueprints 下的蓝图安装 Databricks CLI,并将该 CLI 配置为以步骤 1 中创建的 service principal 身份进行身份验证。- 选项 A:OAuth 客户端密钥。标准的 OAuth M2M 方式:为 service principal 生成一个客户端密钥,并将其存储在 Devin Secrets 中。这是最快的上手方式。
- 选项 B:OIDC 令牌联合。每个 Devin 会话都可以签发一个由 Devin 签名的短期 OpenID Connect 令牌。借助 Databricks 令牌联合,service principal 可以信任该签发方,Devin 便能用自己的身份令牌换取 Databricks OAuth 令牌。全程不会创建或存储任何 Databricks secrets,因此 Databricks 强烈建议在自动化 workloads 中采用这种方式。
方案 A:OAuth 客户端密钥
- 生成 OAuth secret
在账户 console 中,打开步骤 1 中创建的 service principal,生成 OAuth secret。有效期请设置为轮换流程所能支持的最短时长 (最长 730 天) ,并将该 secret 限制在 Devin 所需的 API 作用域内,例如 sql、jobs 和 unity-catalog,不要选择全部作用域。
- 添加 Devin secrets
在 Devin 中,将以下内容作为 Devin secrets 添加到你接下来要编辑的蓝图 (组织级或代码仓库级) 的 Secrets 选项卡中:
当同时存在 client ID 和客户端密钥时,CLI 会自动选择 OAuth M2M,因此无需设置
DATABRICKS_AUTH_TYPE。只有当你想明确排除其他所有认证方式时,才将其设为 oauth-m2m。
Secrets 会在每个新会话开始时以环境变量的形式注入,因此 CLI 不需要 Profile 文件。轮换后的 secret 无需重建即可在下一个新会话中生效。
- 添加蓝图
仅安装 CLI。身份验证完全依赖上述三个 secrets。
initialize 阶段将 secrets 写入文件;写入其中的任何内容都会被固化到快照中。
- 构建快照
保存蓝图,等待构建状态显示为 Success,然后启动新会话。已有会话仍使用旧快照。接下来请继续步骤 3。
方案 B:OIDC 令牌联合
Devin 会话会签发短期身份令牌 (iss、sub、aud) ,而 service principal 上的联合策略会让 Databricks 信任这些令牌。蓝图会安装 devin-oidc CLI,并对 databricks 进行封装,使每次调用都携带一个全新的令牌,同时写入一个指向你的 service principal 的 profile。之后,你从会话中读取令牌的 claims,并创建与之匹配的 policy。
- 添加蓝图
Profile 中有两个占位符必须替换为你自己的值:
该 Profile 不含任何 secrets,因此可以安全地在
initialize 阶段写入。如果你是从方案 A 切换过来的,请在下方策略配置就绪后删除 DATABRICKS_CLIENT_SECRET 这一 Devin Secret,以免 CLI 同时看到两份凭据。
- 构建快照
保存蓝图,等待构建状态变为 Success。蓝图中没有任何内容依赖于你接下来创建的联合策略,因此之后无需重建。
- 创建联合策略
蓝图构建完成后,Devin 会话即可签发身份令牌。先用一个令牌读取 Databricks 需要信任的确切 claims,然后在 service principal 上创建与之匹配的联合策略。
1
读取你的签发方和 subject
启动一个新的 Devin 会话,让它运行以下命令。该命令只会打印令牌的身份 claims,不会打印令牌本身。预期输出格式:在企业部署中,
iss 是你的自定义 Devin URL (例如 https://yourcompany.devinenterprise.com) 。请严格按打印结果复制 iss 和 sub。不要把原始令牌粘贴到工单或文档中;在接下来的 60 秒内,它就是一份 bearer 凭据。2
编写联合策略
将以下内容保存为 这三个字段都要精确匹配:
devin-federation-policy.json,并替换为上一步获得的值:issuer必须与令牌的iss完全一致,包含协议前缀,且结尾不带斜杠。audiences必须包含 Devin 请求的 audience (本指南中为databricks) 。subject必须与令牌的sub完全一致。默认的 subject 是你的组织 ID,因此该组织中的每个会话都能以此主体进行身份验证。对 Databricks 来说这是合适的粒度,因为联合策略是按字面字符串匹配 subject 的。像devin_id这类会话级 claims 每个会话都不同,静态策略无法匹配。
subject_claim、jwks_uri 和 jwks_json。Databricks 默认使用 sub claim,并从签发方的 /.well-known/openid-configuration 发现 JWKS。3
将策略附加到 service principal
重建与版本固定
Databricks 安装脚本和setup-devin-oidc@main 都跟随各自上游的 main 分支,因此完整构建会拉取到新版本;而差分构建会跳过 initialize,在蓝图发生变更之前一直沿用快照中已有的版本。如果你需要可复现的构建,请从发布标签而非 main 获取安装程序 (例如 .../databricks/setup-cli/v1.17.0/install.sh) ,这样安装的就是指定的那个 CLI 版本;同时将 action 固定到某个提交 SHA (setup-devin-oidc@<sha>) 。
步骤 3:授予权限
身份验证只能证明 Devin 的身份。Devin 能查看或更改哪些内容,则由 workspace 权限和 Unity Catalog 授权决定;你可以随时调整这些设置,无需改动蓝图。建议从满足当前工作所需的最小 Profile 起步,再有针对性地逐步扩大。权限 Profile
授权 statement 通过应用程序 ID 指定 service principal:
devin-agents) ,然后改为向该组授权。
步骤 4:安装 Databricks 技能 plugin (可选)
Databricks 发布了 Agent Skills,可以让代码 Agent 掌握 Databricks 的各类工作流程:Asset Bundles、jobs、SQL、Unity Catalog 和 Spark。将它们安装为 Devin 的 plugin 后,Devin 就能在 CLI 的基础上具备这些专业知识。- 打开 Customize → Plugins,选择 Add plugin → From repository。
- 输入代码仓库
databricks/databricks-agent-skills和子目录plugins/databricks/claude。plugin 清单位于该子目录中,因此从 repository root 安装会提示 No plugin manifest found。 - 如果你在步骤 2 中使用了 organization blueprint,请在 Organization 作用域下安装;如果使用的是 repository blueprint,则改为在该代码仓库的
.devin/config.json中声明该 plugin (参见继承与级别) ,这样只有装有 CLI 的会话才会获得这些技能。 - 确认 plugin 正常工作后,将 plugin 固定到某个 commit,以免上游变更未经审查就进入你的会话。
databricks auth login 来设置 profile。这一交互式浏览器流程无法在无人值守的 Devin 会话中完成,这里也不需要执行;步骤 2 中的 knowledge 条目已告知 Devin,CLI 已完成身份验证。
步骤 5:验证
待蓝图构建成功后,启动一个新会话,让 Devin 运行:current-user me 应返回该服务主体 (service principal) ,且其 userName 等于该应用程序 ID。要确认 CLI 使用了哪种身份验证方式:
oauth-m2m,选项 B 则报告 env-oidc。
身份验证成功并不代表 Devin 就能访问你的数据。请确认步骤 3 中的授权已生效:
<catalog-name> 替换为你在步骤 3 中授权的 catalog (那里的示例使用 analytics) 。然后让 Devin 对它拥有 CAN USE 权限的仓库运行一个小型只读 query;如果你配置了 Build profile,还可以让它在 devin_dev 中创建并删除一张表。而对 Devin 没有 SELECT 权限的生产表执行 query 应当失败——这次失败恰恰说明权限边界正在生效。

