chungen0126 commented on code in PR #11053: URL: https://github.com/apache/ozone/pull/11053#discussion_r4311746581
########## hadoop-hdds/docs/content/design/s3-object-lock.md: ########## @@ -203,7 +241,18 @@ To enable action-level authorization and onboard Object Lock actions into the Oz ```properties ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition=true ``` -* When enabled, Ozone S3 Gateway (S3G) intercepts the high-level S3 API operation and populates the S3 action name into the `RangerAccessRequest`, allowing Ranger's `RangerActionMatcher` to evaluate policy conditions against incoming requests. +* When enabled, the S3 action name in the `RangerAccessRequest` is evaluated by Ranger's `RangerActionMatcher` against policy conditions. + Without this flag, Ranger ignores the action and only checks the primitive access type (for example, plain `WRITE` for `PutObjectLegalHold`), + so this flag is a prerequisite for using Object Lock with Ranger. + +**OM Determines the Object Lock Action**: +* Today OM forwards `S3Authentication.s3Action` from S3 Gateway to Ranger as is, and only when `ozone.s3g.sts.http.enabled=true` (default `false`). + For Object Lock, OM must not depend on that string, because a wrong mapping in S3 Gateway, a native client that sends no action, + or STS being disabled would all reduce the check to plain `WRITE`. +* Instead, each Object Lock OM request sets the S3 action in the `RequestContext` itself, based on the request type: + `OMKeySetLegalHoldRequest` always checks `PutObjectLegalHold`, `OMKeySetRetentionRequest` checks `PutObjectRetention`, the bucket request checks `PutBucketObjectLockConfiguration`, + and any request with `bypassGovernanceRetention = true` additionally checks `BypassGovernanceRetention`. +* As a result, Object Lock with Ranger does not require STS to be enabled, and S3 Gateway, native clients and STS sessions are checked the same way. Review Comment: @ChenSammi @fmorg-git Updated the doc: - Native ACLs: following @ChenSammi's proposal fully, every Compliance change needs an Ozone administrator, including extending it, because no API can undo that either. The one exception is releasing the event hold of a Compliance key without a `RetainUntilDate`: it only turns the duration an administrator already approved into a date, so the owner can do it when the business event happens. Keys that inherit a Compliance bucket default need no extra check, so applications can upload Compliance data as normal users. - Ranger: reading lock information needs `READ`, and changing locks needs `WRITE` (plus `DELETE` for the bypass), the same access types as for data, instead of `READ_ACL` / `WRITE_ACL`. This matches what @fmorg-git described earlier (for example `PutObjectLegalHold` with `write`). Ranger has no administrator role, so setting Compliance only needs `PutObjectRetention`, as in AWS S3, and `action-matches` is what separates lock management from data writes. - `ozone repair om object-lock` is for both models: no API can relax a Compliance retention, so one set by mistake can only be removed offline. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
