本文旨在澄清minio中桶策略与iam策略的区别及其应用场景。minio的桶策略主要用于管理匿名访问权限，而要对特定用户进行精细化权限控制，则必须通过创建和应用iam策略来实现。教程将指导您如何利用minio的iam功能，为用户配置专属的访问权限。
在MinIO存储系统中，权限管理是确保数据安全和访问控制的关键环节。许多用户在配置MinIO时，可能会参考AWS S3的策略示例，并尝试将AWS S3中用于特定用户的桶策略概念应用于MinIO，这往往会导致混淆。本文将详细阐述MinIO中桶策略（Bucket Policy）与IAM策略（Identity and Access Management Policy）的根本区别，并指导您如何正确地为特定用户配置访问权限。
MinIO策略概述：桶策略与IAM策略
MinIO提供了两种核心的权限管理机制，它们服务于不同的目的和用户群体：
- 桶策略（Bucket Policy）：主要用于控制匿名用户对特定桶或桶内对象的访问权限。这意味着，任何未经验证的请求（即没有提供Access Key和Secret Key的请求）都将受到桶策略的约束。
- IAM策略（Identity and Access Management Policy）：用于为MinIO中的特定用户（即已通过mc admin user add等命令创建的，拥有Access Key和Secret Key的用户）定义精细化的访问权限。这些策略决定了认证用户可以对哪些资源执行哪些操作。
理解这两者之间的差异至关重要。AWS S3的桶策略可以包含Principal字段来指定特定的IAM用户或角色，从而直接在桶级别限制特定用户的访问。然而，MinIO的桶策略设计理念有所不同，它主要聚焦于匿名访问的控制。
MinIO桶策略：匿名访问的守护者
在MinIO中，桶策略的核心功能是管理那些未经验证的请求。例如，如果您希望一个桶中的所有对象都能被公开读取，您可以配置一个允许匿名s3:GetObject操作的桶策略。
示例：允许匿名用户读取特定桶
假设您有一个名为public-data的桶，并希望任何人都可以下载其中的文件。您可以创建一个桶策略，并使用mc命令将其应用：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::public-data/*"
]
}
]
}将上述JSON保存为public-read-policy.json，然后执行：
# mc admin policy create myminio public-read-policy public-read-policy.json # 注意：桶策略是直接设置在桶上的，而不是通过mc admin policy create来创建的IAM策略 # 对于桶策略，您需要使用mc policy set mc policy set download myminio/public-data
上述mc policy set download命令实际上是MinIO CLI提供的一个便捷方式，用于设置桶的公共下载权限，其背后就是配置了一个允许匿名读取的桶策略。
关键点： 在MinIO的桶策略中，Principal字段通常为*，表示所有用户（包括匿名用户），或者在某些情况下，MinIO会隐式处理，将其作为匿名请求的策略来评估。它不直接用于指定MinIO中的特定已认证用户。
通过IAM策略实现特定用户权限控制
要对MinIO中的特定用户进行权限限制，您必须使用IAM策略。IAM策略允许您为用户定义非常细粒度的权限，例如允许用户A只对mybucket进行只读操作，而用户B则拥有对admin-bucket的完全控制权。
以下是为特定用户配置IAM策略的步骤：
1. 创建自定义IAM策略文件
首先，定义一个JSON格式的IAM策略，指定允许或拒绝的操作（Action）和资源（Resource）。
示例：创建一个只读策略，允许用户读取mybucket中的内容
假设您希望创建一个名为read_only_policy的策略，允许用户读取mybucket桶及其中的对象，并列出该桶的内容。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::mybucket",
"arn:aws:s3:::mybucket/*"
]
}
]
}将上述JSON内容保存为policy-readonly.json文件。
2. 创建MinIO用户（如果尚未存在）
如果目标用户尚未在MinIO中创建，您需要先创建一个用户。
示例：创建一个名为read_only_user的用户
mc admin user add myminio read_only_user strong-password123
请替换myminio为您的MinIO别名，read_only_user为用户名，strong-password123为安全的密码。
3. 将策略附加到用户
使用mc admin policy set命令将创建的IAM策略附加给指定的用户。
示例：将read_only_policy策略附加给read_only_user
# 首先，将策略文件上传到MinIO并命名为read-only-policy mc admin policy create myminio read-only-policy policy-readonly.json # 然后，将该策略附加给用户 mc admin policy set myminio read-only-policy user=read_only_user
执行上述命令后，read_only_user将只能执行s3:GetObject和s3:ListBucket操作，且仅限于mybucket桶。尝试对mybucket执行其他操作（如s3:PutObject）或访问其他桶都将被拒绝。
MinIO与AWS S3策略的Principal差异
在原始问题中，用户对AWS S3策略中"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]}的格式感到困惑，并试图在MinIO中找到类似的用户标识符。
核心区别在于：
- AWS S3桶策略：Principal字段用于在策略中明确指定哪个AWS IAM用户、角色或账户被允许或拒绝访问。
-
MinIO IAM策略：当您使用mc admin policy set myminio
user= 命令将一个IAM策略附加给MinIO用户时，该策略的Principal就是这个被附加的用户。您无需在策略JSON文件中显式声明Principal字段。MinIO系统会自动将此策略与特定用户关联起来，并在该用户进行操作时进行评估。因此，您不需要查找MinIO用户的“ARN”或“用户标识符”来将其放入策略的Principal字段。
注意事项与最佳实践
- 理解策略评估顺序：MinIO会根据请求类型（匿名或认证）和策略类型（桶策略或IAM策略）来评估权限。认证用户的请求会优先通过其IAM策略进行评估。
- 最小权限原则：始终遵循最小权限原则，即只授予用户完成其任务所需的最小权限。避免授予不必要的s3:*权限。
- 资源路径的精确性：在策略的Resource字段中，精确指定桶名和对象路径，避免使用过于宽泛的通配符，除非确实需要。例如，arn:aws:s3:::mybucket/*表示mybucket桶中的所有对象，而arn:aws:s3:::mybucket则通常指桶本身（例如ListBucket操作）。
- 定期审计：定期审查您的MinIO用户、组及其附加的IAM策略，确保权限配置仍然符合安全要求。
总结
MinIO的权限管理体系清晰地划分了匿名访问控制（通过桶策略）和认证用户访问控制（通过IAM策略）。要限制特定用户的访问权限，您应该创建IAM策略，定义具体的允许/拒绝操作和资源，然后将这些策略附加到相应的MinIO用户。通过这种方式，您可以实现对MinIO存储资源的精细化、安全访问控制。
