IAM 临时凭证的刷新与缓存：一个容易拖垮服务的细节

临时凭证为什么会成为故障源

用 IAM 临时凭证（STS）替代长期 AK/SK 是安全上的正确选择，但它引入了一个新的运行时问题：凭证有有效期。如果一整个集群的实例是在同一时刻启动的，它们会在同一时刻拿到同一批凭证，然后在同一时刻集体过期——于是每到刷新点，服务就会出现一次集中的鉴权失败。

这类问题的特点是：平时完全正常，只在特定时间点抖一下，日志里是一批 403 或 TokenExpired，很难和代码逻辑关联起来。

刷新窗口该留多长

核心原则是提前刷新，不要等过期。经验公式：

刷新提前量 = max(凭证有效期 × 10%, 5 分钟)

比如有效期 1 小时，就在剩余 6 分钟时开始刷新；有效期 15 分钟，就在剩余 5 分钟时刷新。提前量太小容易赶不上网络抖动，太大则浪费请求。

判断是否该刷新的条件应该基于 expires_at 的绝对时间，而不是「拿到之后过了多久」——因为凭证可能来自缓存、可能由别的进程写入，持续时间不可靠。

缓存的三层设计

一个能扛住并发的凭证管理，通常分三层：

第一层：进程内缓存

最常见的实现是一个模块级变量加锁。它的好处是零依赖，坏处是每个进程各自持有一份，多进程部署时刷新次数 = 进程数。对普通 Web 服务来说这个量级完全可以接受，先做这一层就够了。

import threading, time

_lock = threading.Lock()
_cache = {"cred": None, "exp": 0.0}

def get_credential(fetch):
    now = time.time()
    with _lock:
        if _cache["cred"] and now < _cache["exp"] - 300:
            return _cache["cred"]
        cred = fetch()                     # 只在锁内刷新一次
        _cache["cred"] = cred
        _cache["exp"] = cred["expires_at"]
        return cred

注意锁的位置：判断和刷新都要在锁内。如果先判断再加锁，高并发下会出现多个线程同时发现过期、同时发起刷新请求，把鉴权服务打出一波尖峰。

第二层：本地文件共享

同一台机器上的多个进程，可以让刷新结果落在一个权限收得很紧的临时文件里（0600，放在 /run 或内存盘上，不要放 /tmp 全局可读目录）。刷新时用原子写：先写临时文件再 rename，避免读端读到半个 JSON。

第三层：集中式签发

进程数量到几十上百时，让每个进程自己去换凭证就不划算了。做法是起一个小的 sidecar 或内部服务，统一刷新、统一对外提供，业务进程通过本地回环地址拉取。这样刷新次数恒定，也便于统一监控和审计。

刷新失败的降级策略

刷新本身会失败：网络抖动、鉴权服务限流、上游超时。失败时不能简单抛异常，否则一次抖动就等于一次业务不可用。合理的降级顺序是：

1. 刷新失败但旧凭证还没过期 → 继续用旧凭证，后台退避重试，同时打 warn 日志；
2. 旧凭证已过期 → 尝试从文件缓存或 sidecar 取；
3. 都拿不到 → 明确抛错，并把错误分类（网络类 / 鉴权类）便于上层区别处理。

关键在于把「刷新失败」和「凭证不可用」区分开。前者是可恢复的瞬时状态，后者才是真正的故障。

可观测性：这一步别省

凭证相关的故障排查成本高，是因为它默认是「黑盒」。至少暴露三个指标：

• 当前凭证的剩余有效期（Gauge）；
• 刷新成功/失败次数（Counter）；
• 刷新耗时分布（Histogram）。

再配一条告警：任意实例的凭证剩余有效期低于 2 分钟。这条规则能提前发现刷新链路卡死，比等到业务报 403 再查要早得多。

小结

临时凭证的正确使用，重点不在「怎么换」，而在「什么时候换、换不动怎么办」。把刷新窗口留足、把并发放进锁里、把失败降级写清楚，这三件事做完，凭证刷新就不再是需要半夜起来处理的隐患。