mirror of
https://github.com/pgsty/minio.git
synced 2026-08-09 15:53:28 +03:00
Feng Ruohang
fd2ca1c6d2
README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE, code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue and pull request templates, and the docs/ tree all present Silo as the product. The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel titles and descriptions rebranded while every minio_* query, label and expression is left alone, so existing alerts and recording rules keep matching. The distinction the review demanded is applied per hit rather than by search-and-replace: - Product and command text becomes Silo and silo: install and run instructions, systemd examples, compose services, download links, badges. - Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics, x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and error names. - Attribution keeps MinIO and gains the fork's own: the AGPL obligations, original copyright, CREDITS and NOTICE stay, with the modification notice added alongside rather than replacing them. - Historical and third-party references are left as facts, not rewritten for brand tidiness. README and README_ZH each carry an explicit non-affiliation notice, document the side-by-side package migration including the /etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a legacy UID/GID, and state that recursive chown is never performed. The trademark attribution uses the policy's approved "based on MinIO technology" wording, not the shortened form the policy rejects. github.com/pgsty/minio links are left in place and labelled transitional. The repository has not been renamed, and rewriting them now would produce documented URLs that 404 until the cutover; they change in the cutover commit together with the goreleaser release target, the OCI source label and the raw-content branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
84 lines
2.2 KiB
Markdown
84 lines
2.2 KiB
Markdown
# OPA Quickstart Guide [](https://slack.minio.io)
|
|
|
|
OPA is a lightweight general-purpose policy engine that can be co-located with Silo server, in this document we talk about how to use OPA HTTP API to authorize requests. It can be used with any type of credentials (STS based like OpenID or LDAP, regular IAM users or service accounts).
|
|
|
|
OPA is enabled through Silo's Access Management Plugin feature.
|
|
|
|
## Get started
|
|
|
|
### 1. Start OPA in a container
|
|
|
|
```sh
|
|
podman run -it \
|
|
--name opa \
|
|
--publish 8181:8181 \
|
|
docker.io/openpolicyagent/opa:0.40.0-rootless \
|
|
run --server \
|
|
--log-format=json-pretty \
|
|
--log-level=debug \
|
|
--set=decision_logs.console=true
|
|
```
|
|
|
|
### 2. Create a sample OPA Policy
|
|
|
|
In another terminal, create a policy that allows root user all access and for all other users denies `PutObject`:
|
|
|
|
```sh
|
|
cat > example.rego <<EOF
|
|
package httpapi.authz
|
|
|
|
import input
|
|
|
|
default allow = false
|
|
|
|
# Allow the root user to perform any action.
|
|
allow {
|
|
input.owner == true
|
|
}
|
|
|
|
# All other users may do anything other than call PutObject
|
|
allow {
|
|
input.action != "s3:PutObject"
|
|
input.owner == false
|
|
}
|
|
EOF
|
|
```
|
|
|
|
Then load the policy via OPA's REST API.
|
|
|
|
```
|
|
curl -X PUT --data-binary @example.rego \
|
|
localhost:8181/v1/policies/putobject
|
|
```
|
|
|
|
### 4. Setup Silo with OPA
|
|
|
|
Set the `MINIO_POLICY_PLUGIN_URL` as the endpoint that Silo should send authorization requests to. Then start the server.
|
|
|
|
```sh
|
|
export MINIO_POLICY_PLUGIN_URL=http://localhost:8181/v1/data/httpapi/authz/allow
|
|
export MINIO_CI_CD=1
|
|
export MINIO_ROOT_USER=minio
|
|
export MINIO_ROOT_PASSWORD=silo123
|
|
silo server /mnt/data
|
|
```
|
|
|
|
### 5. Test with a regular IAM user
|
|
|
|
Ensure that `mc` is installed and the configured with the above server with the alias `mysilo`.
|
|
|
|
```sh
|
|
# 1. Create a bucket and a user, and upload a file. These operations will succeed.
|
|
mc mb mysilo/test
|
|
mc admin user add mysilo foo foobar123
|
|
mc cp /etc/issue mysilo/test/
|
|
|
|
# 2. Now access the server as user `foo`. These operations will also succeed.
|
|
export MC_HOST_foo=http://foo:foobar123@localhost:9000
|
|
mc ls foo/test
|
|
mc cat foo/test/issue
|
|
|
|
# 3. Attempt to upload an object as user `foo` - this will fail with a permissions error.
|
|
mc cp /etc/issue mysilo/test/issue2
|
|
```
|