mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +03:00
Feng Ruohang
fd2ca1c6d2
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>
173 lines
4.4 KiB
Markdown
173 lines
4.4 KiB
Markdown
# Silo Admin Multi-user Quickstart Guide
|
|
|
|
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
|
|
|
|
In this document we will explain in detail on how to configure admin users.
|
|
|
|
### 1. Prerequisites
|
|
|
|
- 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
|
|
|
|
Use [`mc admin policy`](https://silo.pgsty.com/reference/minio-mc-admin/mc-admin-policy/#command-mc.admin.policy) to create custom admin policies.
|
|
|
|
Create new canned policy file `adminManageUser.json`. This policy enables admin user to
|
|
manage other users.
|
|
|
|
```json
|
|
cat > adminManageUser.json << EOF
|
|
{
|
|
"Version": "2012-10-17",
|
|
"Statement": [
|
|
{
|
|
"Action": [
|
|
"admin:CreateUser",
|
|
"admin:DeleteUser",
|
|
"admin:ConfigUpdate"
|
|
],
|
|
"Effect": "Allow",
|
|
"Sid": ""
|
|
},
|
|
{
|
|
"Action": [
|
|
"s3:*"
|
|
],
|
|
"Effect": "Allow",
|
|
"Resource": [
|
|
"arn:aws:s3:::*"
|
|
],
|
|
"Sid": ""
|
|
}
|
|
]
|
|
}
|
|
EOF
|
|
```
|
|
|
|
Create new canned policy by name `userManager` using `userManager.json` policy file.
|
|
|
|
```
|
|
mc admin policy attach mysilo userManager adminManageUser.json
|
|
```
|
|
|
|
Create a new admin user `admin1` on Silo use `mc admin user`.
|
|
|
|
```
|
|
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 mysilo userManager --user=admin1
|
|
```
|
|
|
|
This admin user will then be allowed to perform create/delete user operations via `mc admin user`
|
|
|
|
### 3. Configure `mc` and create another user user1 with attached policy user1policy
|
|
|
|
```
|
|
mc alias set mysilo-admin1 http://localhost:9000 admin1 admin123 --api s3v4
|
|
|
|
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
|
|
|
|
#### Config management permissions
|
|
|
|
- admin:ConfigUpdate
|
|
|
|
#### User management permissions
|
|
|
|
- admin:CreateUser
|
|
- admin:DeleteUser
|
|
- admin:ListUsers
|
|
- admin:EnableUser
|
|
- admin:DisableUser
|
|
- admin:GetUser
|
|
|
|
#### Service management permissions
|
|
|
|
- admin:ServerInfo
|
|
- admin:ServerUpdate
|
|
- admin:StorageInfo
|
|
- admin:DataUsageInfo
|
|
- admin:TopLocks
|
|
- admin:OBDInfo
|
|
- admin:Profiling,
|
|
- admin:ServerTrace
|
|
- admin:ConsoleLog
|
|
- admin:KMSKeyStatus
|
|
- admin:KMSCreateKey
|
|
- admin:ServiceRestart
|
|
- admin:ServiceStop
|
|
- admin:Prometheus
|
|
- admin:ForceUnlock
|
|
- admin:TopLocksInfo
|
|
- admin:BandwidthMonitor
|
|
|
|
#### User/Group management permissions
|
|
|
|
- admin:AddUserToGroup
|
|
- admin:RemoveUserFromGroup
|
|
- admin:GetGroup
|
|
- admin:ListGroups
|
|
- admin:EnableGroup
|
|
- admin:DisableGroup
|
|
|
|
#### Policy management permissions
|
|
|
|
- admin:CreatePolicy
|
|
- admin:DeletePolicy
|
|
- admin:GetPolicy
|
|
- admin:AttachUserOrGroupPolicy
|
|
- admin:ListUserPolicies
|
|
|
|
#### Heal management permissions
|
|
|
|
- admin:Heal
|
|
|
|
#### Service account management permissions
|
|
|
|
- admin:CreateServiceAccount
|
|
- admin:UpdateServiceAccount
|
|
- admin:RemoveServiceAccount
|
|
- admin:ListServiceAccounts
|
|
|
|
#### Bucket quota management permissions
|
|
|
|
- admin:SetBucketQuota
|
|
- admin:GetBucketQuota
|
|
|
|
#### Bucket target management permissions
|
|
|
|
- admin:SetBucketTarget
|
|
- admin:GetBucketTarget
|
|
|
|
#### Remote tier management permissions
|
|
|
|
- admin:SetTier
|
|
- admin:ListTier
|
|
|
|
#### Give full admin permissions
|
|
|
|
- admin:*
|
|
|
|
### 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 [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) to manage users with an IDP.
|
|
|
|
## Explore Further
|
|
|
|
- [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/)
|