SST 密钥管理：技术指南

SST 在构建 AWS 无服务器应用的 TypeScript 开发者中迅速流行起来。其命令式、代码优先的基础设施方式让 AWS 更易于上手，尤其适合前端工作量较大、后端相对精简的团队。但随着你的 SST 应用从原型走向生产环境，Secret 管理就会成为一个需要认真对待的关键问题。

了解 SST 及其基础设施模型

SST v3 代表了无服务器基础设施工具的一次重大演进。与 Terraform 或 CloudFormation 这类声明式工具不同，SST 使用命令式 TypeScript 代码来定义 AWS 资源。它构建在 Pulumi 的部署引擎之上，并为常见模式提供了高级构造（constructs）。

对于一个典型的全栈应用，你的 sst.config.ts 可能如下所示：

export default $config({
  app(input) {
    return {
      name: "my-app",
      removal: input?.stage === "production" ? "retain" : "remove",
      home: "aws",
    };
  },
  async run() {
    // 创建一个带有堡垒机和基于 EC2 的 NAT 的 VPC
    const vpc = new sst.aws.Vpc("Vpc", {
      bastion: true,
      nat: "ec2",
    });

    // 在 VPC 内创建一个 Aurora Serverless v2 Postgres 数据库
    const database = new sst.aws.Aurora("Database", {
      engine: "postgres",
      vpc,
    });

    // 创建一个带有函数 URL 的 Lambda 函数，并连接到数据库
    const api = new sst.aws.Function("ApiFunction", {
      handler: "src/api.handler",
      vpc,
      url: true,
      link: [database],
    });

    // 将前端部署为静态网站
    const site = new sst.aws.StaticSite("Web", {
      path: "frontend",
      environment: {
        API_URL: api.url,
      },
    });
  },
});

这展示了 SST 的易用性：只需少量代码，你就可以定义网络、数据库、API 和前端部署。

SST 如何处理 Secrets？

SST 通过 sst secret CLI 命令和 Secret 组件提供内置的 Secret 管理功能。

工作流程非常简单：

## 为当前 Stage 设置一个 Secret
npx sst secret set StripeSecretKey sk_test_xxxx

## 列出当前 Stage 的 Secrets
npx sst secret list

## 为生产环境设置一个 Secret
npx sst secret set StripeSecretKey sk_live_xxxx --stage production

## 设置一个适用于所有 Stage 的 Fallback 值（除非被覆盖）
npx sst secret set StripeSecretKey sk_test_xxxx --fallback

--fallback 标志允许你为 Secret 定义一个默认值，任何没有显式设置该 Secret 的 Stage 都会使用这个默认值。这对于像 PR 预览环境这样的临时 Stage 特别有用。Fallback 值只能被部署在同一 AWS 账户和区域中的 Stage 继承。

在基础设施代码中，你可以使用 Secret 组件来引用 Secrets：

// infra/storage.ts
export const stripeKey = new sst.Secret("StripeSecretKey");

// infra/api.ts
import { stripeKey } from "./storage";

const api = new sst.aws.Function("ApiFunction", {
  handler: "src/api.handler",
  link: [stripeKey],
});

应用代码则通过 Resource 对象访问 Secrets：

import { Resource } from "sst";
import Stripe from "stripe";

const stripe = new Stripe(Resource.StripeSecretKey.value);

在底层，SST v3 会对 Secrets 进行加密，并将其存储在你 AWS 账户中的 S3 存储桶里。当函数引用某个 Secret 时，SST 会将加密后的载荷注入到函数配置中。在运行时，SST SDK 使用 IAM 权限解密该值。

SST 原生 Secret 管理的局限性

随着应用逐渐成熟，SST 内置的 Secret 管理也会暴露出一些限制：

受 Stage 约束且层级能力有限的 Secrets

SST Secrets 默认是按 Stage 区分的。虽然 --fallback 标志提供了基础的继承能力，但它并不是真正的层级系统。你无法定义分层覆盖（例如，一个基础值、一个 development 层级覆盖以及一个针对每个 Stage 的覆盖），也无法在不单独设置的情况下，在特定 Stage 之间共享 Secret。

