mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +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
+17
-17
@@ -1,8 +1,8 @@
|
||||
# MinIO STS Quickstart Guide [](https://slack.min.io)
|
||||
# Silo STS Quickstart Guide
|
||||
|
||||
The MinIO Security Token Service (STS) is an endpoint service that enables clients to request temporary credentials for MinIO resources. Temporary credentials work almost identically to default admin credentials, with some differences:
|
||||
The Silo Security Token Service (STS) is an endpoint service that enables clients to request temporary credentials for Silo resources. Temporary credentials work almost identically to default admin credentials, with some differences:
|
||||
|
||||
- Temporary credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, MinIO no longer recognizes them or allows any kind of access from API requests made with them.
|
||||
- Temporary credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, Silo no longer recognizes them or allows any kind of access from API requests made with them.
|
||||
- Temporary credentials do not need to be stored with the application but are generated dynamically and provided to the application when requested. When (or even before) the temporary credentials expire, the application can request new credentials.
|
||||
|
||||
Following are advantages for using temporary credentials:
|
||||
@@ -17,7 +17,7 @@ Following are advantages for using temporary credentials:
|
||||
| :---------------------- | ------------------------------------------ |
|
||||
| [**WebIdentity**](https://github.com/pgsty/minio/blob/master/docs/sts/web-identity.md) | Let users request temporary credentials using any OpenID(OIDC) compatible web identity providers such as KeyCloak, Dex, Facebook, Google etc. |
|
||||
| [**AD/LDAP**](https://github.com/pgsty/minio/blob/master/docs/sts/ldap.md) | Let AD/LDAP users request temporary credentials using AD/LDAP username and password. |
|
||||
| [**AssumeRole**](https://github.com/pgsty/minio/blob/master/docs/sts/assume-role.md) | Let MinIO users request temporary credentials using user access and secret keys. |
|
||||
| [**AssumeRole**](https://github.com/pgsty/minio/blob/master/docs/sts/assume-role.md) | Let Silo users request temporary credentials using user access and secret keys. |
|
||||
|
||||
### Understanding JWT Claims
|
||||
|
||||
@@ -44,33 +44,33 @@ In this document we will explain in detail on how to configure all the prerequis
|
||||
- [Configuring keycloak](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md) or [Configuring Casdoor](https://github.com/pgsty/minio/blob/master/docs/sts/casdoor.md)
|
||||
- [Configuring etcd](https://github.com/pgsty/minio/blob/master/docs/sts/etcd.md)
|
||||
|
||||
### Setup MinIO with Identity Provider
|
||||
### Setup Silo with Identity Provider
|
||||
|
||||
Make sure we have followed the previous step and configured each software independently, once done we can now proceed to use MinIO STS API and MinIO server to use these credentials to perform object API operations.
|
||||
Make sure we have followed the previous step and configured each software independently, once done we can now proceed to use Silo STS API and Silo server to use these credentials to perform object API operations.
|
||||
|
||||
#### KeyCloak
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
export MINIO_IDENTITY_OPENID_CONFIG_URL=http://localhost:8080/auth/realms/demo/.well-known/openid-configuration
|
||||
export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
|
||||
minio server /mnt/data
|
||||
silo server /mnt/data
|
||||
```
|
||||
|
||||
#### Casdoor
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
export MINIO_IDENTITY_OPENID_CONFIG_URL=http://CASDOOR_ENDPOINT/.well-known/openid-configuration
|
||||
export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
|
||||
minio server /mnt/data
|
||||
silo server /mnt/data
|
||||
```
|
||||
|
||||
### Using WebIdentiy API
|
||||
|
||||
On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the MinIO server using the STS API call `AssumeRoleWithWebIdentity`.
|
||||
On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the Silo server using the STS API call `AssumeRoleWithWebIdentity`.
|
||||
|
||||
```
|
||||
$ go run docs/sts/web-identity.go -cid account -csec 072e7f00-4289-469c-9ab2-bbe843c7f5a8 -config-ep "http://localhost:8080/auth/realms/demo/.well-known/openid-configuration" -port 8888
|
||||
@@ -95,16 +95,16 @@ This will open the login page of keycloak, upon successful login, STS credential
|
||||
|
||||
> NOTE: You can use the `-cscopes` parameter to restrict the requested scopes, for example to `"openid,policy_role_attribute"`, being `policy_role_attribute` a client_scope / client_mapper that maps a role attribute called policy to a `policy` claim returned by Keycloak.
|
||||
|
||||
These credentials can now be used to perform MinIO API operations.
|
||||
These credentials can now be used to perform Silo API operations.
|
||||
|
||||
### Using MinIO Console
|
||||
### Using Silo Console
|
||||
|
||||
- Open MinIO URL on the browser, lets say <http://localhost:9000/>
|
||||
- Open Silo URL on the browser, lets say <http://localhost:9000/>
|
||||
- Click on `Login with SSO`
|
||||
- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to MinIO page and logged in automatically,
|
||||
- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to Silo page and logged in automatically,
|
||||
the user should see now the buckets and objects they have access to.
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
@@ -36,7 +36,7 @@ import (
|
||||
)
|
||||
|
||||
var (
|
||||
// Minio endpoint (for STS API)
|
||||
// Silo endpoint (for STS API)
|
||||
stsEndpoint string
|
||||
|
||||
// User account credentials
|
||||
@@ -58,8 +58,8 @@ var (
|
||||
|
||||
func init() {
|
||||
flag.StringVar(&stsEndpoint, "sts-ep", "http://localhost:9000", "STS endpoint")
|
||||
flag.StringVar(&minioUsername, "u", "", "MinIO Username")
|
||||
flag.StringVar(&minioPassword, "p", "", "MinIO Password")
|
||||
flag.StringVar(&minioUsername, "u", "", "Silo username")
|
||||
flag.StringVar(&minioPassword, "p", "", "Silo password")
|
||||
flag.BoolVar(&displayCreds, "d", false, "Only show generated credentials")
|
||||
flag.DurationVar(&expiryDuration, "e", 0, "Request a duration of validity for the generated credential")
|
||||
flag.StringVar(&bucketToList, "b", "", "Bucket to list (defaults to username)")
|
||||
@@ -132,7 +132,7 @@ func main() {
|
||||
}
|
||||
|
||||
// API requests are secure (HTTPS) if secure=true and insecure (HTTP) otherwise.
|
||||
// New returns an MinIO Admin client object.
|
||||
// New returns a compatible Admin API client object.
|
||||
madmClnt, err := madmin.NewWithOptions(stsEndpointURL.Host, mopts)
|
||||
if err != nil {
|
||||
log.Fatalln(err)
|
||||
@@ -143,13 +143,13 @@ func main() {
|
||||
log.Fatalln(err)
|
||||
}
|
||||
|
||||
// Use generated credentials to authenticate with MinIO server
|
||||
// Use generated credentials to authenticate with Silo server
|
||||
minioClient, err := minio.New(stsEndpointURL.Host, opts)
|
||||
if err != nil {
|
||||
log.Fatalf("Error initializing client: %v", err)
|
||||
}
|
||||
|
||||
// Use minIO Client object normally like the regular client.
|
||||
// Use the minio-go Client object like a regular client.
|
||||
if bucketToList == "" {
|
||||
bucketToList = minioUsername
|
||||
}
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
# AssumeRole [](https://slack.min.io)
|
||||
# AssumeRole
|
||||
|
||||
## Introduction
|
||||
|
||||
Returns a set of temporary security credentials that you can use to access MinIO resources. AssumeRole requires authorization credentials for an existing user on MinIO. The advantages of this API are
|
||||
Returns a set of temporary security credentials that you can use to access Silo resources. AssumeRole requires authorization credentials for an existing user on Silo. The advantages of this API are
|
||||
|
||||
- To be able to reliably use S3 multipart APIs feature of the SDKs without re-inventing the wheel of pre-signing the each URL in multipart API. This is very tedious to implement with all the scenarios of fault tolerance that's already implemented by the client SDK. The general client SDKs don't support multipart with presigned URLs.
|
||||
- To be able to easily get the temporary credentials to upload to a prefix. Make it possible for a client to upload a whole folder using the session. The server side applications need not create a presigned URL and serve to the client for each file. Since, the client would have the session it can do it by itself.
|
||||
|
||||
The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to MinIO API operations. The policy applied to these temporary credentials is inherited from the MinIO user credentials. By default, the temporary security credentials created by AssumeRole last for one hour. However, use the optional DurationSeconds parameter to specify the duration of the credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
|
||||
The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to Silo API operations. The policy applied to these temporary credentials is inherited from the Silo user credentials. By default, the temporary security credentials created by AssumeRole last for one hour. However, use the optional DurationSeconds parameter to specify the duration of the credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
|
||||
|
||||
## API Request Parameters
|
||||
|
||||
@@ -85,8 +85,8 @@ http://minio:9000/?Action=AssumeRole&DurationSeconds=3600&Version=2011-06-15&Pol
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
minio server ~/test
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
silo server ~/test
|
||||
```
|
||||
|
||||
Create new users following the multi-user guide [here](https://silo.pgsty.com/administration/identity-access-management/)
|
||||
@@ -102,7 +102,7 @@ aws_access_key_id = foobar
|
||||
aws_secret_access_key = foo12345
|
||||
```
|
||||
|
||||
> NOTE: In the following commands `--role-arn` and `--role-session-name` are not meaningful for MinIO and can be set to any value satisfying the command line requirements.
|
||||
> NOTE: In the following commands `--role-arn` and `--role-session-name` are not meaningful for Silo and can be set to any value satisfying the command line requirements.
|
||||
|
||||
```
|
||||
$ aws --profile foobar --endpoint-url http://localhost:9000 sts assume-role --policy '{"Version":"2012-10-17","Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"arn:aws:s3:::*"}]}' --role-arn arn:xxx:xxx:xxx:xxxx --role-session-name anything
|
||||
@@ -134,5 +134,5 @@ SessionToken: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJhY2Nlc3NLZXkiOiIyN1lEUllFT
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
+20
-20
@@ -1,6 +1,6 @@
|
||||
# Casdoor Quickstart Guide [](https://slack.min.io)
|
||||
# Casdoor Quickstart Guide
|
||||
|
||||
Casdoor is a UI-first centralized authentication / Single-Sign-On (SSO) platform supporting OAuth 2.0, OIDC and SAML, integrated with Casbin RBAC and ABAC permission management. This document covers configuring Casdoor identity provider support with MinIO.
|
||||
Casdoor is a UI-first centralized authentication / Single-Sign-On (SSO) platform supporting OAuth 2.0, OIDC and SAML, integrated with Casbin RBAC and ABAC permission management. This document covers configuring Casdoor identity provider support with Silo.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -18,23 +18,23 @@ For a quick installation, docker-compose reference configs are also available on
|
||||
|
||||
- Go to Users
|
||||
- Edit the user
|
||||
- Add your MinIO policy (ex: `readwrite`) in `Tag`
|
||||
- Add your Silo policy (ex: `readwrite`) in `Tag`
|
||||
- Save
|
||||
|
||||
- Open your favorite browser and visit: **http://`CASDOOR_ENDPOINT`/.well-known/openid-configuration**, you will see the OIDC configure of Casdoor.
|
||||
|
||||
### Configure MinIO
|
||||
### Configure Silo
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
minio server /mnt/export
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
silo server /mnt/export
|
||||
```
|
||||
|
||||
Here are all the available options to configure OpenID connect
|
||||
|
||||
```
|
||||
mc admin config set myminio/ identity_openid
|
||||
mc admin config set mysilo/ identity_openid
|
||||
|
||||
KEY:
|
||||
identity_openid enable OpenID SSO support
|
||||
@@ -51,7 +51,7 @@ comment (sentence) optionally add a comment to this setting
|
||||
and ENV based options
|
||||
|
||||
```
|
||||
mc admin config set myminio/ identity_openid --env
|
||||
mc admin config set mysilo/ identity_openid --env
|
||||
|
||||
KEY:
|
||||
identity_openid enable OpenID SSO support
|
||||
@@ -65,23 +65,23 @@ MINIO_IDENTITY_OPENID_SCOPES (csv) Comma separated list of OpenID s
|
||||
MINIO_IDENTITY_OPENID_COMMENT (sentence) optionally add a comment to this setting
|
||||
```
|
||||
|
||||
Set `identity_openid` config with `config_url`, `client_id` and restart MinIO
|
||||
Set `identity_openid` config with `config_url`, `client_id` and restart Silo
|
||||
|
||||
```
|
||||
~ mc admin config set myminio identity_openid config_url="http://CASDOOR_ENDPOINT/.well-known/openid-configuration" client_id=<client id> client_secret=<client secret> claim_name="tag"
|
||||
~ mc admin config set mysilo identity_openid config_url="http://CASDOOR_ENDPOINT/.well-known/openid-configuration" client_id=<client id> client_secret=<client secret> claim_name="tag"
|
||||
```
|
||||
|
||||
> NOTE: As MinIO needs to use a claim attribute in JWT for its policy, you should configure it in casdoor as well. Currently, casdoor uses `tag` as a workaround for configuring MinIO's policy.
|
||||
> NOTE: As Silo needs to use a claim attribute in JWT for its policy, you should configure it in casdoor as well. Currently, casdoor uses `tag` as a workaround for configuring Silo's policy.
|
||||
|
||||
Once successfully set restart the MinIO instance.
|
||||
Once successfully set restart the Silo instance.
|
||||
|
||||
```
|
||||
mc admin service restart myminio
|
||||
mc admin service restart mysilo
|
||||
```
|
||||
|
||||
### Using WebIdentiy API
|
||||
|
||||
On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the MinIO server using the STS API call `AssumeRoleWithWebIdentity`.
|
||||
On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the Silo server using the STS API call `AssumeRoleWithWebIdentity`.
|
||||
|
||||
```
|
||||
$ go run docs/sts/web-identity.go -cid account -csec 072e7f00-4289-469c-9ab2-bbe843c7f5a8 -config-ep "http://CASDOOR_ENDPOINT/.well-known/openid-configuration" -port 8888
|
||||
@@ -102,15 +102,15 @@ This will open the login page of Casdoor, upon successful login, STS credentials
|
||||
}
|
||||
```
|
||||
|
||||
### Using MinIO Console
|
||||
### Using Silo Console
|
||||
|
||||
- Open MinIO URL on the browser, lets say <http://localhost:9000/>
|
||||
- Open Silo URL on the browser, lets say <http://localhost:9000/>
|
||||
- Click on `Login with SSO`
|
||||
- User will be redirected to the Casdoor user login page, upon successful login the user will be redirected to MinIO page and logged in automatically,
|
||||
- User will be redirected to the Casdoor user login page, upon successful login the user will be redirected to Silo page and logged in automatically,
|
||||
the user should see now the buckets and objects they have access to.
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [Casdoor MinIO Integration](https://casdoor.org/docs/integration/minio)
|
||||
- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Casdoor Silo Integration](https://casdoor.org/docs/integration/minio)
|
||||
- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
@@ -102,7 +102,7 @@ func main() {
|
||||
log.Fatal(err)
|
||||
}
|
||||
|
||||
// Uncomment this to use MinIO API operations by initializing minio
|
||||
// Uncomment this to use Silo API operations with the compatible minio-go client.
|
||||
// client with obtained credentials.
|
||||
|
||||
opts := &minio.Options{
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# AssumeRoleWithClientGrants [](https://slack.min.io)
|
||||
# AssumeRoleWithClientGrants
|
||||
|
||||
## Introduction
|
||||
|
||||
Returns a set of temporary security credentials for applications/clients who have been authenticated through client credential grants provided by identity provider. Example providers include KeyCloak, Okta etc.
|
||||
|
||||
Calling AssumeRoleWithClientGrants does not require the use of MinIO default credentials. Therefore, client application can be distributed that requests temporary security credentials without including MinIO default credentials. Instead, the identity of the caller is validated by using a JWT access token from the identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to MinIO API operations.
|
||||
Calling AssumeRoleWithClientGrants does not require the use of Silo default credentials. Therefore, client application can be distributed that requests temporary security credentials without including Silo default credentials. Instead, the identity of the caller is validated by using a JWT access token from the identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to Silo API operations.
|
||||
|
||||
**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the JWT access token with the provider JWKS endpoint advertised by the configured OpenID discovery document. In practice, MinIO currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed access tokens for this flow, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
|
||||
**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the JWT access token with the provider JWKS endpoint advertised by the configured OpenID discovery document. In practice, Silo currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed access tokens for this flow, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
|
||||
|
||||
By default, the temporary security credentials created by AssumeRoleWithClientGrants last for one hour. However, use the optional DurationSeconds parameter to specify the duration of the credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
|
||||
|
||||
@@ -62,7 +62,7 @@ XML error response for this API is similar to [AWS STS AssumeRoleWithWebIdentity
|
||||
## Sample `POST` Request
|
||||
|
||||
```
|
||||
http://minio.cluster:9000?Action=AssumeRoleWithClientGrants&DurationSeconds=3600&Token=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
|
||||
http://silo.cluster:9000?Action=AssumeRoleWithClientGrants&DurationSeconds=3600&Token=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
|
||||
```
|
||||
|
||||
## Sample Response
|
||||
@@ -90,10 +90,10 @@ http://minio.cluster:9000?Action=AssumeRoleWithClientGrants&DurationSeconds=3600
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
export MINIO_IDENTITY_OPENID_CONFIG_URL=http://localhost:8080/auth/realms/demo/.well-known/openid-configuration
|
||||
export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
|
||||
minio server /mnt/export
|
||||
silo server /mnt/export
|
||||
```
|
||||
|
||||
Testing with an example
|
||||
@@ -113,5 +113,5 @@ $ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBt
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
@@ -33,7 +33,7 @@ import (
|
||||
)
|
||||
|
||||
var (
|
||||
// LDAP integrated Minio endpoint
|
||||
// Identity-provider-integrated Silo endpoint
|
||||
stsEndpoint string
|
||||
|
||||
// token to use with AssumeRoleWithCustomToken
|
||||
@@ -95,7 +95,7 @@ func main() {
|
||||
return
|
||||
}
|
||||
|
||||
// Use generated credentials to authenticate with MinIO server
|
||||
// Use generated credentials to authenticate with Silo server
|
||||
stsEndpointURL, err := url.Parse(stsEndpoint)
|
||||
if err != nil {
|
||||
log.Fatalf("Error parsing sts endpoint: %v", err)
|
||||
@@ -109,7 +109,7 @@ func main() {
|
||||
log.Fatalf("Error initializing client: ", err)
|
||||
}
|
||||
|
||||
// Use minIO Client object normally like the regular client.
|
||||
// Use the minio-go Client object like a regular client.
|
||||
fmt.Printf("Calling list objects on bucket named `%s` with temp creds:\n===\n", bucketToList)
|
||||
objCh := minioClient.ListObjects(context.Background(), bucketToList, minio.ListObjectsOptions{})
|
||||
for obj := range objCh {
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# AssumeRoleWithCustomToken [](https://slack.min.io)
|
||||
# AssumeRoleWithCustomToken
|
||||
|
||||
## Introduction
|
||||
|
||||
To integrate with custom authentication methods using the [Identity Management Plugin](../iam/identity-management-plugin.md)), MinIO provides an STS API extension called `AssumeRoleWithCustomToken`.
|
||||
To integrate with custom authentication methods using the [Identity Management Plugin](../iam/identity-management-plugin.md)), Silo provides an STS API extension called `AssumeRoleWithCustomToken`.
|
||||
|
||||
After configuring the plugin, use the generated Role ARN with `AssumeRoleWithCustomToken` to get temporary credentials to access object storage.
|
||||
|
||||
## API Request
|
||||
|
||||
To make an STS API request with this method, send a POST request to the MinIO endpoint with following query parameters:
|
||||
To make an STS API request with this method, send a POST request to the Silo endpoint with following query parameters:
|
||||
|
||||
| Parameter | Type | Required | |
|
||||
|-----------------|---------|----------|----------------------------------------------------------------------|
|
||||
|
||||
+8
-8
@@ -1,4 +1,4 @@
|
||||
# Dex Quickstart Guide [](https://slack.min.io)
|
||||
# Dex Quickstart Guide
|
||||
|
||||
Dex is an identity service that uses OpenID Connect to drive authentication for apps. Dex acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.
|
||||
|
||||
@@ -22,12 +22,12 @@ time="2020-07-12T20:45:50Z" level=info msg="config id tokens valid for: 3h0m0s"
|
||||
time="2020-07-12T20:45:50Z" level=info msg="listening (http) on 0.0.0.0:5556"
|
||||
```
|
||||
|
||||
### Configure MinIO server with Dex
|
||||
### Configure Silo server with Dex
|
||||
|
||||
```
|
||||
~ export MINIO_IDENTITY_OPENID_CLAIM_NAME=name
|
||||
~ export MINIO_IDENTITY_OPENID_CONFIG_URL=http://127.0.0.1:5556/dex/.well-known/openid-configuration
|
||||
~ minio server ~/test
|
||||
~ silo server ~/test
|
||||
```
|
||||
|
||||
### Run the `web-identity.go`
|
||||
@@ -69,7 +69,7 @@ You will be redirected to dex login screen - click "Login with email", enter use
|
||||
|
||||
and then click "Grant access"
|
||||
|
||||
On the browser now you shall see the list of buckets output, along with your temporary credentials obtained from MinIO.
|
||||
On the browser now you shall see the list of buckets output, along with your temporary credentials obtained from Silo.
|
||||
|
||||
```
|
||||
{
|
||||
@@ -87,7 +87,7 @@ On the browser now you shall see the list of buckets output, along with your tem
|
||||
}
|
||||
```
|
||||
|
||||
Now you have successfully configured Dex IdP with MinIO.
|
||||
Now you have successfully configured Dex IdP with Silo.
|
||||
|
||||
> NOTE: Dex supports groups with external connectors so you can use `groups` as policy claim instead of `name`.
|
||||
|
||||
@@ -95,9 +95,9 @@ Now you have successfully configured Dex IdP with MinIO.
|
||||
export MINIO_IDENTITY_OPENID_CLAIM_NAME=groups
|
||||
```
|
||||
|
||||
and add relevant policies on MinIO using `mc admin policy create myminio/ <group_name> group-access.json`
|
||||
and add relevant policies on Silo using `mc admin policy create mysilo/ <group_name> group-access.json`
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
+9
-9
@@ -1,4 +1,4 @@
|
||||
# etcd V3 Quickstart Guide [](https://slack.min.io)
|
||||
# etcd V3 Quickstart Guide
|
||||
|
||||
etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines.
|
||||
|
||||
@@ -35,22 +35,22 @@ rm -rf /tmp/etcd-data.tmp && mkdir -p /tmp/etcd-data.tmp && \
|
||||
|
||||
You may also setup etcd with TLS following this documentation [here](https://coreos.com/etcd/docs/latest/op-guide/security.html)
|
||||
|
||||
### 3. Setup MinIO with etcd
|
||||
### 3. Setup Silo with etcd
|
||||
|
||||
MinIO server expects environment variable for etcd as `MINIO_ETCD_ENDPOINTS`, this environment variable takes many comma separated entries.
|
||||
Silo server expects environment variable for etcd as `MINIO_ETCD_ENDPOINTS`, this environment variable takes many comma separated entries.
|
||||
|
||||
```
|
||||
export MINIO_ETCD_ENDPOINTS=http://localhost:2379
|
||||
minio server /data
|
||||
silo server /data
|
||||
```
|
||||
|
||||
NOTE: If `etcd` is configured with `Client-to-server authentication with HTTPS client certificates` then you need to use additional envs such as `MINIO_ETCD_CLIENT_CERT` pointing to path to `etcd-client.crt` and `MINIO_ETCD_CLIENT_CERT_KEY` path to `etcd-client.key` .
|
||||
|
||||
### 4. Test with MinIO STS API
|
||||
### 4. Test with Silo STS API
|
||||
|
||||
Once etcd is configured, **any STS configuration** will work including Client Grants, Web Identity or AD/LDAP.
|
||||
|
||||
For example, you can configure STS with Client Grants (KeyCloak) using the guides at [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) and [KeyCloak Configuration Guide](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md). Once this is done, STS credentials can be generated:
|
||||
For example, you can configure STS with Client Grants (KeyCloak) using the guides at [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) and [KeyCloak Configuration Guide](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md). Once this is done, STS credentials can be generated:
|
||||
|
||||
```
|
||||
go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga
|
||||
@@ -64,9 +64,9 @@ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrO
|
||||
}
|
||||
```
|
||||
|
||||
These credentials can now be used to perform MinIO API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
|
||||
These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
+19
-19
@@ -1,6 +1,6 @@
|
||||
# Keycloak Quickstart Guide [](https://slack.min.io)
|
||||
# Keycloak Quickstart Guide
|
||||
|
||||
Keycloak is an open source Identity and Access Management solution aimed at modern applications and services, this document covers configuring Keycloak identity provider support with MinIO.
|
||||
Keycloak is an open source Identity and Access Management solution aimed at modern applications and services, this document covers configuring Keycloak identity provider support with Silo.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -16,11 +16,11 @@ For a quick installation, docker-compose reference configs are also available on
|
||||
- Save
|
||||
- Click on credentials tab
|
||||
- Copy the `Secret` to clipboard.
|
||||
- This value is needed for `MINIO_IDENTITY_OPENID_CLIENT_SECRET` for MinIO.
|
||||
- This value is needed for `MINIO_IDENTITY_OPENID_CLIENT_SECRET` for Silo.
|
||||
|
||||
- Go to Users
|
||||
- Click on the user
|
||||
- Attribute, add a new attribute `Key` is `policy`, `Value` is name of the `policy` on MinIO (ex: `readwrite`)
|
||||
- Attribute, add a new attribute `Key` is `policy`, `Value` is name of the `policy` on Silo (ex: `readwrite`)
|
||||
- Add and Save
|
||||
|
||||
- Go to Clients
|
||||
@@ -78,18 +78,18 @@ curl \
|
||||
"http://localhost:8080/auth/admin/realms/{realm}/users/{userid}"
|
||||
```
|
||||
|
||||
### Configure MinIO
|
||||
### Configure Silo
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
minio server /mnt/export
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
silo server /mnt/export
|
||||
```
|
||||
|
||||
Here are all the available options to configure OpenID connect
|
||||
|
||||
```
|
||||
mc admin config set myminio/ identity_openid
|
||||
mc admin config set mysilo/ identity_openid
|
||||
|
||||
KEY:
|
||||
identity_openid enable OpenID SSO support
|
||||
@@ -106,7 +106,7 @@ comment (sentence) optionally add a comment to this setting
|
||||
and ENV based options
|
||||
|
||||
```
|
||||
mc admin config set myminio/ identity_openid --env
|
||||
mc admin config set mysilo/ identity_openid --env
|
||||
|
||||
KEY:
|
||||
identity_openid enable OpenID SSO support
|
||||
@@ -120,18 +120,18 @@ MINIO_IDENTITY_OPENID_SCOPES (csv) Comma separated list of OpenID s
|
||||
MINIO_IDENTITY_OPENID_COMMENT (sentence) optionally add a comment to this setting
|
||||
```
|
||||
|
||||
Set `identity_openid` config with `config_url`, `client_id` and restart MinIO
|
||||
Set `identity_openid` config with `config_url`, `client_id` and restart Silo
|
||||
|
||||
```
|
||||
~ mc admin config set myminio identity_openid config_url="http://localhost:8080/auth/realms/{your-realm-name}/.well-known/openid-configuration" client_id="account"
|
||||
~ mc admin config set mysilo identity_openid config_url="http://localhost:8080/auth/realms/{your-realm-name}/.well-known/openid-configuration" client_id="account"
|
||||
```
|
||||
|
||||
> NOTE: You can configure the `scopes` parameter to restrict the OpenID scopes requested by minio to the IdP, for example, `"openid,policy_role_attribute"`, being `policy_role_attribute` a client_scope / client_mapper that maps a role attribute called policy to a `policy` claim returned by Keycloak
|
||||
|
||||
Once successfully set restart the MinIO instance.
|
||||
Once successfully set restart the Silo instance.
|
||||
|
||||
```
|
||||
mc admin service restart myminio
|
||||
mc admin service restart mysilo
|
||||
```
|
||||
|
||||
### Using WebIdentiy API
|
||||
@@ -161,16 +161,16 @@ This will open the login page of keycloak, upon successful login, STS credential
|
||||
|
||||
> NOTE: You can use the `-cscopes` parameter to restrict the requested scopes, for example to `"openid,policy_role_attribute"`, being `policy_role_attribute` a client_scope / client_mapper that maps a role attribute called policy to a `policy` claim returned by Keycloak.
|
||||
|
||||
These credentials can now be used to perform MinIO API operations.
|
||||
These credentials can now be used to perform Silo API operations.
|
||||
|
||||
### Using MinIO Console
|
||||
### Using Silo Console
|
||||
|
||||
- Open MinIO URL on the browser, lets say <http://localhost:9000/>
|
||||
- Open Silo URL on the browser, lets say <http://localhost:9000/>
|
||||
- Click on `Login with SSO`
|
||||
- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to MinIO page and logged in automatically,
|
||||
- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to Silo page and logged in automatically,
|
||||
the user should see now the buckets and objects they have access to.
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
+3
-3
@@ -35,7 +35,7 @@ import (
|
||||
)
|
||||
|
||||
var (
|
||||
// LDAP integrated Minio endpoint
|
||||
// LDAP-integrated Silo endpoint
|
||||
stsEndpoint string
|
||||
|
||||
// LDAP credentials
|
||||
@@ -121,13 +121,13 @@ func main() {
|
||||
return
|
||||
}
|
||||
|
||||
// Use generated credentials to authenticate with MinIO server
|
||||
// Use generated credentials to authenticate with Silo server
|
||||
minioClient, err := minio.New(stsEndpointURL.Host, opts)
|
||||
if err != nil {
|
||||
log.Fatalf("Error initializing client: %v", err)
|
||||
}
|
||||
|
||||
// Use minIO Client object normally like the regular client.
|
||||
// Use the minio-go Client object like a regular client.
|
||||
if bucketToList == "" {
|
||||
bucketToList = ldapUsername
|
||||
}
|
||||
|
||||
+38
-38
@@ -1,35 +1,35 @@
|
||||
# AssumeRoleWithLDAPIdentity [](https://slack.min.io)
|
||||
# AssumeRoleWithLDAPIdentity
|
||||
|
||||
## Introduction
|
||||
|
||||
MinIO provides a custom STS API that allows integration with LDAP based corporate environments including Microsoft Active Directory. The MinIO server uses a separate LDAP service account to lookup user information. The login flow for a user is as follows:
|
||||
Silo provides a custom STS API that allows integration with LDAP based corporate environments including Microsoft Active Directory. The Silo server uses a separate LDAP service account to lookup user information. The login flow for a user is as follows:
|
||||
|
||||
- User provides their AD/LDAP username and password to the STS API.
|
||||
- MinIO looks up the user's information (specifically the user's Distinguished Name) in the LDAP server.
|
||||
- On finding the user's info, MinIO verifies the login credentials with the AD/LDAP server.
|
||||
- MinIO optionally queries the AD/LDAP server for a list of groups that the user is a member of.
|
||||
- MinIO then checks if there are any policies [explicitly associated](#managing-usergroup-access-policy) with the user or their groups.
|
||||
- On finding at least one associated policy, MinIO generates temporary credentials for the user storing the list of groups in a cryptographically secure session token. The temporary access key, secret key and session token are returned to the user.
|
||||
- The user can now use these credentials to make requests to the MinIO server.
|
||||
- Silo looks up the user's information (specifically the user's Distinguished Name) in the LDAP server.
|
||||
- On finding the user's info, Silo verifies the login credentials with the AD/LDAP server.
|
||||
- Silo optionally queries the AD/LDAP server for a list of groups that the user is a member of.
|
||||
- Silo then checks if there are any policies [explicitly associated](#managing-usergroup-access-policy) with the user or their groups.
|
||||
- On finding at least one associated policy, Silo generates temporary credentials for the user storing the list of groups in a cryptographically secure session token. The temporary access key, secret key and session token are returned to the user.
|
||||
- The user can now use these credentials to make requests to the Silo server.
|
||||
|
||||
The administrator will associate IAM access policies with each group and if required with the user too. The MinIO server then evaluates applicable policies on a user (these are the policies associated with the groups along with the policy on the user if any) to check if the request should be allowed or denied.
|
||||
The administrator will associate IAM access policies with each group and if required with the user too. The Silo server then evaluates applicable policies on a user (these are the policies associated with the groups along with the policy on the user if any) to check if the request should be allowed or denied.
|
||||
|
||||
To ensure that changes in the LDAP directory are reflected in object storage access changes, MinIO performs an **Automatic LDAP sync**. MinIO periodically queries the LDAP service to:
|
||||
To ensure that changes in the LDAP directory are reflected in object storage access changes, Silo performs an **Automatic LDAP sync**. Silo periodically queries the LDAP service to:
|
||||
|
||||
- find accounts (user DNs) that have been removed; any active STS credentials or MinIO service accounts belonging to these users are purged.
|
||||
- find accounts (user DNs) that have been removed; any active STS credentials or Silo service accounts belonging to these users are purged.
|
||||
|
||||
- find accounts whose group memberships have changed; access policies available to a credential are updated to reflect the change, i.e. they will lose any privileges associated with a group they are removed from, and gain any privileges associated with a group they are added to.
|
||||
|
||||
**Please note that when AD/LDAP is configured, MinIO will not support long term users defined internally.** Only AD/LDAP users (and the root user) are allowed. In addition to this, the server will not support operations on users or groups using `mc admin user` or `mc admin group` commands except `mc admin user info` and `mc admin group info` to list set policies for users and groups. This is because users and groups are defined externally in AD/LDAP.
|
||||
**Please note that when AD/LDAP is configured, Silo will not support long term users defined internally.** Only AD/LDAP users (and the root user) are allowed. In addition to this, the server will not support operations on users or groups using `mc admin user` or `mc admin group` commands except `mc admin user info` and `mc admin group info` to list set policies for users and groups. This is because users and groups are defined externally in AD/LDAP.
|
||||
|
||||
## Configuring AD/LDAP on MinIO
|
||||
## Configuring AD/LDAP on Silo
|
||||
|
||||
LDAP STS configuration can be performed via MinIO's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we refer to environment variables here.
|
||||
LDAP STS configuration can be performed via Silo's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we refer to environment variables here.
|
||||
|
||||
LDAP is configured via the following environment variables:
|
||||
|
||||
```
|
||||
$ mc admin config set myminio identity_ldap --env
|
||||
$ mc admin config set mysilo identity_ldap --env
|
||||
KEY:
|
||||
identity_ldap enable LDAP SSO support
|
||||
|
||||
@@ -64,21 +64,21 @@ MINIO_IDENTITY_LDAP_SERVER_STARTTLS (on|off) use StartTLS connection
|
||||
|
||||
The server address variable is _required_. TLS is assumed to be on by default. The port in the server address is optional and defaults to 636 if not provided.
|
||||
|
||||
**MinIO sends LDAP credentials to the LDAP server for validation. So we _strongly recommend_ to use MinIO with AD/LDAP server over TLS or StartTLS _only_. Using plain-text connection between MinIO and LDAP server means _credentials can be compromised_ by anyone listening to network traffic.**
|
||||
**Silo sends LDAP credentials to the LDAP server for validation. So we _strongly recommend_ to use Silo with AD/LDAP server over TLS or StartTLS _only_. Using plain-text connection between Silo and LDAP server means _credentials can be compromised_ by anyone listening to network traffic.**
|
||||
|
||||
If a self-signed certificate is being used, the certificate can be added to MinIO's certificates directory, so it can be trusted by the server.
|
||||
If a self-signed certificate is being used, the certificate can be added to Silo's certificates directory, so it can be trusted by the server.
|
||||
|
||||
#### DNS SRV Records
|
||||
|
||||
Many Active Directory and other LDAP services are setup with [DNS SRV Records](https://ldap.com/dns-srv-records-for-ldap/) for high-availability of the directory service. To use this to find LDAP servers to connect to, an LDAP client makes a DNS SRV record request to the DNS service on a domain that looks like `_service._proto.example.com`. For LDAP the `proto` value is always `tcp`, and `service` is usually `ldap` or `ldaps`.
|
||||
|
||||
To enable MinIO to use the SRV records, specify the `srv_record_name` config parameter (or equivalently the `MINIO_IDENTITY_LDAP_SRV_RECORD_NAME` environment variable). This parameter can be set to `ldap` or `ldaps` and MinIO will substitute it into the `service` value. For example, when `server_addr=myldapserver.com` and `srv_record_name=ldap`, MinIO will lookup the SRV record for `_ldap._tcp.myldapserver.com` and pick an appropriate target for LDAP requests.
|
||||
To enable Silo to use the SRV records, specify the `srv_record_name` config parameter (or equivalently the `MINIO_IDENTITY_LDAP_SRV_RECORD_NAME` environment variable). This parameter can be set to `ldap` or `ldaps` and Silo will substitute it into the `service` value. For example, when `server_addr=myldapserver.com` and `srv_record_name=ldap`, Silo will lookup the SRV record for `_ldap._tcp.myldapserver.com` and pick an appropriate target for LDAP requests.
|
||||
|
||||
If the DNS SRV record is at an entirely different place, say `_ldapsrv._tcpish.myldapserver.com`, then set `srv_record_name` to the special value `on` and set `server_addr=_ldapsrv._tcpish.myldapserver.com`.
|
||||
|
||||
When using this feature, do not specify a port in the `server_addr` as the port is picked up automatically from the SRV record.
|
||||
|
||||
With the default (empty) value for `srv_record_name`, MinIO **will not** perform any SRV record request.
|
||||
With the default (empty) value for `srv_record_name`, Silo **will not** perform any SRV record request.
|
||||
|
||||
The value of `srv_record_name` does not affect any TLS settings - they must be configured with their own parameters.
|
||||
|
||||
@@ -86,7 +86,7 @@ The value of `srv_record_name` does not affect any TLS settings - they must be c
|
||||
|
||||
LDAP STS rate limiting is enforced before each LDAP bind. Requests are tracked by source IP. A login attempt is throttled when that bucket is exhausted. Rate limiting is deliberately not keyed by username: a username-keyed bucket is shared across all sources, so an attacker could drain a known account's bucket with bad-password attempts and lock the legitimate user out. The per-source bucket caps the attempt rate from any single source, while the uniform auth-failure response is what conceals whether a username exists. This combination does not stop attackers who spread requests across many source IPs (botnets, IPv6 address rotation) or the residual bind-timing side channel; those are accepted limitations of an in-memory, per-source control.
|
||||
|
||||
By default, the source IP used for this key is the socket peer address. This is the safe default because MinIO does **not** trust `X-Forwarded-For`, `X-Real-IP`, or `Forwarded` headers for this security-sensitive rate-limit key unless you opt in explicitly.
|
||||
By default, the source IP used for this key is the socket peer address. This is the safe default because Silo does **not** trust `X-Forwarded-For`, `X-Real-IP`, or `Forwarded` headers for this security-sensitive rate-limit key unless you opt in explicitly.
|
||||
|
||||
Each login attempt reserves capacity for the duration of the LDAP bind. Successful logins and LDAP infrastructure failures refund that reservation. Only real authentication failures permanently consume tokens. Concurrent bursts above the burst capacity can still receive `429` responses even if those in-flight requests later succeed.
|
||||
|
||||
@@ -101,11 +101,11 @@ Each login attempt reserves capacity for the duration of the LDAP bind. Successf
|
||||
| Scope | Per-node, in-memory, not cluster-wide |
|
||||
| Configurability | Not currently configurable |
|
||||
|
||||
In a multi-node deployment behind a load balancer, each MinIO node tracks its own buckets. The effective aggregate budget therefore depends on how requests are distributed across nodes.
|
||||
In a multi-node deployment behind a load balancer, each Silo node tracks its own buckets. The effective aggregate budget therefore depends on how requests are distributed across nodes.
|
||||
|
||||
#### Trusted proxies
|
||||
|
||||
If MinIO is deployed behind a trusted reverse proxy, load balancer, or API gateway and you want LDAP STS throttling to bucket by the forwarded client IP instead of the proxy peer address, configure:
|
||||
If Silo is deployed behind a trusted reverse proxy, load balancer, or API gateway and you want LDAP STS throttling to bucket by the forwarded client IP instead of the proxy peer address, configure:
|
||||
|
||||
```
|
||||
MINIO_IDENTITY_LDAP_STS_TRUSTED_PROXIES (list) comma/semicolon/whitespace-separated list of trusted proxy IPs or CIDRs
|
||||
@@ -123,7 +123,7 @@ This allowlist governs LDAP STS rate-limit bucketing only. The client address us
|
||||
|
||||
### Lookup-Bind
|
||||
|
||||
A low-privilege read-only LDAP service account is configured in the MinIO server by providing the account's Distinguished Name (DN) and password. This service account is used to perform directory lookups as needed.
|
||||
A low-privilege read-only LDAP service account is configured in the Silo server by providing the account's Distinguished Name (DN) and password. This service account is used to perform directory lookups as needed.
|
||||
|
||||
```
|
||||
MINIO_IDENTITY_LDAP_LOOKUP_BIND_DN* (string) DN for LDAP read-only service account used to perform DN and group lookups
|
||||
@@ -134,7 +134,7 @@ If you set an empty lookup bind password, the lookup bind will use the unauthent
|
||||
|
||||
### User lookup
|
||||
|
||||
When a user provides their LDAP credentials, MinIO runs a lookup query to find the user's Distinguished Name (DN). The search filter and base DN used in this lookup query are configured via the following variables:
|
||||
When a user provides their LDAP credentials, Silo runs a lookup query to find the user's Distinguished Name (DN). The search filter and base DN used in this lookup query are configured via the following variables:
|
||||
|
||||
```
|
||||
MINIO_IDENTITY_LDAP_USER_DN_SEARCH_BASE_DN* (list) ";" separated list of user search base DNs e.g. "dc=myldapserver,dc=com"
|
||||
@@ -153,7 +153,7 @@ is optional and can be used to specify additional attributes to lookup on the Us
|
||||
|
||||
### Group membership search
|
||||
|
||||
MinIO can be optionally configured to find the groups of a user from AD/LDAP by specifying the following variables:
|
||||
Silo can be optionally configured to find the groups of a user from AD/LDAP by specifying the following variables:
|
||||
|
||||
```
|
||||
MINIO_IDENTITY_LDAP_GROUP_SEARCH_FILTER (string) search filter for groups e.g. "(&(objectclass=groupOfNames)(memberUid=%s))"
|
||||
@@ -196,30 +196,30 @@ In the configuration variables, `%s` is substituted with the _username_ from the
|
||||
|
||||
## Managing User/Group Access Policy
|
||||
|
||||
Access policies may be associated by their name with a group or user directly. Access policies are first defined on the MinIO server using IAM policy JSON syntax. To define a new policy, you can use the [AWS policy generator](https://awspolicygen.s3.amazonaws.com/policygen.html). Copy the policy into a text file `mypolicy.json` and issue the command like so:
|
||||
Access policies may be associated by their name with a group or user directly. Access policies are first defined on the Silo server using IAM policy JSON syntax. To define a new policy, you can use the [AWS policy generator](https://awspolicygen.s3.amazonaws.com/policygen.html). Copy the policy into a text file `mypolicy.json` and issue the command like so:
|
||||
|
||||
```sh
|
||||
mc admin policy create myminio mypolicy mypolicy.json
|
||||
mc admin policy create mysilo mypolicy mypolicy.json
|
||||
```
|
||||
|
||||
To associate the policy with an LDAP user or group, use the full DN of the user or group:
|
||||
|
||||
```sh
|
||||
mc idp ldap policy attach myminio mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
|
||||
mc idp ldap policy attach mysilo mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
|
||||
```
|
||||
|
||||
```sh
|
||||
mc idp ldap policy attach myminio mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
|
||||
mc idp ldap policy attach mysilo mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
|
||||
```
|
||||
|
||||
To remove a policy association, use the similar `detach` command:
|
||||
|
||||
```sh
|
||||
mc idp ldap policy detach myminio mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
|
||||
mc idp ldap policy detach mysilo mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
|
||||
```
|
||||
|
||||
```sh
|
||||
mc idp ldap policy detach myminio mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
|
||||
mc idp ldap policy detach mysilo mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
|
||||
```
|
||||
|
||||
|
||||
@@ -230,12 +230,12 @@ Note that the commands above attempt to validate if the given entity (user or gr
|
||||
Please **do not use** these as they may be removed or their behavior may change.
|
||||
|
||||
```sh
|
||||
mc admin policy attach myminio mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
|
||||
mc admin policy attach mysilo mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
|
||||
```
|
||||
|
||||
|
||||
```sh
|
||||
mc admin policy attach myminio mypolicy --group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
|
||||
mc admin policy attach mysilo mypolicy --group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
|
||||
```
|
||||
|
||||
</details>
|
||||
@@ -312,7 +312,7 @@ Authentication failures caused by unknown users and invalid passwords intentiona
|
||||
## Sample `POST` Request
|
||||
|
||||
```
|
||||
http://minio.cluster:9000?Action=AssumeRoleWithLDAPIdentity&LDAPUsername=foouser&LDAPPassword=foouserpassword&Version=2011-06-15&DurationSeconds=7200
|
||||
http://silo.cluster:9000?Action=AssumeRoleWithLDAPIdentity&LDAPUsername=foouser&LDAPPassword=foouserpassword&Version=2011-06-15&DurationSeconds=7200
|
||||
```
|
||||
|
||||
## Sample Response
|
||||
@@ -342,13 +342,13 @@ With multiple OU hierarchies for users, and multiple group search base DN's.
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
export MINIO_IDENTITY_LDAP_SERVER_ADDR='my.ldap-active-dir-server.com:636'
|
||||
export MINIO_IDENTITY_LDAP_LOOKUP_BIND_DN='cn=admin,dc=min,dc=io'
|
||||
export MINIO_IDENTITY_LDAP_LOOKUP_BIND_PASSWORD=admin
|
||||
export MINIO_IDENTITY_LDAP_GROUP_SEARCH_BASE_DN='dc=minioad,dc=local;dc=somedomain,dc=com'
|
||||
export MINIO_IDENTITY_LDAP_GROUP_SEARCH_FILTER='(&(objectclass=groupOfNames)(member=%d))'
|
||||
minio server ~/test
|
||||
silo server ~/test
|
||||
```
|
||||
|
||||
You can make sure it works appropriately using our [example program](https://raw.githubusercontent.com/pgsty/minio/master/docs/sts/ldap.go):
|
||||
@@ -367,5 +367,5 @@ $ go run ldap.go -u foouser -p foopassword
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
+18
-18
@@ -1,15 +1,15 @@
|
||||
# AssumeRoleWithCertificate [](https://slack.min.io)
|
||||
# AssumeRoleWithCertificate
|
||||
|
||||
## Introduction
|
||||
|
||||
MinIO provides a custom STS API that allows authentication with client X.509 / TLS certificates.
|
||||
Silo provides a custom STS API that allows authentication with client X.509 / TLS certificates.
|
||||
|
||||
A major advantage of certificate-based authentication compared to other STS authentication methods, like OpenID Connect or LDAP/AD, is that client authentication works without any additional/external component that must be constantly available. Therefore, certificate-based authentication may provide better availability / lower operational complexity.
|
||||
|
||||
The MinIO TLS STS API can be configured via MinIO's standard configuration API (i.e. using `mc admin config set/get`). Further, it can be configured via the following environment variables:
|
||||
The Silo TLS STS API can be configured via Silo's standard configuration API (i.e. using `mc admin config set/get`). Further, it can be configured via the following environment variables:
|
||||
|
||||
```
|
||||
mc admin config set myminio identity_tls --env
|
||||
mc admin config set mysilo identity_tls --env
|
||||
KEY:
|
||||
identity_tls enable X.509 TLS certificate SSO support
|
||||
|
||||
@@ -17,7 +17,7 @@ ARGS:
|
||||
MINIO_IDENTITY_TLS_SKIP_VERIFY (on|off) trust client certificates without verification. Defaults to "off" (verify)
|
||||
```
|
||||
|
||||
The MinIO TLS STS API is disabled by default. However, it can be *enabled* by setting environment variable:
|
||||
The Silo TLS STS API is disabled by default. However, it can be *enabled* by setting environment variable:
|
||||
|
||||
```
|
||||
export MINIO_IDENTITY_TLS_ENABLE=on
|
||||
@@ -25,10 +25,10 @@ export MINIO_IDENTITY_TLS_ENABLE=on
|
||||
|
||||
## Example
|
||||
|
||||
MinIO exposes a custom S3 STS API endpoint as `Action=AssumeRoleWithCertificate`. A client has to send an HTTP `POST` request to `https://<host>:<port>?Action=AssumeRoleWithCertificate&Version=2011-06-15`. Since the authentication and authorization happens via X.509 certificates the client has to send the request over **TLS** and has to provide
|
||||
Silo exposes a custom S3 STS API endpoint as `Action=AssumeRoleWithCertificate`. A client has to send an HTTP `POST` request to `https://<host>:<port>?Action=AssumeRoleWithCertificate&Version=2011-06-15`. Since the authentication and authorization happens via X.509 certificates the client has to send the request over **TLS** and has to provide
|
||||
a client certificate.
|
||||
|
||||
The following curl example shows how to authenticate to a MinIO server with client certificate and obtain STS access credentials.
|
||||
The following curl example shows how to authenticate to a Silo server with client certificate and obtain STS access credentials.
|
||||
|
||||
```curl
|
||||
curl -X POST --key private.key --cert public.crt "https://minio:9000?Action=AssumeRoleWithCertificate&Version=2011-06-15&DurationSeconds=3600"
|
||||
@@ -53,11 +53,11 @@ curl -X POST --key private.key --cert public.crt "https://minio:9000?Action=Assu
|
||||
|
||||
## Authentication Flow
|
||||
|
||||
A client can request temp. S3 credentials via the STS API. It can authenticate via a client certificate and obtain a access/secret key pair as well as a session token. These credentials are associated to an S3 policy at the MinIO server.
|
||||
A client can request temp. S3 credentials via the STS API. It can authenticate via a client certificate and obtain a access/secret key pair as well as a session token. These credentials are associated to an S3 policy at the Silo server.
|
||||
|
||||
In case of certificate-based authentication, MinIO has to map the client-provided certificate to an S3 policy. MinIO does this via the subject common name field of the X.509 certificate. So, MinIO will associate a certificate with a subject `CN = foobar` to a S3 policy named `foobar`.
|
||||
In case of certificate-based authentication, Silo has to map the client-provided certificate to an S3 policy. Silo does this via the subject common name field of the X.509 certificate. So, Silo will associate a certificate with a subject `CN = foobar` to a S3 policy named `foobar`.
|
||||
|
||||
The following self-signed certificate is issued for `consoleAdmin`. So, MinIO would associate it with the pre-defined `consoleAdmin` policy.
|
||||
The following self-signed certificate is issued for `consoleAdmin`. So, Silo would associate it with the pre-defined `consoleAdmin` policy.
|
||||
|
||||
```
|
||||
Certificate:
|
||||
@@ -94,18 +94,18 @@ Certificate:
|
||||
|
||||
> Observe the `Subject: CN = consoleAdmin` field.
|
||||
|
||||
Also, note that the certificate has to contain the `Extended Key Usage: TLS Web Client Authentication`. Otherwise, MinIO would not accept the certificate as client certificate.
|
||||
Also, note that the certificate has to contain the `Extended Key Usage: TLS Web Client Authentication`. Otherwise, Silo would not accept the certificate as client certificate.
|
||||
|
||||
Now, the STS certificate-based authentication happens in 4 steps:
|
||||
|
||||
- Client sends HTTP `POST` request over a TLS connection hitting the MinIO TLS STS API.
|
||||
- MinIO verifies that the client certificate is valid.
|
||||
- MinIO tries to find a policy that matches the `CN` of the client certificate.
|
||||
- MinIO returns temp. S3 credentials associated to the found policy.
|
||||
- Client sends HTTP `POST` request over a TLS connection hitting the Silo TLS STS API.
|
||||
- Silo verifies that the client certificate is valid.
|
||||
- Silo tries to find a policy that matches the `CN` of the client certificate.
|
||||
- Silo returns temp. S3 credentials associated to the found policy.
|
||||
|
||||
The returned credentials expiry after a certain period of time that can be configured via `&DurationSeconds=3600`. By default, the STS credentials are valid for 1 hour. The minimum expiration allowed is 15 minutes.
|
||||
|
||||
Further, the temp. S3 credentials will never out-live the client certificate. For example, if the `MINIO_IDENTITY_TLS_STS_EXPIRY` is 7 days but the certificate itself is only valid for the next 3 days, then MinIO will return S3 credentials that are valid for 3 days only.
|
||||
Further, the temp. S3 credentials will never out-live the client certificate. For example, if the `MINIO_IDENTITY_TLS_STS_EXPIRY` is 7 days but the certificate itself is only valid for the next 3 days, then Silo will return S3 credentials that are valid for 3 days only.
|
||||
|
||||
## Caveat
|
||||
|
||||
@@ -113,5 +113,5 @@ Further, the temp. S3 credentials will never out-live the client certificate. Fo
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
@@ -239,7 +239,7 @@ func main() {
|
||||
|
||||
clnt, err := minio.New(u.Host, opts)
|
||||
if err != nil {
|
||||
log.Println(fmt.Errorf("Error while initializing Minio client, %s", err))
|
||||
log.Println(fmt.Errorf("error while initializing minio-go client: %s", err))
|
||||
http.Error(w, err.Error(), http.StatusBadRequest)
|
||||
return
|
||||
}
|
||||
|
||||
+31
-31
@@ -1,21 +1,21 @@
|
||||
# AssumeRoleWithWebIdentity [](https://slack.min.io)
|
||||
# AssumeRoleWithWebIdentity
|
||||
|
||||
## Introduction
|
||||
|
||||
MinIO supports the standard AssumeRoleWithWebIdentity STS API to enable integration with OIDC/OpenID based identity provider environments. This allows the generation of temporary credentials with pre-defined access policies for applications/users to interact with MinIO object storage.
|
||||
Silo supports the standard AssumeRoleWithWebIdentity STS API to enable integration with OIDC/OpenID based identity provider environments. This allows the generation of temporary credentials with pre-defined access policies for applications/users to interact with Silo object storage.
|
||||
|
||||
Calling AssumeRoleWithWebIdentity does not require the use of MinIO root or IAM credentials. Therefore, you can distribute an application (for example, on mobile devices) that requests temporary security credentials without including MinIO long lasting credentials in the application. Instead, the identity of the caller is validated by using a JWT id_token from the web identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to MinIO API operations.
|
||||
Calling AssumeRoleWithWebIdentity does not require the use of Silo root or IAM credentials. Therefore, you can distribute an application (for example, on mobile devices) that requests temporary security credentials without including Silo long lasting credentials in the application. Instead, the identity of the caller is validated by using a JWT id_token from the web identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to Silo API operations.
|
||||
|
||||
**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the `id_token` with the provider JWKS endpoint advertised by the OpenID discovery document at `MINIO_IDENTITY_OPENID_CONFIG_URL`. In practice, MinIO currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed `id_token`s, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
|
||||
**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the `id_token` with the provider JWKS endpoint advertised by the OpenID discovery document at `MINIO_IDENTITY_OPENID_CONFIG_URL`. In practice, Silo currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed `id_token`s, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
|
||||
|
||||
By default, the temporary security credentials created by AssumeRoleWithWebIdentity last for one hour. However, the optional DurationSeconds parameter can be used to specify the validity duration of the generated credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
|
||||
|
||||
## Configuring OpenID Identity Provider on MinIO
|
||||
## Configuring OpenID Identity Provider on Silo
|
||||
|
||||
Configuration can be performed via MinIO's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we show only environment variables here:
|
||||
Configuration can be performed via Silo's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we show only environment variables here:
|
||||
|
||||
```
|
||||
$ mc admin config set myminio identity_openid --env
|
||||
$ mc admin config set mysilo identity_openid --env
|
||||
KEY:
|
||||
identity_openid[:name] enable OpenID SSO support
|
||||
|
||||
@@ -28,7 +28,7 @@ MINIO_IDENTITY_OPENID_CLIENT_SECRET* (string) secret for the unique pu
|
||||
MINIO_IDENTITY_OPENID_ROLE_POLICY (string) Set the IAM access policies applicable to this client application and IDP e.g. "app-bucket-write,app-bucket-list"
|
||||
MINIO_IDENTITY_OPENID_CLAIM_NAME (string) JWT canned policy claim name (default: 'policy')
|
||||
MINIO_IDENTITY_OPENID_SCOPES (csv) Comma separated list of OpenID scopes for server, defaults to advertised scopes from discovery document e.g. "email,admin"
|
||||
MINIO_IDENTITY_OPENID_VENDOR (string) Specify vendor type for vendor specific behavior to checking validity of temporary credentials and service accounts on MinIO
|
||||
MINIO_IDENTITY_OPENID_VENDOR (string) Specify vendor type for vendor specific behavior to checking validity of temporary credentials and service accounts on Silo
|
||||
MINIO_IDENTITY_OPENID_CLAIM_USERINFO (on|off) Enable fetching claims from UserInfo Endpoint for authenticated user
|
||||
MINIO_IDENTITY_OPENID_KEYCLOAK_REALM (string) Specify Keycloak 'realm' name, only honored if vendor was set to 'keycloak' as value, if no realm is specified 'master' is default
|
||||
MINIO_IDENTITY_OPENID_KEYCLOAK_ADMIN_URL (string) Specify Keycloak 'admin' REST API endpoint e.g. http://localhost:8080/auth/admin/
|
||||
@@ -40,7 +40,7 @@ MINIO_IDENTITY_OPENID_COMMENT (sentence) optionally add a comment
|
||||
|
||||
Either `MINIO_IDENTITY_OPENID_ROLE_POLICY` (recommended) or `MINIO_IDENTITY_OPENID_CLAIM_NAME` must be specified but not both. See the section Access Control Policies to understand the differences between the two.
|
||||
|
||||
**NOTE**: When configuring multiple OpenID based authentication providers on a MinIO cluster, any number of Role Policy based providers may be configured, and at most one JWT Claim based provider may be configured.
|
||||
**NOTE**: When configuring multiple OpenID based authentication providers on a Silo cluster, any number of Role Policy based providers may be configured, and at most one JWT Claim based provider may be configured.
|
||||
|
||||
<details><summary>Example 1: Two role policy providers</summary>
|
||||
|
||||
@@ -83,23 +83,23 @@ MINIO_IDENTITY_OPENID_CLAIM_NAME="groups"
|
||||
|
||||
### Redirection from OpenID Provider
|
||||
|
||||
To login to MinIO, the user first loads the MinIO console on their browser, and selects the OpenID Provider they wish to use (the `MINIO_IDENTITY_OPENID_DISPLAY_NAME` value is shown here). The user is then redirected to the OpenID provider's login page and performs necessary login actions (e.g. entering credentials, responding to MFA authentication challenges, etc). After successful login, the user is redirected back to the MinIO console. This redirect URL is specified as a parameter by MinIO when the user is redirected to the OpenID Provider in the beginning. For some setups, extra configuration may be required for this step to work correctly.
|
||||
To login to Silo, the user first loads the Silo console on their browser, and selects the OpenID Provider they wish to use (the `MINIO_IDENTITY_OPENID_DISPLAY_NAME` value is shown here). The user is then redirected to the OpenID provider's login page and performs necessary login actions (e.g. entering credentials, responding to MFA authentication challenges, etc). After successful login, the user is redirected back to the Silo console. This redirect URL is specified as a parameter by Silo when the user is redirected to the OpenID Provider in the beginning. For some setups, extra configuration may be required for this step to work correctly.
|
||||
|
||||
For a simple setup where the user/client app accesses MinIO directly (i.e. with no intervening proxies/load-balancers), and each MinIO server (if there are more than one) has a unique domain name, this redirection should work automatically with no further configuration. For example, if the MinIO service is being accessed by the browser at the URL `https://minio-node-1.example.org`, the redirect URL will be `https://minio-node-1.example.org/oauth_callback` and all is well.
|
||||
For a simple setup where the user/client app accesses Silo directly (i.e. with no intervening proxies/load-balancers), and each Silo server (if there are more than one) has a unique domain name, this redirection should work automatically with no further configuration. For example, if the Silo service is being accessed by the browser at the URL `https://silo-node-1.example.org`, the redirect URL will be `https://silo-node-1.example.org/oauth_callback` and all is well.
|
||||
|
||||
For deployments with a load-balancer (LB), it is required that the LB is configured to send requests from the same user/client-app to the same backend MinIO server (at least for the initial login request and subsequent redirection, as the OpenID auth flow's state parameter is currently local to the MinIO server). For this setup, set the `MINIO_BROWSER_REDIRECT_URL` parameter to the publicly/client-accessible endpoint for the MinIO Console. For example `MINIO_BROWSER_REDIRECT_URL=https://console.minio.example.org`. This will ensure that the redirect URL is set to `https://console.minio.example.org/oauth_callback` and the login process should work correctly.
|
||||
For deployments with a load-balancer (LB), it is required that the LB is configured to send requests from the same user/client-app to the same backend Silo server (at least for the initial login request and subsequent redirection, as the OpenID auth flow's state parameter is currently local to the Silo server). For this setup, set the `MINIO_BROWSER_REDIRECT_URL` parameter to the publicly/client-accessible endpoint for the Silo Console. For example `MINIO_BROWSER_REDIRECT_URL=https://console.silo.example.org`. This will ensure that the redirect URL is set to `https://console.silo.example.org/oauth_callback` and the login process should work correctly.
|
||||
|
||||
For deployments employing DNS round-robin on a single domain to all the MinIO servers, it is possible that after redirection the browser may land on a different MinIO server. For example, the domain `console.minio.example.org` may resolve to `console-X.minio.example.org`, where `X` is `1`, `2`, `3` or `4`. For the login to work, if the user first landed on `console-1.minio.example.org`, they must be redirected back to the same place after logging in at the OpenID provider's web-page. To ensure this, set the `MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC=on` parameter - this lets MinIO set the redirect URL based on the "Host" header of the (initial login) request.
|
||||
For deployments employing DNS round-robin on a single domain to all the Silo servers, it is possible that after redirection the browser may land on a different Silo server. For example, the domain `console.silo.example.org` may resolve to `console-X.silo.example.org`, where `X` is `1`, `2`, `3` or `4`. For the login to work, if the user first landed on `console-1.silo.example.org`, they must be redirected back to the same place after logging in at the OpenID provider's web-page. To ensure this, set the `MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC=on` parameter - this lets Silo set the redirect URL based on the "Host" header of the (initial login) request.
|
||||
|
||||
The **deprecated** parameter `MINIO_IDENTITY_OPENID_REDIRECT_URI` works similar to the `MINIO_BROWSER_REDIRECT_URL` but needs to include the `/oauth_callback` suffix. Please do not use it, as it is sufficient to the set the `MINIO_BROWSER_REDIRECT_URL` parameter (which is required anyway for most load-balancer based setups to work correctly). This deprecated parameter **will be removed** in a future release.
|
||||
|
||||
## Specifying Access Control with IAM Policies
|
||||
|
||||
The STS API authenticates the user by verifying the JWT provided in the request. However access to object storage resources are controlled via named IAM policies defined in the MinIO instance. Once authenticated via the STS API, the MinIO server applies one or more IAM policies to the generated credentials. MinIO's AssumeRoleWithWebIdentity implementation supports specifying IAM policies in two ways:
|
||||
The STS API authenticates the user by verifying the JWT provided in the request. However access to object storage resources are controlled via named IAM policies defined in the Silo instance. Once authenticated via the STS API, the Silo server applies one or more IAM policies to the generated credentials. Silo's AssumeRoleWithWebIdentity implementation supports specifying IAM policies in two ways:
|
||||
|
||||
1. Role Policy (Recommended): When specified as part of the OpenID provider configuration, all users authenticating via this provider are authorized to (only) use the specified role policy. The policy to associate with such users is specified via the `role_policy` configuration parameter or the `MINIO_IDENTITY_OPENID_ROLE_POLICY` environment variable. The value is a comma-separated list of IAM access policy names already defined in the server. In this situation, the server prints a role ARN at startup that must be specified as a `RoleArn` API request parameter in the STS AssumeRoleWithWebIdentity API call. When using Role Policies, multiple OpenID providers and/or client applications (with unique client IDs) may be configured with independent role policies. Each configuration is assigned a unique RoleARN by the MinIO server and this is used to select the policies to apply to temporary credentials generated in the AssumeRoleWithWebIdentity call.
|
||||
1. Role Policy (Recommended): When specified as part of the OpenID provider configuration, all users authenticating via this provider are authorized to (only) use the specified role policy. The policy to associate with such users is specified via the `role_policy` configuration parameter or the `MINIO_IDENTITY_OPENID_ROLE_POLICY` environment variable. The value is a comma-separated list of IAM access policy names already defined in the server. In this situation, the server prints a role ARN at startup that must be specified as a `RoleArn` API request parameter in the STS AssumeRoleWithWebIdentity API call. When using Role Policies, multiple OpenID providers and/or client applications (with unique client IDs) may be configured with independent role policies. Each configuration is assigned a unique RoleARN by the Silo server and this is used to select the policies to apply to temporary credentials generated in the AssumeRoleWithWebIdentity call.
|
||||
|
||||
2. `id_token` claims: When the role policy is not configured, MinIO looks for a specific claim in the `id_token` (JWT) returned by the OpenID provider in the STS request. The default claim is `policy` and can be overridden by the `claim_name` configuration parameter or the `MINIO_IDENTITY_OPENID_CLAIM_NAME` environment variable. The claim value can be a string (comma-separated list) or an array of IAM access policy names defined in the server. A `RoleArn` API request parameter *must not* be specified in the STS AssumeRoleWithWebIdentity API call.
|
||||
2. `id_token` claims: When the role policy is not configured, Silo looks for a specific claim in the `id_token` (JWT) returned by the OpenID provider in the STS request. The default claim is `policy` and can be overridden by the `claim_name` configuration parameter or the `MINIO_IDENTITY_OPENID_CLAIM_NAME` environment variable. The claim value can be a string (comma-separated list) or an array of IAM access policy names defined in the server. A `RoleArn` API request parameter *must not* be specified in the STS AssumeRoleWithWebIdentity API call.
|
||||
|
||||
## API Request Parameters
|
||||
|
||||
@@ -113,7 +113,7 @@ The OAuth 2.0 id_token that is provided by the web identity provider. Applicatio
|
||||
| *Length Constraints* | *Minimum length of 4. Maximum length of 2048.* |
|
||||
| *Required* | *Yes* |
|
||||
|
||||
### WebIdentityAccessToken (MinIO Extension)
|
||||
### WebIdentityAccessToken (Silo Extension)
|
||||
|
||||
There are situations when identity provider does not provide user claims in `id_token` instead it needs to be retrieved from UserInfo endpoint, this extension is only useful in this scenario. This is rare so use it accordingly depending on your Identity provider implementation. `access_token` is available as part of the OIDC authentication flow similar to `id_token`.
|
||||
|
||||
@@ -171,7 +171,7 @@ XML error response for this API is similar to [AWS STS AssumeRoleWithWebIdentity
|
||||
## Sample `POST` Request
|
||||
|
||||
```
|
||||
http://minio.cluster:9000?Action=AssumeRoleWithWebIdentity&DurationSeconds=3600&WebIdentityToken=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
|
||||
http://silo.cluster:9000?Action=AssumeRoleWithWebIdentity&DurationSeconds=3600&WebIdentityToken=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
|
||||
```
|
||||
|
||||
## Sample Response
|
||||
@@ -199,18 +199,18 @@ http://minio.cluster:9000?Action=AssumeRoleWithWebIdentity&DurationSeconds=3600&
|
||||
|
||||
```
|
||||
export MINIO_ROOT_USER=minio
|
||||
export MINIO_ROOT_PASSWORD=minio123
|
||||
export MINIO_ROOT_PASSWORD=silo123
|
||||
export MINIO_IDENTITY_OPENID_CONFIG_URL=https://accounts.google.com/.well-known/openid-configuration
|
||||
export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
|
||||
# Optional: Allow to specify the requested OpenID scopes (OpenID only requires the `openid` scope)
|
||||
#export MINIO_IDENTITY_OPENID_SCOPES="openid,profile,email"
|
||||
minio server /mnt/export
|
||||
silo server /mnt/export
|
||||
```
|
||||
|
||||
or using `mc`
|
||||
|
||||
```
|
||||
mc admin config get myminio identity_openid
|
||||
mc admin config get mysilo identity_openid
|
||||
identity_openid config_url=https://accounts.google.com/.well-known/openid-configuration client_id=843351d4-1080-11ea-aa20-271ecba3924a
|
||||
```
|
||||
|
||||
@@ -246,32 +246,32 @@ $ go run web-identity.go -cid 204367807228-ok7601k6gj1pgge7m09h7d79co8p35xx.apps
|
||||
- Visit <http://localhost:8080>, login will direct the user to the Google OAuth2 Auth URL to obtain a permission grant.
|
||||
- The redirection URI (callback handler) receives the OAuth2 callback, verifies the state parameter, and obtains a Token.
|
||||
- Using the id_token the callback handler further talks to Google OAuth2 Token URL to obtain an JWT id_token.
|
||||
- Once obtained the JWT id_token is further sent to STS endpoint i.e MinIO to retrieve temporary credentials.
|
||||
- Once obtained the JWT id_token is further sent to STS endpoint i.e Silo to retrieve temporary credentials.
|
||||
- Temporary credentials are displayed on the browser upon successful retrieval.
|
||||
|
||||
## Using MinIO Console
|
||||
## Using Silo Console
|
||||
|
||||
To support WebIdentity based login for MinIO Console, set openid configuration and restart MinIO
|
||||
To support WebIdentity based login for Silo Console, set openid configuration and restart Silo
|
||||
|
||||
```
|
||||
mc admin config set myminio identity_openid config_url="<CONFIG_URL>" client_id="<client_identifier>"
|
||||
mc admin config set mysilo identity_openid config_url="<CONFIG_URL>" client_id="<client_identifier>"
|
||||
```
|
||||
|
||||
```
|
||||
mc admin service restart myminio
|
||||
mc admin service restart mysilo
|
||||
```
|
||||
|
||||
Sample URLs for Keycloak are
|
||||
|
||||
`config_url` - `http://localhost:8080/auth/realms/demo/.well-known/openid-configuration`
|
||||
|
||||
JWT token returned by the Identity Provider should include a custom claim for the policy, this is required to create a STS user in MinIO. The name of the custom claim could be either `policy` or `<NAMESPACE_PREFIX>policy`. If there is no namespace then `claim_prefix` can be ignored. For example if the custom claim name is `https://min.io/policy` then, `claim_prefix` should be set as `https://min.io/`.
|
||||
JWT token returned by the Identity Provider should include a custom claim for the policy, this is required to create a STS user in Silo. The name of the custom claim could be either `policy` or `<NAMESPACE_PREFIX>policy`. If there is no namespace then `claim_prefix` can be ignored. For example if the custom claim name is `https://min.io/policy` then, `claim_prefix` should be set as `https://min.io/`.
|
||||
|
||||
- Open MinIO Console and click `Login with SSO`
|
||||
- Open Silo Console and click `Login with SSO`
|
||||
- The user will be redirected to the Identity Provider login page
|
||||
- Upon successful login on Identity Provider page the user will be automatically logged into MinIO Console.
|
||||
- Upon successful login on Identity Provider page the user will be automatically logged into Silo Console.
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
+11
-11
@@ -1,6 +1,6 @@
|
||||
# WSO2 Quickstart Guide [](https://slack.min.io)
|
||||
# WSO2 Quickstart Guide
|
||||
|
||||
WSO2 is an Identity Server open source and is released under Apache Software License Version 2.0, this document covers configuring WSO2 to be used as an identity provider for MinIO server STS API.
|
||||
WSO2 is an Identity Server open source and is released under Apache Software License Version 2.0, this document covers configuring WSO2 to be used as an identity provider for Silo server STS API.
|
||||
|
||||
## Get started
|
||||
|
||||
@@ -16,7 +16,7 @@ Once WSO2 is up and running, configure WSO2 to generate Self contained id_tokens
|
||||
1. The id_token is an identifier that is hard to guess. For example, a randomly generated string of sufficient length, that the server handling the protected resource can use to lookup the associated authorization information.
|
||||
2. The id_token self-contains the authorization information in a manner that can be verified. For example, by encoding authorization information along with a signature into the token.
|
||||
|
||||
WSO2 generates tokens in first style by default, but if to be used with MinIO we should configure WSO2 to provide JWT tokens instead.
|
||||
WSO2 generates tokens in first style by default, but if to be used with Silo we should configure WSO2 to provide JWT tokens instead.
|
||||
|
||||
### 3. Generate Self-contained Access Tokens
|
||||
|
||||
@@ -73,21 +73,21 @@ The id_token received is a signed JSON Web Token (JWT). Use a JWT decoder to dec
|
||||
| jti | _string_ | Unique identifier for the JWT token. |
|
||||
| policy | _string_ | Canned policy name to be applied for STS credentials. (Recommended) |
|
||||
|
||||
Using the above `id_token` we can perform an STS request to MinIO to get temporary credentials for MinIO API operations. MinIO STS API uses [JSON Web Key Set Endpoint](https://docs.wso2.com/display/IS541/JSON+Web+Key+Set+Endpoint) to validate if JWT is valid and is properly signed.
|
||||
Using the above `id_token` we can perform an STS request to Silo to get temporary credentials for Silo API operations. Silo STS API uses [JSON Web Key Set Endpoint](https://docs.wso2.com/display/IS541/JSON+Web+Key+Set+Endpoint) to validate if JWT is valid and is properly signed.
|
||||
|
||||
**We recommend setting `policy` as a custom claim for the JWT service provider follow [here](https://docs.wso2.com/display/IS550/Configuring+Claims+for+a+Service+Provider) and [here](https://docs.wso2.com/display/IS550/Handling+Custom+Claims+with+the+JWT+Bearer+Grant+Type) for relevant docs on how to configure claims for a service provider.**
|
||||
|
||||
### 5. Setup MinIO with OpenID configuration URL
|
||||
### 5. Setup Silo with OpenID configuration URL
|
||||
|
||||
MinIO server expects environment variable for OpenID configuration url as `MINIO_IDENTITY_OPENID_CONFIG_URL`, this environment variable takes a single entry.
|
||||
Silo server expects environment variable for OpenID configuration url as `MINIO_IDENTITY_OPENID_CONFIG_URL`, this environment variable takes a single entry.
|
||||
|
||||
```
|
||||
export MINIO_IDENTITY_OPENID_CONFIG_URL=https://localhost:9443/oauth2/oidcdiscovery/.well-known/openid-configuration
|
||||
export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
|
||||
minio server /mnt/data
|
||||
silo server /mnt/data
|
||||
```
|
||||
|
||||
Assuming that MinIO server is configured to support STS API by following the doc [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/), execute the following command to temporary credentials from MinIO server.
|
||||
Assuming that Silo server is configured to support STS API by following the doc [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/), execute the following command to temporary credentials from Silo server.
|
||||
|
||||
```
|
||||
go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga
|
||||
@@ -101,9 +101,9 @@ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrO
|
||||
}
|
||||
```
|
||||
|
||||
These credentials can now be used to perform MinIO API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
|
||||
These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
|
||||
|
||||
## Explore Further
|
||||
|
||||
- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The MinIO documentation website](https://silo.pgsty.com/docs/)
|
||||
- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
|
||||
- [The Silo documentation website](https://silo.pgsty.com/docs/)
|
||||
|
||||
Reference in New Issue
Block a user