短期凭证的实践之道
所有人都同意密钥应该过期。然后总有人把 TTL 设成一年,以免出问题。这是我们如何让几分钟有效期的凭证真正经受住真实工作负载考验的方法。
为何长 TTL 总是默认赢家
没人会公开支持永久密钥。但人们支持便利性,而便利性总能在会议上胜出。一小时有效期的凭证意味着有人得处理续期、失败与时钟偏差。一年有效期的凭证则意味着直到出事之前谁都不用操心。
于是默认值不断变长。我们见过有效期以年计的生产密钥,而签发它们的团队会真诚地告诉你,他们相信轮换机制。
把续期从开发者手中拿走
短期凭证只有在续期不再是人的职责时才可行。在 Mandavo 中,智能体在需要时申请凭证,限定于当前任务范围,平台返回一个几分钟内就会过期的凭证。没有密钥需要存储,自然也没有密钥会被忘记轮换。
故障模式也随之改变。一次续期失败,不再是六个月后某个凌晨三点悄无声息地过期然后叫醒某人,而是一次立即、明显的请求,当场成功或被拒绝,并附有原因。
会出什么问题,以及如何应对
从一年缩短到五分钟,有两件事会出问题:运行时间超过 TTL 的批处理任务,以及永久缓存令牌的代码。这两者都值得修复。长时间运行的任务应在检查点重新获取凭证;缓存应尊重过期时间。
换来的回报是,泄露的凭证在几分钟内就变得毫无价值,撤销成为一等操作,而非祈祷。您不再需要问“这把密钥是不是还在某处有效”,因为答案永远是“很快就不会了”。
- #凭证
- #轮换
- #TTL
More field notes
零常驻密钥:一份迁移实操手册
实现零长期密钥是一个项目,而不是一个开关。这是我们建议的顺序,以及每个阶段的陷阱。
Priya Nandakumar · 平台负责人
9 分钟阅读
在执行时而非部署时编写策略
部署时就固化的访问决策,等到真正用上时早已过时。我们在智能体行动的那一刻评估策略图。这是它带来的好处。
Priya Nandakumar · 平台负责人
6 分钟阅读