mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 07:43:29 +03:00
docs: rebrand the repository documentation, templates and dashboards
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
@@ -1,10 +1,10 @@
|
||||
# Access Management Plugin Guide [](https://slack.minio.io)
|
||||
|
||||
MinIO now includes support for using an Access Management Plugin. This is to allow object storage access control to be managed externally via a webhook.
|
||||
Silo now includes support for using an Access Management Plugin. This is to allow object storage access control to be managed externally via a webhook.
|
||||
|
||||
When configured, MinIO sends request and credential details for every API call to an external HTTP(S) endpoint and expects an allow/deny response. MinIO is thus able to delegate access management to an external system, and users are able to use a custom solution instead of S3 standard IAM policies.
|
||||
When configured, Silo sends request and credential details for every API call to an external HTTP(S) endpoint and expects an allow/deny response. Silo is thus able to delegate access management to an external system, and users are able to use a custom solution instead of S3 standard IAM policies.
|
||||
|
||||
Latency sensitive applications may notice an increased latency due to a request to the external plugin upon every authenticated request to MinIO. User are advised to provision their infrastructure such that latency and performance is acceptable.
|
||||
Latency sensitive applications may notice an increased latency due to a request to the external plugin upon every authenticated request to Silo. User are advised to provision their infrastructure such that latency and performance is acceptable.
|
||||
|
||||
## Quickstart
|
||||
|
||||
@@ -16,27 +16,27 @@ go run access-manager-plugin.go
|
||||
|
||||
This program, lets the admin user perform any action and prevents all other users from performing `s3:Put*` operations.
|
||||
|
||||
In another terminal start MinIO:
|
||||
In another terminal start Silo:
|
||||
|
||||
```sh
|
||||
export MINIO_CI_CD=1
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
export MINIO_POLICY_PLUGIN_URL=http://localhost:8080/
|
||||
minio server /tmp/disk{1...4}
|
||||
silo server /tmp/disk{1...4}
|
||||
```
|
||||
|
||||
Now, let's test it out with `mc`:
|
||||
|
||||
```sh
|
||||
mc alias set myminio http://localhost:9000 minio minio123
|
||||
mc ls myminio
|
||||
mc mb myminio/test
|
||||
mc cp /etc/issue myminio/test
|
||||
mc admin user add myminio foo foobar123
|
||||
mc alias set mysilo http://localhost:9000 minio silo123
|
||||
mc ls mysilo
|
||||
mc mb mysilo/test
|
||||
mc cp /etc/issue mysilo/test
|
||||
mc admin user add mysilo foo foobar123
|
||||
export MC_HOST_foo=http://foo:foobar123@localhost:9000
|
||||
mc ls foo
|
||||
mc cp /etc/issue myminio/test/issue2
|
||||
mc cp /etc/issue mysilo/test/issue2
|
||||
```
|
||||
|
||||
Only the last operation would fail with a permissions error.
|
||||
@@ -46,7 +46,7 @@ Only the last operation would fail with a permissions error.
|
||||
Access Management Plugin can be configured with environment variables:
|
||||
|
||||
```sh
|
||||
$ mc admin config set myminio policy_plugin --env
|
||||
$ mc admin config set mysilo policy_plugin --env
|
||||
KEY:
|
||||
policy_plugin enable Access Management Plugin for policy enforcement
|
||||
|
||||
@@ -61,7 +61,7 @@ By default this plugin uses HTTP 1.x. To enable HTTP2 use the `MINIO_POLICY_PLUG
|
||||
|
||||
## Request and Response
|
||||
|
||||
MinIO will make a `POST` request with a JSON body to the given plugin URL. If the auth token parameter is set, it will be sent as an authorization header.
|
||||
Silo will make a `POST` request with a JSON body to the given plugin URL. If the auth token parameter is set, it will be sent as an authorization header.
|
||||
|
||||
The JSON body structure can be seen from this sample:
|
||||
|
||||
@@ -100,10 +100,10 @@ The JSON body structure can be seen from this sample:
|
||||
"127.0.0.1"
|
||||
],
|
||||
"User-Agent": [
|
||||
"MinIO (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
|
||||
"Silo (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
|
||||
],
|
||||
"UserAgent": [
|
||||
"MinIO (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
|
||||
"Silo (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
|
||||
],
|
||||
"X-Amz-Content-Sha256": [
|
||||
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
|
||||
@@ -137,7 +137,7 @@ The JSON body structure can be seen from this sample:
|
||||
|
||||
</details>
|
||||
|
||||
The response expected by MinIO, is a JSON body with a boolean:
|
||||
The response expected by Silo, is a JSON body with a boolean:
|
||||
|
||||
```json
|
||||
{
|
||||
|
||||
@@ -2,14 +2,14 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
To enable the integration of custom authentication methods, MinIO can be configured with an Identity Management Plugin webhook. When configured, this plugin enables the `AssumeRoleWithCustomToken` STS API extension. A user or application can now present a token to the `AssumeRoleWithCustomToken` API, and MinIO verifies this token by sending it to the Identity Management Plugin webhook. This plugin responds with some information and MinIO is able to generate temporary STS credentials to interact with object storage.
|
||||
To enable the integration of custom authentication methods, Silo can be configured with an Identity Management Plugin webhook. When configured, this plugin enables the `AssumeRoleWithCustomToken` STS API extension. A user or application can now present a token to the `AssumeRoleWithCustomToken` API, and Silo verifies this token by sending it to the Identity Management Plugin webhook. This plugin responds with some information and Silo is able to generate temporary STS credentials to interact with object storage.
|
||||
|
||||
The authentication flow is similar to that of OpenID, however the token is "opaque" to MinIO - it is simply sent to the plugin for verification. CAVEAT: There is no console UI integration for this method of authentication and it is intended primarily for machine authentication.
|
||||
The authentication flow is similar to that of OpenID, however the token is "opaque" to Silo - it is simply sent to the plugin for verification. CAVEAT: There is no console UI integration for this method of authentication and it is intended primarily for machine authentication.
|
||||
|
||||
It can be configured via MinIO's standard configuration API (i.e. using `mc admin config set/get`), or equivalently with environment variables. For brevity we show only environment variables here:
|
||||
It can be configured via Silo's standard configuration API (i.e. using `mc admin config set/get`), or equivalently with environment variables. For brevity we show only environment variables here:
|
||||
|
||||
```sh
|
||||
$ mc admin config set myminio identity_plugin --env
|
||||
$ mc admin config set mysilo identity_plugin --env
|
||||
KEY:
|
||||
identity_plugin enable Identity Plugin via external hook
|
||||
|
||||
@@ -25,11 +25,11 @@ If provided, the auth token parameter is sent as an authorization header.
|
||||
|
||||
`MINIO_IDENTITY_PLUGIN_ROLE_POLICY` is a required parameter and can be list of comma separated policy names.
|
||||
|
||||
On setting up the plugin, the MinIO server prints the Role ARN to its log. The Role ARN is generated by default based on the given plugin URL. To avoid this and use a configurable value set a unique role ID via `MINIO_IDENTITY_PLUGIN_ROLE_ID`.
|
||||
On setting up the plugin, the Silo server prints the Role ARN to its log. The Role ARN is generated by default based on the given plugin URL. To avoid this and use a configurable value set a unique role ID via `MINIO_IDENTITY_PLUGIN_ROLE_ID`.
|
||||
|
||||
## REST API call to plugin
|
||||
|
||||
To verify the custom token presented in the `AssumeRoleWithCustomToken` API, MinIO makes a POST request to the configured identity management plugin endpoint and expects a response with some details as shown below:
|
||||
To verify the custom token presented in the `AssumeRoleWithCustomToken` API, Silo makes a POST request to the configured identity management plugin endpoint and expects a response with some details as shown below:
|
||||
|
||||
### Request `POST` to plugin endpoint
|
||||
|
||||
@@ -59,7 +59,7 @@ A `200 OK` Response should have `application/json` content-type and body with th
|
||||
| maxValiditySeconds | integer (>= 900 seconds and < 365 days) | Maximum allowed expiry duration for the credentials |
|
||||
| claims | key-value pairs | Claims to be associated with the requested credentials |
|
||||
|
||||
The keys "exp", "parent" and "sub" in the `claims` object are reserved and if present are ignored by MinIO.
|
||||
The keys "exp", "parent" and "sub" in the `claims` object are reserved and if present are ignored by Silo.
|
||||
|
||||
If the token is not valid or access is not approved, the plugin must return a `403` (forbidden) HTTP status code. The body must have an `application/json` content-type with the following structure:
|
||||
|
||||
|
||||
+11
-11
@@ -1,8 +1,8 @@
|
||||
# OPA Quickstart Guide [](https://slack.minio.io)
|
||||
|
||||
OPA is a lightweight general-purpose policy engine that can be co-located with MinIO server, in this document we talk about how to use OPA HTTP API to authorize requests. It can be used with any type of credentials (STS based like OpenID or LDAP, regular IAM users or service accounts).
|
||||
OPA is a lightweight general-purpose policy engine that can be co-located with Silo server, in this document we talk about how to use OPA HTTP API to authorize requests. It can be used with any type of credentials (STS based like OpenID or LDAP, regular IAM users or service accounts).
|
||||
|
||||
OPA is enabled through MinIO's Access Management Plugin feature.
|
||||
OPA is enabled through Silo's Access Management Plugin feature.
|
||||
|
||||
## Get started
|
||||
|
||||
@@ -51,27 +51,27 @@ curl -X PUT --data-binary @example.rego \
|
||||
localhost:8181/v1/policies/putobject
|
||||
```
|
||||
|
||||
### 4. Setup MinIO with OPA
|
||||
### 4. Setup Silo with OPA
|
||||
|
||||
Set the `MINIO_POLICY_PLUGIN_URL` as the endpoint that MinIO should send authorization requests to. Then start the server.
|
||||
Set the `MINIO_POLICY_PLUGIN_URL` as the endpoint that Silo should send authorization requests to. Then start the server.
|
||||
|
||||
```sh
|
||||
export MINIO_POLICY_PLUGIN_URL=http://localhost:8181/v1/data/httpapi/authz/allow
|
||||
export MINIO_CI_CD=1
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
minio server /mnt/data
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
silo server /mnt/data
|
||||
```
|
||||
|
||||
### 5. Test with a regular IAM user
|
||||
|
||||
Ensure that `mc` is installed and the configured with the above server with the alias `myminio`.
|
||||
Ensure that `mc` is installed and the configured with the above server with the alias `mysilo`.
|
||||
|
||||
```sh
|
||||
# 1. Create a bucket and a user, and upload a file. These operations will succeed.
|
||||
mc mb myminio/test
|
||||
mc admin user add myminio foo foobar123
|
||||
mc cp /etc/issue myminio/test/
|
||||
mc mb mysilo/test
|
||||
mc admin user add mysilo foo foobar123
|
||||
mc cp /etc/issue mysilo/test/
|
||||
|
||||
# 2. Now access the server as user `foo`. These operations will also succeed.
|
||||
export MC_HOST_foo=http://foo:foobar123@localhost:9000
|
||||
@@ -79,5 +79,5 @@ mc ls foo/test
|
||||
mc cat foo/test/issue
|
||||
|
||||
# 3. Attempt to upload an object as user `foo` - this will fail with a permissions error.
|
||||
mc cp /etc/issue myminio/test/issue2
|
||||
mc cp /etc/issue mysilo/test/issue2
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user