Render 发布 Sandboxes，为每个 AI 智能体提供独立隔离的计算机

Introducing Render Sandboxes: a computer for every agent. ProductAgent execution Sandboxes Beta Give agents an isolated computer Workflows Orchestrate dynamic background work Core compute Web services Host dynamic web apps at a public URL Private services Host apps for internal traffic Background workers Offload asynchronous jobs Cron jobs Schedule recurring workloads Static sites Deploy websites for free, forever Managed data Shared filesystems Early Access Share persistent files across sandboxes Postgres DBs Run enterprise-grade DBs at scale Key Value stores Provision Redis-compatible datastores Persistent disks Preserve filesystem changes for services Ship faster Native runtimes Full-stack PR previews Zero-downtime deploys Infrastructure-as-code Scale and secure Automatic private networking Load-based autoscaling DDoS protection HIPAA applications SolutionsUse cases Render + Coding Agents By company Startups HIPAA Compliance Customers How OpenAI’s DX team builds breakout apps on Render All customer stories → Migrate Migration Credits Heroku Migration Guide Railway Migration Guide ResourcesBuild Templates Framework Quickstarts Community Find a Render Expert Stay current Changelog Status Blog Introducing Render Sandboxes: A computer for every agent Read the blog → Company About Us Careers Newsroom Brand Kit Security Contact Docs Pricing Migrate to Render Sign in Get started Blog / Engineering 我们最近为 AWS、GCP、OpenAI 和 Anthropic 等第三方服务提供商推出了 OIDC 支持。OIDC 是一个很巧妙的功能，它让你的服务能够向这些服务提供商进行身份认证，而无需生成敏感的 API token。你只需在任意 Render 服务上设置几个环境变量，该服务就能立刻向服务提供商完成认证。就是这么简单，It Just Works™！

这让连接你的服务变得更加容易，而且比生成长期有效的 API token 安全得多。但在这份简洁的表象之下，隐藏着相当复杂的机制，才让这个功能得以实现。让我们打开这只钟表，看看它是怎么走动的！

OIDC 到底是什么 当你使用 OIDC 访问服务提供商时，你的 Render 服务会通过发送一个由 Render 生成的 OIDC token 来向对方完成认证。这个 token 就是一个普通的 JSON blob，里面包含与你服务相关的信息，例如服务的 ID 以及它运行所在的环境：

这个 token 经过加密签名，以防止被篡改或伪造。你可以通过向外部服务提供商（例如 AWS）提供 Render 的验证密钥链接来配置它们接受这些 token，这些密钥可用于验证 token 的签名。

这个 blob 中的每个字段称为一个 claim。每个 claim 在保障 token 安全方面都扮演着不同的角色。让我们来看看！

OIDC 是限时优惠 签发时间（iat）和过期时间（exp）这两个 claim 最容易理解。Render 签发的每个 token 都会在签发 60 分钟后过期，届时服务提供商将不再接受它。在 token 泄露或被盗这种不太可能发生的情况下，它会在一个小时内变得毫无价值。无需轮换！

这个 60 分钟的窗口在安全性和可用性之间精心划出了一条界线。如果 token 过期得更快，泄露一个 token 的危险性就更小。但更短的 token 有效期也会放大服务中断的影响：如果 Render 因任何原因无法签发新 token，这个过期时间就会成为连接开始失败的截止时间。我们从不希望发生这类服务中断，但确保平台可靠性的一部分，就是为意外情况做好准备。一小时是一个稳妥的折中方案：它极大地限制了攻击者利用该 token 能造成的损害，同时留出了足够的缓冲空间，以便在万一发生事故时能够从容恢复。

你究竟是谁？ subject（sub）claim 是最重要的，因为正是它向服务提供商标识了你的 Render 服务。以 AWS 为例：每个 AWS IAM 角色都有一个“信任关系”策略，定义了谁可以、谁不可以担任该角色，而这些策略可以基于这个 claim 将访问权限限制到特定的 Render 服务。

这个 claim 可以是任何类型的标识符，所以最简单的方案就是把它设置为 Render 服务的 ID。但通过在这个字符串中同时包含环境和 workspace ID，用户就可以用单个信任关系为一个角色授予多个 Render 服务的访问权限。例如，用户可以指定一个环境，但把服务 ID 设为通配符，从而允许该环境中的任何服务担任该角色：

借助其他通配符组合，你可以把访问权限授予整个 workspace，或者限制到单个服务。或者干脆完全不限制到任何 subject！这就引出了下一个 claim……

收拾那些容易踩的坑 issuer（iss）claim 指明是谁签署了这个 token。在上面的示例中，它是 https://oidc.render.com/tea-yourworkspaceid。

这个 issuer 代表创建 OIDC token 的身份提供商。该 URL 托管着用于验证这些 token 的公钥。你在配置 AWS 之类的服务提供商时会指定这个 URL，从而确保它们只信任由 Render 真实签发的 token。每当该服务提供商收到一个 token，它们都会从这个 issuer URL 拉取公钥并进行匹配验证。我们将公开的验证密钥托管在 oidc.render.com，因此 issuer URL 中包含它也合情合理。

但为什么路径里还要包含 workspace ID 呢？

这实际上是一道针对服务提供商配置错误的防护措施。当我们的用户配置服务提供商信任 Render 时，我们无法控制他们授予了多少访问权限，也无法控制他们把访问权限授予了哪些服务 ID。我们的一些用户可能想配置一个完全不校验 subject claim 的角色，这将允许任何服务担任该角色。这并非最安全的配置，但在某些情况下是合理的。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）