mc admin policy list myminio 和 mc anonymous get-json data/openbayes区别
这两个命令不是一回事 ,主要区别在于 mc admin policy 和 mc anonymous 操作的是不同层面的权限。
1. mc admin policy list myminio
mc admin policy list myminio
这是查看 MinIO 服务端已经定义的 IAM Policy。
例如你可能看到:
consoleAdmin
diagnostics
readonly
readwrite
writeonly
它回答的是:
MinIO 里有哪些 Policy?
如果你有自定义策略,比如:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::openbayes/*"]
}
]
}
那么这个 Policy 可以通过:
mc admin policy create myminio mypolicy policy.json
创建,然后绑定给用户:
mc admin policy attach myminio mypolicy --user xxx
2. mc anonymous get-json myminio/data/openbayes
这个是完全不同的东西:
mc anonymous get-json myminio/data/openbayes
它查看的是 bucket 的匿名访问策略。
也就是:
不登录 MinIO 的情况下,匿名用户能不能访问这个 bucket?能干什么?
例如你之前看到:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": ["*"]
},
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::openbayes/*"
]
}
]
}
这里的:
"Principal": {
"AWS": ["*"]
}
意味着所有匿名用户。
所以:
mc anonymous get-json
关注的是:
匿名用户
↓
bucket
↓
允许哪些 S3 操作
而:
mc admin policy list
关注的是:
MinIO IAM Policy
↓
用户 / ServiceAccount / Group
↓
允许哪些 S3 操作
结合你现在的 openbayes 场景
你现在很可能同时存在两套权限:
MinIO
│
┌───────────┴───────────┐
│ │
IAM Policy Anonymous Policy
│ │
登录用户/账号 未登录用户
│ │
mc admin policy ... mc anonymous ...
所以如果你的目标是:
让浏览器可以直接访问
openbayes/xxx/logo.png,但是不允许用户列出 bucket
那么你应该主要看:
mc anonymous get-json myminio/data/openbayes
而不是:
mc admin policy list myminio
匿名策略可以做到:
"Action": [
"s3:GetObject"
]
而不授予:
s3:ListBucket
这样:
GET /openbayes/xxx/logo.png
↓
允许
GET /openbayes/
↓
不允许
这正是你前面想实现的效果。
另外,你这里的 data/openbayes 要注意:data 是 mc alias ,openbayes 才是 bucket。也就是说:
mc anonymous get-json myminio/data/openbayes
和:
mc anonymous get-json myminio/openbayes
指向的对象可能完全不同,取决于你 alias 的配置。
mc anonymous set-json /tmp/openbayes-anonymous.json myminio/openbayes 为啥 admin policy 不能这么应用
因为 admin policy 和 anonymous 本质上是两套不同的配置入口,虽然它们最后都长得像 AWS IAM Policy JSON。
你这个命令:
mc anonymous set-json /tmp/openbayes-anonymous.json myminio/openbayes
实际上是在做:
bucket openbayes
↓
Anonymous Access Policy
↓
所有未认证请求
而 mc admin policy 操作的是:
MinIO IAM Policy
↓
User / Group / Service Account
↓
认证后的请求
为什么不能直接这样?
你可能会想到:
mc admin policy set-json /tmp/openbayes-anonymous.json myminio/openbayes
或者:
mc admin policy create myminio openbayes /tmp/openbayes-anonymous.json
问题在于 Policy 本身只是"权限规则",它还需要一个身份主体来生效。
例如:
{
"Effect": "Allow",
"Principal": {
"AWS": ["*"]
},
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::openbayes/*"]
}
这里:
"Principal": {
"AWS": ["*"]
}
表达的是:
所有人,包括匿名请求。
但 mc admin policy 管理的是 IAM Policy,它通常需要挂载到:
user
group
service account
例如:
mc admin policy create myminio openbayes-read /tmp/policy.json
mc admin policy attach myminio openbayes-read \
--user someuser
于是变成:
someuser
↓
openbayes-read
↓
s3:GetObject
↓
openbayes/*
匿名请求没有 user 身份,所以没有东西可以让 admin policy attach 去绑定。
这也是为什么 MinIO 有两个命令
| 命令 | 管理对象 | 典型用途 |
|---|---|---|
mc admin policy |
IAM Policy | 控制认证用户 |
mc anonymous |
Bucket Anonymous Policy | 控制匿名访问 |
所以你之前这个需求:
不允许
ListBucket,但是允许浏览器直接 GET logo
最合适的就是:
mc anonymous set-json /tmp/openbayes-anonymous.json myminio/openbayes
策略:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": ["*"]
},
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::openbayes/*"
]
}
]
}
这样:
匿名 GET /openbayes/logo.png ✅
匿名 GET /openbayes/xxx/a.png ✅
匿名 ListBucket openbayes ❌
匿名查看 bucket 文件列表 ❌
而且这里不需要创建 MinIO 用户。
一句话总结:
mc admin policy是"这个用户能干什么";mc anonymous是"没登录的人能干什么"。你这个
Principal: "*"的场景,本质上属于后者。