该集成由三个完全由你掌控的部分构成:一个 Databricks service principal、通过环境蓝图安装的 Databricks CLI,以及 (可选的) Databricks 技能 plugin。Databricks、其 workspace 及所有权限始终保留在你的账户中。
选择 Devin 的身份验证方式
如果你希望今天就让 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) 。
前置条件
- 一个位于 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
然后,将该 service principal 分配给 Devin 需要使用的每个 workspace。你可以在 account console 的 User management → Service principals 中操作,也可以使用 CLI:
USER,而非 ADMIN。Devin 不需要 workspace admin 权限。
步骤 2:将 Devin 连接到 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 客户端密钥
1. 生成 OAuth secret
sql、jobs 和 unity-catalog,不要选择全部作用域。
2. 添加 Devin secrets
当同时存在 client ID 和客户端密钥时,CLI 会自动选择 OAuth M2M,因此无需设置
DATABRICKS_AUTH_TYPE。只有当你想明确排除其他所有认证方式时,才将其设为 oauth-m2m。
Secrets 会在每个新会话开始时以环境变量的形式注入,因此 CLI 不需要 Profile 文件。轮换后的 secret 无需重建即可在下一个新会话中生效。
3. 添加蓝图
initialize 阶段将 secrets 写入文件;写入其中的任何内容都会被固化到快照中。
4. 构建快照
方案 B:OIDC 令牌联合
iss、sub、aud) ,而 service principal 上的联合策略会让 Databricks 信任这些令牌。蓝图会安装 devin-oidc CLI,并对 databricks 进行封装,使每次调用都携带一个全新的令牌,同时写入一个指向你的 service principal 的 profile。之后,你从会话中读取令牌的 claims,并创建与之匹配的 policy。
1. 添加蓝图
该 Profile 不含任何 secrets,因此可以安全地在
initialize 阶段写入。如果你是从方案 A 切换过来的,请在下方策略配置就绪后删除 DATABRICKS_CLIENT_SECRET 这一 Devin Secret,以免 CLI 同时看到两份凭据。
2. 构建快照
3. 创建联合策略
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
重建与版本固定
setup-devin-oidc@main 都跟随各自上游的 main 分支,因此完整构建会拉取到新版本;而差分构建会跳过 initialize,在蓝图发生变更之前一直沿用快照中已有的版本。如果你需要可复现的构建,请从发布标签而非 main 获取安装程序 (例如 .../databricks/setup-cli/v1.17.0/install.sh) ,这样安装的就是指定的那个 CLI 版本;同时将 action 固定到某个提交 SHA (setup-devin-oidc@<sha>) 。
步骤 3:授予权限
权限 Profile
授权 statement 通过应用程序 ID 指定 service principal:
devin-agents) ,然后改为向该组授权。
步骤 4:安装 Databricks 技能 plugin (可选)
- 打开 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:验证
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 应当失败——这次失败恰恰说明权限边界正在生效。

