MinIO 的 STS 尝试及注意事项

发表于 分类于 阅读次数： Valine： 本文字数： 1.6k 阅读时长 ≈ 1 分钟

前言

在上一篇博文 进可攻退可守的存储解决方案 中，有提到两种文件保护方式：一种是多用户方式，每个用户使用单独的 KEY 和 SECRET 上传下载；另外一种则是生成带签名的 URL 给用户上传下载。

多用户方式下，除了创建长期用户，还可以通过 MinIO 提供的 Security Token Service（STS）创建「临时的用户身份」和对应的 KEY 与 SECRET，用户在有效内可以凭此进行文件上传与下载活动。

需要注意的是，如果是将 MinIO 运行在 gateway 模式下，同样需要 etcd 的配合使用，才能使用 STS。

STS 简介

用户通过 MinIO 提供的 STS 服务，可以获取临时凭证，进而对 MinIO 上的资源进行操作。临时凭证与 MinIO 安装时的默认凭证类似，但有一些细微的差别：

  • 正如它的名字一样，临时凭证有一定的有效期。一旦过期，MinIO 将会直接拒绝来自它的任何请求。
  • 临时凭证并不需要存储在 MinIO 应用上，一旦有需要，可以随时请求 STS 服务生成。

使用 STS 有以下几点优势：

  • 不需要产生大量的长期凭证
  • 不需要将对存储桶和特定资源的访问权限静态配置在长期凭证中
  • 不需要显性地作废凭证，因为 STS 自带有效期

总的来说，使用 STS 可以减少用户及权限管理带来的一堆琐碎的工作。

Assume Role

MinIO 提供了三种方式：Client grants、WebIdentity 和 AssumeRole，具体可以看 MinIO STS Quickstart Guide 介绍。

考虑到相比前两种，第三个方式比较轻量，而且可以生成临时的 KEY 和 SECRET，配合 MinIO 的 JS SDK，可以比较方便地实现文件的受限访问。

项目使用的框架是 Laravel，相关包是 aws/aws-sdk-php，在这里给下我的操作代码，希望能够帮到有需要的人。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* @var StsClient $stsClient */
$stsClient = new \Aws\Sts\StsClient([
    'credentials' => [
		'key'    => 'your-key',
		'secret' => 'your-secret'
	],
	'region' => 'default',
	'version' => 'latest',
	'bucket_endpoint' => false,
	'use_path_style_endpoint' => true,
	'endpoint'  => 'http://your-minio-endpoint:9000'
]);

$assumeRoleResult = $client->assumeRole([
    'RoleArn' => 'arn:ssssxxx:xxx:xxx:xxxx',
    'RoleSessionName' => 'role-session-name'
]);

$stsClient->createCredentials($assumeRoleResult);

出于安全考虑，建议使用新建的用户的 KEY 和 SECRET 创建凭证，更多安全策略请参考 IAM 最佳实践。在创建凭证时，可以限制存储桶、特定资源、特定操作以及用户的 IP 和客户端等等，具体请自行谷歌。

结语

嗯，凑数用的一节。

总的来说，MinIO 是个好东西，STS 也不错（虽然文档搓了点），欢迎大家一起用 & 交流！