You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update the STS, security, select, and Docker documentation to reflect the recent hardening work, including LDAP STS throttling details, OIDC JWT verification changes, and the new pgsty-specific security policy and advisory index.
Rewrite repository and raw-document links that still pointed at minio/minio so the docs consistently reference pgsty/minio instead.
The core idea is to keep the documentation aligned with the fork's actual security behavior, ownership, and upgrade guidance without mixing in unrelated code changes.
This repository is the `pgsty/minio` community fork of `minio/minio`. Upstream MinIO security contacts do not handle fork-specific fixes or release notes for this repository.
4
+
3
5
## Supported Versions
4
6
5
-
We always provide security updates for the [latest release](https://github.com/minio/minio/releases/latest).
6
-
Whenever there is a security update you just need to upgrade to the latest version.
7
+
Security fixes are tracked on the active `master` branch and summarized in [docs/security/advisories.md](docs/security/advisories.md).
7
8
8
9
## Reporting a Vulnerability
9
10
10
-
All security bugs in [minio/minio](https://github,com/minio/minio) (or other minio/* repositories)
11
-
should be reported by email to security@min.io. Your email will be acknowledged within 48 hours,
12
-
and you'll receive a more detailed response to your email within 72 hours indicating the next steps
13
-
in handling your report.
14
-
15
-
Please, provide a detailed explanation of the issue. In particular, outline the type of the security
16
-
issue (DoS, authentication bypass, information disclose, ...) and the assumptions you're making (e.g. do
17
-
you need access credentials for a successful exploit).
18
-
19
-
If you have not received a reply to your email within 48 hours or you have not heard from the security team
20
-
for the past five days please contact the security team directly:
21
-
22
-
- Primary security coordinator: aead@min.io
23
-
- Secondary coordinator: harsha@min.io
24
-
- If you receive no response: dev@min.io
25
-
26
-
### Disclosure Process
11
+
For vulnerabilities in this fork:
27
12
28
-
MinIO uses the following disclosure process:
13
+
1. Follow the fork-specific expectations in [VULNERABILITY_REPORT.md](VULNERABILITY_REPORT.md).
14
+
2. Prefer the `pgsty/minio` repository's GitHub security reporting workflow when it is available.
15
+
3. If private reporting is not available, contact the maintainers through the `pgsty/minio` repository before publishing detailed exploit information.
16
+
4. If you confirm the issue also affects upstream `minio/minio`, report it upstream separately.
29
17
30
-
1. Once the security report is received one member of the security team tries to verify and reproduce
31
-
the issue and determines the impact it has.
32
-
2. A member of the security team will respond and either confirm or reject the security report.
33
-
If the report is rejected the response explains why.
34
-
3. Code is audited to find any potential similar problems.
35
-
4. Fixes are prepared for the latest release.
36
-
5. On the date that the fixes are applied a security advisory will be published on <https://blog.min.io>.
37
-
Please inform us in your report email whether MinIO should mention your contribution w.r.t. fixing
38
-
the security issue. By default MinIO will **not** publish this information to protect your privacy.
18
+
## Disclosure Process
39
19
40
-
This process can take some time, especially when coordination is required with maintainers of other projects.
41
-
Every effort will be made to handle the bug in as timely a manner as possible, however it's important that we
42
-
follow the process described above to ensure that disclosures are handled consistently.
20
+
Fork-specific fixes and user-visible upgrade notes are published in [docs/security/advisories.md](docs/security/advisories.md). The fork-specific triage and remediation process is described in [VULNERABILITY_REPORT.md](VULNERABILITY_REPORT.md).
Kubernetes manages stateless Spark and Hive containers elastically on the compute nodes. Spark has native scheduler integration with Kubernetes. Hive, for legacy reasons, uses YARN scheduler on top of Kubernetes.
8
8
@@ -23,17 +23,17 @@ MinIO also supports multi-cluster, multi-site federation similar to AWS regions
23
23
24
24
After successful installation navigate to the Ambari UI `http://<ambari-server>:8080/` and login using the default credentials: [**_username: admin, password: admin_**]
For more information about these options please visit [https://www.cloudera.com/documentation/enterprise/5-11-x/topics/admin_hive_on_s3_tuning.html](https://www.cloudera.com/documentation/enterprise/5-11-x/topics/admin_hive_on_s3_tuning.html)
Copy file name to clipboardExpand all lines: docs/bucket/lifecycle/DESIGN.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# ILM Tiering Design [](https://slack.min.io)[](https://hub.docker.com/r/minio/minio/)
2
2
3
-
Lifecycle transition functionality provided in [bucket lifecycle guide](https://github.com/minio/minio/master/docs/bucket/lifecycle/README.md) allows tiering of content from MinIO object store to public clouds or other MinIO clusters.
3
+
Lifecycle transition functionality provided in [bucket lifecycle guide](https://github.com/pgsty/minio/blob/master/docs/bucket/lifecycle/README.md) allows tiering of content from MinIO object store to public clouds or other MinIO clusters.
4
4
5
5
Transition tiers can be added to MinIO using `mc admin tier add` command to associate a `gcs`, `s3` or `azure` bucket or prefix path on a bucket to the tier name.
6
6
Lifecycle transition rules can be applied to buckets (both versioned and un-versioned) by specifying the tier name defined above as the transition storage class for the lifecycle rule.
This document explains the design approach of server side bucket replication. If you're looking to get started with replication, we suggest you go through the [Bucket replication guide](https://github.com/minio/minio/blob/master/docs/bucket/replication/README.md) first.
3
+
This document explains the design approach of server side bucket replication. If you're looking to get started with replication, we suggest you go through the [Bucket replication guide](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/README.md) first.
4
4
5
5
## Overview
6
6
@@ -59,7 +59,7 @@ If 3 or more targets are participating in active-active replication, the replica
59
59
60
60
### Internal metadata for replication
61
61
62
-
`xl.meta` that is in use for [versioning](https://github.com/minio/minio/blob/master/docs/bucket/versioning/DESIGN.md) has additional metadata for replication of objects,delete markers and versioned deletes.
62
+
`xl.meta` that is in use for [versioning](https://github.com/pgsty/minio/blob/master/docs/bucket/versioning/DESIGN.md) has additional metadata for replication of objects,delete markers and versioned deletes.
Copy file name to clipboardExpand all lines: docs/bucket/replication/README.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -94,7 +94,7 @@ The access key provided for the replication *target* cluster should have these m
94
94
}
95
95
```
96
96
97
-
Please note that the permissions required by the admin user on the target cluster can be more fine grained to exclude permissions like "s3:ReplicateDelete", "s3:GetBucketObjectLockConfiguration" etc depending on whether delete replication rules are set up or if object locking is disabled on `destbucket`. The above policies assume that replication of objects, tags and delete marker replication are all enabled on object lock enabled buckets. A sample script to setup replication is provided [here](https://github.com/minio/minio/blob/master/docs/bucket/replication/setup_replication.sh)
97
+
Please note that the permissions required by the admin user on the target cluster can be more fine grained to exclude permissions like "s3:ReplicateDelete", "s3:GetBucketObjectLockConfiguration" etc depending on whether delete replication rules are set up or if object locking is disabled on `destbucket`. The above policies assume that replication of objects, tags and delete marker replication are all enabled on object lock enabled buckets. A sample script to setup replication is provided [here](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/setup_replication.sh)
98
98
99
99
To set up replication from a source bucket `srcbucket` on myminio cluster to a bucket `destbucket` on the target minio cluster with endpoint https://replica-endpoint:9000, use:
100
100
```
@@ -161,9 +161,9 @@ Replication status can be seen in the metadata on the source and destination obj
161
161
162
162
To perform bi-directional replication, repeat the above process on the target site - this time setting the source bucket as the replication target. It is recommended that replication be run in a system with at least two CPU's available to the process, so that replication can run in its own thread.
@@ -210,11 +210,11 @@ Also note that `mc` version `RELEASE.2021-09-02T09-21-27Z` or older supports onl
210
210
211
211
Status of delete marker replication can be viewed by doing a GET/HEAD on the object version - it will return a `X-Minio-Replication-DeleteMarker-Status` header and http response code of `405`. In the case of permanent deletes, if the delete replication is pending or failed to propagate to the target cluster, GET/HEAD will return additional `X-Minio-Replication-Delete-Status` header and a http response code of `405`.
The status of replication can be monitored by configuring event notifications on the source and target buckets using `mc event add`.On the source side, the `s3:PutObject`, `s3:Replication:OperationCompletedReplication` and `s3:Replication:OperationFailedReplication` events show the status of replication in the `X-Amz-Replication-Status` metadata.
216
216
217
-
On the target bucket, `s3:PutObject` event shows `X-Amz-Replication-Status` status of `REPLICA` in the metadata. Additional metrics to monitor backlog state for the purpose of bandwidth management and resource allocation are exposed via Prometheus - see <https://github.com/minio/minio/blob/master/docs/metrics/prometheus/list.md> for more details.
217
+
On the target bucket, `s3:PutObject` event shows `X-Amz-Replication-Status` status of `REPLICA` in the metadata. Additional metrics to monitor backlog state for the purpose of bandwidth management and resource allocation are exposed via Prometheus - see <https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/list.md> for more details.
218
218
219
219
### Sync/Async Replication
220
220
@@ -276,6 +276,6 @@ MinIO does not support SSE-C encrypted objects on replicated buckets, any applic
0 commit comments