应用访问AWS API时，长期访问密钥容易进入环境配置、镜像层、脚本、备份和日志，泄露后通常还要依赖人工轮换。IAM角色提供一种身份授权机制：可信主体在满足信任条件时取得有时限的临时凭据，再按角色权限访问资源。将角色用于工作负载，可以减少静态秘密，同时保留“哪个应用在调用”的身份线索。实施时必须分别审查谁能担任角色、角色能访问什么，以及应用能否正确刷新凭据。
角色信任策略定义允许担任角色的主体及条件，权限策略定义该角色获准执行的操作和目标资源。二者不能互相替代：主体被允许担任角色，不代表角色权限合理；权限策略很窄，也不能弥补过宽的信任关系。为EC2工作负载配置实例角色时，信任主体应对应合适的AWS服务；容器、函数或外部部署平台应使用与其运行环境匹配的身份方式。
权限策略尽量明确操作、资源和必要条件，避免无边界通配。角色可按应用和环境拆分，使测试工作负载不能意外获得生产数据访问。对跨账号访问，要分别检查调用方身份的担任权限、目标角色信任条件以及最终角色权限。角色的名称不能证明其边界，需查看实际策略和最近调用。
在AWS托管计算环境中，应用应使用官方SDK支持的默认凭据提供链，从运行环境取得角色凭据。SDK通常可处理临时凭据刷新，但应用若自行复制凭据到静态配置、手写缓存或在启动时只读取一次，就可能在会话到期后失败。确认应用使用的SDK实现了适当的提供器，避免把临时密钥、会话令牌和访问密钥写入日志或诊断页面。
网络层也会影响凭据获取。实例元数据访问需遵守平台的安全设置，应用应避免接受不可信输入后转发到元数据端点。容器环境要确认容器获得的是预期工作负载身份，而不是宿主机上更宽权限的身份。系统时间偏差、代理配置、DNS或元数据路由故障，都可能表现为凭据获取或签名失败。
aws sts get-caller-identity确认当前主体，并测试目标API及预期拒绝的越权操作。遇到拒绝时，先核对账号、区域、资源ARN、信任关系和条件键，再检查权限策略与服务控制边界等上层约束。若看到成功的API调用，还要确认审计中的主体确实是目标角色，不能只依据业务结果推断切换完成。
验收需覆盖四个方面：运行主体是预期角色；必要API操作成功；超出权限范围的操作被拒绝；临时会话续期或重新获取后应用仍正常工作。结合审计记录检查主体、会话名称、操作和资源，检查应用配置、镜像和日志中不再包含长期凭据。再观察一段完整业务周期，确保批处理和低频任务也已切换。
后续复核角色信任条件、权限范围、长期未使用角色和异常担任行为。角色减少静态凭据风险，但不会自动带来最小权限；只有身份边界和资源边界都经过验证，临时凭据的优势才真正落地。✅
