详细介绍:在Minio以STS方式获得临时凭据
前言
在使用对象存储服务(如MinIO)时,安全性始终是首要考虑的问题。直接将长期访问密钥(Access Key 和 Secret Key)暴露给前端应用或不可信的客户端,存在极大的安全风险——一旦泄露,攻击者可能长期非法访问存储资源。为了解决这一问题,MinIO 提供了基于 STS(Security Token Service,安全令牌服务) 的临时凭据机制,允许用户动态获取具有有限权限和有效期的临时访问凭证,既满足业务需求,又大幅提升安全性。
一、STS 临时凭据的核心概念
- 什么是 STS?
STS 是一种安全服务,允许用户通过调用接口动态申请临时访问凭证(包括临时 Access Key、Secret Key 和 Security Token)。这些临时凭证具有以下特性:
- 时效性:默认有效期较短(如 15 分钟~1 小时),过期后自动失效。
- 权限受限:临时凭证的权限由关联的 策略(Policy) 严格限制,仅能执行被明确授权的操作(例如仅允许上传到特定 Bucket)。
- 不可长期持有:无法像长期密钥一样长期使用,需每次使用时重新申请。
- 为什么需要 STS?
- 避免长期密钥泄露:前端应用(如 Web/移动端)无需直接接触长期 Access Key,降低因代码泄露导致的数据风险。
- 精细化权限控制:通过策略动态定义临时凭证的权限范围(例如“仅允许上传图片到 user-uploads/目录”)。
- 符合最小权限原则:临时凭证仅授予完成当前任务所需的最小权限,减少攻击面
二、MinIO 对 STS 的支持
MinIO 完全兼容 AWS S3 的 STS API(基于 AWS Signature V4),因此可以直接使用 AWS 官方文档中的 STS 接口规范(如 AssumeRole)。MinIO 的 STS 服务默认内置于服务中,无需额外部署组件,只需正确配置即可使用。
关键点:
- MinIO 的 STS 接口地址通常与主服务一致(如 http://minio.example.com),通过特定路径(如 /sts)访问。
- 需要为 STS 操作配置一个 角色(Role) 或 策略模板,用于定义临时凭证的权限。
- 客户端通过调用 AssumeRole接口(或其他 STS 接口,如 GetFederationToken),传入角色信息及可选参数(如会话名称),获取临时凭证。
三、配置
1.创建策略


{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::*"
]
}
]
}
2.创建用户,绑定策略


3.通过Java 获得凭据
public CredentialsToken getCredentials() {
try {
AssumeRoleProvider provider = new AssumeRoleProvider(OssConfiguration.endpoint, OssConfiguration.stsUser,
OssConfiguration.stsPassword, Math.toIntExact(OssConfiguration.expire),
null, OssConfiguration.region, null, null, null, null);
Credentials credential = provider.fetch();
return new CredentialsToken(credential.accessKey(), credential.secretKey(), credential.sessionToken(), OssConfiguration.expire);
} catch (NoSuchAlgorithmException e) {
log.debug("Failed to obtain sts.");
e.printStackTrace();
}
return null;
}
总结
通过 MinIO 的 STS 机制,开发者可以安全地实现“按需授权、临时访问”的对象存储方案,有效平衡业务灵活性与数据安全性。无论是前端直传、第三方集成还是多租户场景,STS 都是推荐的实践方式。结合自定义策略和合理的有效期设置,能够进一步降低安全风险,构建可靠的云存储架构。

浙公网安备 33010602011771号