缺乏中心化的 Secret 可视性

sst secret list 命令一次只能显示一个 Stage 的 Secrets。没有仪表板或集中视图来查看所有 Stage 和项目中的全部 Secrets。当你管理多个 SST 应用时，跟踪 Secrets 会变得越来越困难。

有限的访问控制和审计追踪

SST Secrets 继承 AWS IAM 权限，这对基于团队的工作流来说缺乏足够的细粒度控制。你无法轻松跟踪谁在什么时间访问了哪个 Secret，也无法查看已轮换 Secret 的历史记录。虽然 AWS CloudTrail 会捕获基础设施事件，但它并不提供 Secret 级别的审计可视性。

没有 Secret 轮换或过期机制

SST 不包含内置的 Secret 轮换工作流。对于 PCI DSS 或 SOC 2 等合规要求，你必须借助外部服务自行构建轮换流程，然后手动更新 SST 使用的值。

手动同步 Secret

当 Secrets 发生变化时，开发者必须在所有相关 Stage 中手动更新它们。没有机制可以在多个环境之间同步 Secret 更新，也无法在 Secret 被修改时触发通知。

开发者体验上的缺口

开发者需要在本地配置 AWS 凭据才能设置或查看 Secrets。新成员入职时，需要授予 AWS 访问权限，并记录有哪些 Secrets 以及该如何配置它们。

Infisical 如何解决这些局限性

Infisical 提供了企业级的 Secrets 管理能力，在与 SST 集成的同时，也解决了这些运维挑战。

中心化 Secret 管理

Infisical 为跨项目和环境的所有 Secrets 提供单一可信来源。团队可以通过 Web 仪表板查看每个 Secret、其所在环境以及修改历史。

细粒度的访问控制和审计日志

Infisical 在项目、环境和 Secret 级别实施基于角色的访问控制（RBAC）。每次 Secret 的访问、修改和删除都会生成一条审计日志，包含时间戳、用户身份和操作详情。

自动化 Secret 轮换

Infisical 支持手动和自动化的 Secret 轮换工作流。对于数据库凭据和 API 密钥，你可以配置轮换计划，自动生成新凭据并将其传递到 SST 应用中。

面向临时工作负载的动态 Secrets

Infisical 可以为受支持的后端（例如 PostgreSQL、AWS IAM）签发动态凭据，按需生成短期凭据。这些凭据支持可配置的 TTL，并会在租约期结束后自动撤销，从而缩小潜在泄露的影响范围。

无缝集成 SST

Infisical 可以通过为静态网站在构建时注入 Secret，或在 Lambda 函数运行时获取 Secrets 的方式，与 SST 集成。

团队协作功能

团队可以通过审批工作流申请对生产环境 Secret 的临时提权访问，通过限时授权与外部承包商共享 Secrets，并在 Secrets 被修改时接收通知。

实施策略

从 SST 原生 Secrets 迁移到 Infisical 可以循序渐进地进行：

1. 关键生产环境 Secrets：优先迁移生产数据库凭据和支付处理密钥，因为这些风险最高。
2. 开发和测试环境 Secrets：将 Infisical 扩展到非生产环境，以提供跨 Stage 的一致性。
3. CI/CD 集成：配置部署流水线从 Infisical 获取 Secrets，并为临时 CI/CD 凭据使用动态 Secrets。
4. 自动化轮换：为可轮换的凭据（如数据库密码和服务账户密钥）实施轮换计划。

总结

SST 内置的 Secret 管理对于早期项目来说效果不错。然而，随着应用规模扩大以及合规要求收紧，你会逐渐遇到运维上的摩擦。

Infisical 提供了这方面所缺失的成熟能力：中心化可视性、细粒度访问控制、审计日志和自动化轮换。这让你能够在保留 SST 开发者体验的同时，获得企业级安全性。从第一天起就将 Secrets 视为关键基础设施的组织，往往能够构建出更安全、更易维护的系统。

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