astelm/minio
1
0
Fork 0
mirror of https://github.com/pgsty/minio.git synced 2026-08-09 15:53:28 +03:00
Code Issues Packages Projects Releases Wiki Activity

docs: rebrand the repository documentation, templates and dashboards

Browse Source 
README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE,
code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue
and pull request templates, and the docs/ tree all present Silo as the product.
The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel
titles and descriptions rebranded while every minio_* query, label and
expression is left alone, so existing alerts and recording rules keep matching.

The distinction the review demanded is applied per hit rather than by
search-and-replace:

- Product and command text becomes Silo and silo: install and run instructions,
  systemd examples, compose services, download links, badges.
- Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics,
  x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and
  error names.
- Attribution keeps MinIO and gains the fork's own: the AGPL obligations,
  original copyright, CREDITS and NOTICE stay, with the modification notice
  added alongside rather than replacing them.
- Historical and third-party references are left as facts, not rewritten for
  brand tidiness.

README and README_ZH each carry an explicit non-affiliation notice, document
the side-by-side package migration including the
/etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a
legacy UID/GID, and state that recursive chown is never performed. The trademark
attribution uses the policy's approved "based on MinIO technology" wording, not
the shortened form the policy rejects.

github.com/pgsty/minio links are left in place and labelled transitional. The
repository has not been renamed, and rewriting them now would produce documented
URLs that 404 until the cutover; they change in the cutover commit together with
the goreleaser release target, the OCI source label and the raw-content branch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Feng Ruohang
2026-08-06 08:49:30 +08:00
parent 6613c2a3cb
commit fd2ca1c6d2
94 changed files with 1613 additions and 1347 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/multi-user/README.md
+32 -32
View File
@@ -1,6 +1,6 @@
# MinIO Multi-user Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
# Silo Multi-user Quickstart Guide
MinIO supports multiple long term users in addition to default user created during server startup. New users can be added after server starts up, and server can be configured to deny or allow access to buckets and resources to each of these users. This document explains how to add/remove users and modify their access rights.
Silo supports multiple long term users in addition to default user created during server startup. New users can be added after server starts up, and server can be configured to deny or allow access to buckets and resources to each of these users. This document explains how to add/remove users and modify their access rights.
## Get started
@@ -8,8 +8,8 @@ In this document we will explain in detail on how to configure multiple users.
### 1. Prerequisites
- Install mc - [MinIO Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
- Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
- Install mc - [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
- Configure etcd - [Etcd V3 Quickstart Guide](https://github.com/pgsty/minio/blob/master/docs/sts/etcd.md)
### 2. Create a new user with canned policy
@@ -41,31 +41,31 @@ EOF
Create new canned policy by name `getonly` using `getonly.json` policy file.
```
mc admin policy create myminio getonly getonly.json
mc admin policy create mysilo getonly getonly.json
```
Create a new user `newuser` on MinIO use `mc admin user`.
Create a new user `newuser` on Silo use `mc admin user`.
```
mc admin user add myminio newuser newuser123
mc admin user add mysilo newuser newuser123
```
Once the user is successfully created you can now apply the `getonly` policy for this user.
```
mc admin policy attach myminio getonly --user=newuser
mc admin policy attach mysilo getonly --user=newuser
```
### 3. Create a new group
```
mc admin group add myminio newgroup newuser
mc admin group add mysilo newgroup newuser
```
Once the group is successfully created you can now apply the `getonly` policy for this group.
```
mc admin policy attach myminio getonly --group=newgroup
mc admin policy attach mysilo getonly --group=newgroup
```
### 4. Disable user
@@ -73,13 +73,13 @@ mc admin policy attach myminio getonly --group=newgroup
Disable user `newuser`.
```
mc admin user disable myminio newuser
mc admin user disable mysilo newuser
```
Disable group `newgroup`.
```
mc admin group disable myminio newgroup
mc admin group disable mysilo newgroup
```
### 5. Remove user
@@ -87,19 +87,19 @@ mc admin group disable myminio newgroup
Remove the user `newuser`.
```
mc admin user remove myminio newuser
mc admin user remove mysilo newuser
```
Remove the user `newuser` from a group.
```
mc admin group remove myminio newgroup newuser
mc admin group remove mysilo newgroup newuser
```
Remove the group `newgroup`.
```
mc admin group remove myminio newgroup
mc admin group remove mysilo newgroup
```
### 6. Change user or group policy
@@ -107,13 +107,13 @@ mc admin group remove myminio newgroup
Change the policy for user `newuser` to `putonly` canned policy.
```
mc admin policy attach myminio putonly --user=newuser
mc admin policy attach mysilo putonly --user=newuser
```
Change the policy for group `newgroup` to `putonly` canned policy.
```
mc admin policy attach myminio putonly --group=newgroup
mc admin policy attach mysilo putonly --group=newgroup
```
### 7. List all users or groups
@@ -121,27 +121,27 @@ mc admin policy attach myminio putonly --group=newgroup
List all enabled and disabled users.
```
mc admin user list myminio
mc admin user list mysilo
```
List all enabled or disabled groups.
```
mc admin group list myminio
mc admin group list mysilo
```
### 8. Configure `mc`
```
mc alias set myminio-newuser http://localhost:9000 newuser newuser123 --api s3v4
mc cat myminio-newuser/my-bucketname/my-objectname
mc alias set mysilo-newuser http://localhost:9000 newuser newuser123 --api s3v4
mc cat mysilo-newuser/my-bucketname/my-objectname
```
### Policy Variables
You can use policy variables in the *Resource* element and in string comparisons in the *Condition* element.
You can use a policy variable in the Resource element, but only in the resource portion of the ARN. This portion of the ARN appears after the 5th colon (:). You can't use a variable to replace parts of the ARN before the 5th colon, such as the service or account. The following policy might be attached to a group. It gives each of the users in the group full programmatic access to a user-specific object (their own "home directory") in MinIO.
You can use a policy variable in the Resource element, but only in the resource portion of the ARN. This portion of the ARN appears after the 5th colon (:). You can't use a variable to replace parts of the ARN before the 5th colon, such as the service or account. The following policy might be attached to a group. It gives each of the users in the group full programmatic access to a user-specific object (their own "home directory") in Silo.
```
{
@@ -190,7 +190,7 @@ If the user is authenticating using an STS credential which was authorized from
- `jwt:scope`
- `jwt:client_id`
Following example shows OpenID users with full programmatic access to a OpenID user-specific directory (their own "home directory") in MinIO.
Following example shows OpenID users with full programmatic access to a OpenID user-specific directory (their own "home directory") in Silo.
```
{
@@ -222,7 +222,7 @@ Currently supports
- `ldap:user`
- `ldap:groups`
Following example shows LDAP users full programmatic access to a LDAP user-specific directory (their own "home directory") in MinIO.
Following example shows LDAP users full programmatic access to a LDAP user-specific directory (their own "home directory") in Silo.
```
{
@@ -250,9 +250,9 @@ Following example shows LDAP users full programmatic access to a LDAP user-speci
- `aws:CurrentTime` - This can be used for conditions that check the date and time.
- `aws:EpochTime` - This is the date in epoch or Unix time, for use with date/time conditions.
- `aws:PrincipalType` - This value indicates whether the principal is an account (Root credential), user (MinIO user), or assumed role (STS)
- `aws:PrincipalType` - This value indicates whether the principal is an account (Root credential), user (Silo user), or assumed role (STS)
- `aws:SecureTransport` - This is a Boolean value that represents whether the request was sent over TLS.
- `aws:SourceIp` - This is the requester's IP address, for use with IP address conditions. If running behind Nginx like proxies, MinIO preserve's the source IP.
- `aws:SourceIp` - This is the requester's IP address, for use with IP address conditions. If running behind Nginx like proxies, Silo preserve's the source IP.
```
{
@@ -266,13 +266,13 @@ Following example shows LDAP users full programmatic access to a LDAP user-speci
}
```
- `aws:UserAgent` - This value is a string that contains information about the requester's client application. This string is generated by the client and can be unreliable. You can only use this context key from `mc` or other MinIO SDKs which standardize the User-Agent string.
- `aws:username` - This is a string containing the friendly name of the current user, this value would point to STS temporary credential in `AssumeRole`ed requests, use `jwt:preferred_username` in case of OpenID connect and `ldap:username` in case of AD/LDAP. *aws:userid* is an alias to *aws:username* in MinIO.
- `aws:UserAgent` - This value is a string that contains information about the requester's client application. This string is generated by the client and can be unreliable. You can only use this context key from `mc` or other compatible SDKs which standardize the User-Agent string.
- `aws:username` - This is a string containing the friendly name of the current user, this value would point to STS temporary credential in `AssumeRole`ed requests, use `jwt:preferred_username` in case of OpenID connect and `ldap:username` in case of AD/LDAP. *aws:userid* is an alias to *aws:username* in Silo.
- `aws:groups` - This is an array containing the group names, this value would point to group mappings for the user, use `jwt:groups` in case of OpenID connect and `ldap:groups` in case of AD/LDAP.
## Explore Further
- [MinIO Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
- [Silo Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
- [The Silo documentation website](https://silo.pgsty.com/docs/)
docs/multi-user/admin/README.md
+17 -17
View File
@@ -1,6 +1,6 @@
# MinIO Admin Multi-user Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
# Silo Admin Multi-user Quickstart Guide
MinIO supports multiple admin users in addition to default operator credential created during server startup. New admins can be added after server starts up, and server can be configured to deny or allow access to different admin operations for these users. This document explains how to add/remove admin users and modify their access rights.
Silo supports multiple admin users in addition to default operator credential created during server startup. New admins can be added after server starts up, and server can be configured to deny or allow access to different admin operations for these users. This document explains how to add/remove admin users and modify their access rights.
## Get started
@@ -8,8 +8,8 @@ In this document we will explain in detail on how to configure admin users.
### 1. Prerequisites
- Install mc - [MinIO Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
- Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
- Install mc - [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
### 2. Create a new admin user with CreateUser, DeleteUser and ConfigUpdate permissions
@@ -50,19 +50,19 @@ EOF
Create new canned policy by name `userManager` using `userManager.json` policy file.
```
mc admin policy attach myminio userManager adminManageUser.json
mc admin policy attach mysilo userManager adminManageUser.json
```
Create a new admin user `admin1` on MinIO use `mc admin user`.
Create a new admin user `admin1` on Silo use `mc admin user`.
```
mc admin user add myminio admin1 admin123
mc admin user add mysilo admin1 admin123
```
Once the user is successfully created you can now apply the `userManage` policy for this user.
```
mc admin policy attach myminio userManager --user=admin1
mc admin policy attach mysilo userManager --user=admin1
```
This admin user will then be allowed to perform create/delete user operations via `mc admin user`
@@ -70,11 +70,11 @@ This admin user will then be allowed to perform create/delete user operations vi
### 3. Configure `mc` and create another user user1 with attached policy user1policy
```
mc alias set myminio-admin1 http://localhost:9000 admin1 admin123 --api s3v4
mc alias set mysilo-admin1 http://localhost:9000 admin1 admin123 --api s3v4
mc admin user add myminio-admin1 user1 user123
mc admin policy attach myminio-admin1 user1policy ~/user1policy.json
mc admin policy attach myminio-admin1 user1policy --user=user1
mc admin user add mysilo-admin1 user1 user123
mc admin policy attach mysilo-admin1 user1policy ~/user1policy.json
mc admin policy attach mysilo-admin1 user1policy --user=user1
```
### 4. List of permissions defined for admin operations
@@ -162,11 +162,11 @@ mc admin policy attach myminio-admin1 user1policy --user=user1
### 5. Using an external IDP for admin users
Admin users can also be externally managed by an IDP by configuring admin policy with
special permissions listed above. Follow [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) to manage users with an IDP.
special permissions listed above. Follow [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) to manage users with an IDP.
## Explore Further
- [MinIO Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
- [Silo Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
- [The Silo documentation website](https://silo.pgsty.com/docs/)