有效期是最省事的收敛手段
长期有效的凭据一旦泄露，只要没人发现就一直可用；而有效期短的凭据即使在传输中被截获，攻击者能利用的窗口也只有几分钟到几小时。这就是临时凭据的价值：它把安全性从「能不能拿到」部分转移到「拿到时还有没有用」。代价是引入了新的失败模式——过期时间与执行时长不匹配时，任务会在中途失败，且失败现象往往是权限错误而非过期提示。
基本信息
| 适用对象 | 云上资源访问、接口调用、跨系统任务委派 |
|---|---|
| 有效期设定 | 覆盖单次任务最长耗时并留出少量余量 |
| 关键风险 | 时钟偏移导致提前失效或延长可用期 |
| 续期方式 | 任务执行前续期，避免中途换凭据 |
| 与吊销关系 | 过期是自然失效，吊销是否即时生效取决于校验方式 |
有效期设计要点
- 按任务最长耗时定：以最慢一次执行时间为基准，并保留重试余量
- 执行前续期：在任务开始前换取，避免执行中途失效导致半途而废
- 避免长时间缓存：把临时凭据写入长期缓存后，短有效期的优势被抵消
- 关注时钟同步：签发端与使用端时间不一致会让有效期实际缩短或延长
- 区分过期与吊销：依赖无法实时校验的场景下，吊销不会立即生效
- 失败要有明确信号：过期导致的失败应能一眼识别，而不是表现为权限不足
有效期相关检查
有效期相关检查
date -u # 使用端时间，与签发端对比
timedatectl status # 系统时间同步状态
timeout 5 command # 给可能挂起的取用步骤设上限
openssl x509 -in cert.pem -noout -dates # 查看证书生效与失效时间
awk -F: '$2==""{print $1}' /etc/shadow # 找出无口令账号，确认是否预期
stat -c '%y %n' /run/secrets/token # 落盘凭据的时间戳，判断是否长期未更新有效期问题与表现
| 问题 | 表现 | 处置方向 |
|---|---|---|
| 有效期短于任务耗时 | 执行到一半报权限错误 | 按最长耗时重新设定 |
| 缓存超过有效期 | 间歇性认证失败 | 取消缓存或按需续期 |
| 时钟偏移较大 | 提前过期或过期后仍可用 | 统一时间同步源 |
| 依赖吊销而非过期 | 以为已失效实际仍可用 | 缩短有效期或加入实时校验 |
| 失败信息不明确 | 被误判为权限配置问题 | 在错误处理里区分过期状态 |
临时凭据并不等于安全凭据：有效期只限制时间窗口，不限制使用范围。因此仍需配合权限范围限制，把「能做什么」也一起收窄，否则短暂的高权限窗口依然可以造成大范围影响。
批量任务要专门处理过期：多台主机并发执行时，若凭据在批次中途过期，会出现部分成功部分失败。稳妥做法是在批次开始前统一换取，并在失败项上做一次带新凭据的重试。