MinIO/S3项目数据集存储结构、权限配置及上传下载方案咨询

一、规范存储结构（规避策略限制的核心） #

采用单桶+层级前缀的结构，完全镜像Postgres中的项目-数据集层级：

mybucket/
├─ project_id_1/
│  ├─ dataset_id_1/
│  ├─ dataset_id_2/
│  └─ ...
├─ project_id_2/
│  ├─ dataset_id_1/
│  └─ ...
└─ ...

这个结构的优势：

• 用前缀匹配替代逐个数据集的权限配置，彻底避免策略长度/数量限制
• 与Postgres的主数据结构完全对齐，便于后续同步和维护

二、LDAP用户的项目级权限配置 #

MinIO完美支持LDAP用户的组权限管理，分两种场景处理：

场景1：LDAP已存在项目对应组 #

直接将LDAP组与MinIO策略绑定：

1. 确保MinLDAP认证已配置完成，能同步LDAP组信息
2. 创建针对项目的只读策略（以project_id_1为例），策略JSON如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::mybucket",
        "arn:aws:s3:::mybucket/project_id_1/*"
      ]
    }
  ]
}

3. 将LDAP中的project_id_1_readers组与该策略关联，组内所有LDAP用户自动获得对应项目的只读权限

场景2：LDAP无对应项目组（创建MinIO专属组） #

MinIO支持创建本地用户组，并关联LDAP用户：

1. 通过MinIO控制台或mc admin group add命令创建本地组，例如project_id_1_readers
2. 使用mc admin group add user命令将指定LDAP用户加入该组（LDAP用户需已通过MinIO认证）
3. 为该组绑定上述的项目只读策略，实现组内用户的统一权限控制

这种方式的核心是一个项目对应一个策略+一个组，不管项目下有多少数据集，都通过前缀project_id_<X>/*覆盖，完全不会触发策略数量或长度限制。

三、上传下载流程优化 #

1. 前端直接上传（无需每次请求预签名URL） #

使用MinIO的STS临时凭证机制：

• 后端从Postgres获取用户可访问的项目列表，调用MinIO的STS API生成临时凭证
• 临时凭证可限制允许上传的前缀（例如mybucket/project_id_1/dataset_id_1/*），确保权限合规
• 前端拿到临时凭证后，直接使用MinIO SDK或S3兼容的上传工具，在凭证有效期内（可配置，比如1小时）直接上传文件，无需每次请求预签名URL

2. Rclone直接下载（无需自行开发下载器） #

配置Rclone连接MinIO时，使用LDAP认证信息或STS临时凭证：

• 方式1：LDAP用户名密码直接认证
  在Rclone配置文件中设置：

  [minio]
  type = s3
  provider = Minio
  env_auth = false
  access_key = <LDAP用户名>
  secret_key = <LDAP密码>
  endpoint = <MinIO服务地址>
  

  配置完成后，直接使用rclone copy minio:mybucket/project_id_1/ <本地路径>即可下载对应项目的所有文件
• 方式2：STS临时凭证认证
  将后端生成的STS临时access_key、secret_key、session_token填入Rclone配置，同样可直接访问对应权限的前缀

关键注意事项 #

• 定期同步Postgres中的项目-用户权限关系到MinIO的组配置，可通过脚本自动完成（例如监听Postgres的权限变更事件，调用MinIO API更新组成员）
• 策略中的ListBucket权限需授予整个桶，但通过前缀过滤，用户只能看到自己有权访问的项目前缀
• STS临时凭证的有效期根据业务需求调整，平衡安全性和便利性

内容的提问来源于stack exchange，提问作者Dtag