在 Formal，我们厌恶秘密。从第一天开始，我们便在致力于将我们基础设施中长期存在的秘密数量减少到零。我们希望我们的产品以及客户与之互动的方式也能反映这一哲学。因此，我们在几个月前构建了 OIDC 集成：一种让任意机器工作负载根据其自身基础设施身份进行身份验证的方法，并可选地在此过程中证明人类身份。除了产品和 CI/CD 工作负载外，我们还发现支持 OIDC 对于让代理在我们的基础设施中做更多事情非常有用。像 Cursor 和 Devin 这样的云编码代理本身就是 OIDC 发行者，这意味着我们现在可以通过 Formal 为它们提供可审计、受政策控制的只读访问，访问我们的生产数据和云基础设施。 OpenID Connect (OIDC) 简而言之，OIDC 身份验证流程对于机器工作负载的工作方式如下。目标是从工作负载的身份提供者 (IdP) 获取一个短期令牌，并将其用作在被称为依赖方 (RP) 的外部服务上的身份证明。依赖方通常预先配置了有关 IdP 的知识。工作负载从其环境中获取 OIDC JWT 令牌。有时这作为环境变量提供（例如，GitHub、GitLab）；有时，工作负载需要通过向元数据端点（例如，AWS、GCP、Azure）发出 API 调用来检索它。通常，令牌的作用域仅限于依赖方（例如，通过设置受众 aud 声明）以防止在不同的依赖方之间重用令牌。工作负载向依赖方发出 API 调用，使用获得的 OIDC 令牌作为承载令牌（即，Authorization: Bearer eyJ...）。依赖方从其配置中查找 JWKS 端点（通常像 https://idp.com/.well-known/openid-configuration），并获得 IdP 的公钥以验证 JWT。依赖方验证 JWT 是否使用 IdP 的私钥签名。依赖方还检查嵌入在 JWT 中的一些声明作为身份验证条件——这很重要，因为 IdP 通常是多租户的。这些声明通常用于将传入的身份映射到依赖方上的机器身份。如果所有检查通过，则允许 API 调用进行。有时，对通过 OIDC 身份验证的 API 调用还会应用额外的授权条件。 Formal 的 OIDC 我们的 OIDC 集成遵循上述流程，并具有一些关键的附加细节：客户可以为每个集成指定 CEL 条件，只有当给定的令牌满足该条件时才允许身份验证。此外，OIDC 声明字段也作为权限的输入呈现，从而客户可以为特定的控制平面 API 请求定义更细粒度的授权条件。OIDC 身份验证调用方可以调用的一个端点是 CreateFederationToken，该端点返回一个短期的连接器访问令牌，嵌入源 OIDC 声明字段。这意味着工作负载可以将连接器用作注入凭证的代理，而无需自己存储长期凭证。SPIFFE 工作负载也可以原生工作：Formal 像处理其他 OIDC 令牌一样验证来自 SPIRE 的 JWT-SVID，SPIFFE ID 可用于政策和权限。OIDC 还可以用于对 Formal 端点和 Kubernetes Egress Agent 进行身份验证。 证明人类身份 每个 OIDC 集成都映射到一个单一的机器用户。这对于大多数传统的机器工作负载来说是一个良好的默认模型；然而，我们所关心的许多工作负载并不代表自己行事。例如，CI 作业通常可以归因于推送提交的人，而云代理通常是因为某人从 Slack 启动的。因此，每个集成可以选择定义一个令牌声明，Formal 将其解析为出现在日志中和作为策略输入的人类身份。这两个涉及的身份具有不同类型的信任。Formal 可以对机器身份进行加密认证，但人类身份仅由下游工作负载断言。我们接受该声明，因为我们的客户信任进行该断言的系统，并明确配置 Formal 以信任它。我们从第一天就支持这种形状，但出于非常不同的用例：我们的许多客户使用 Formal 来控制商业智能 (BI) 工具与其数据源之间的数据库流量。像 Metabase 这样的工具每个数据库只能使用一个凭证，但客户往往会根据登录 Metabase 的人类用户不同地执行控制。我们最初建立了最终用户身份传播，作为一种允许 Metabase 将人类身份声称为数据库查询并让 Formal 根据其评估政策的方法。结果表明，这种模式几乎与云编码代理完美契合，特别是那些整个团队共享且任何人都可以从 Slack、Linear 或 GitHub 启动的多人代理。