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): - `GetBucketObjectLockConfiguration` / `GetObjectRetention` / `GetObjectLegalHold` require `READ`. - Changing a legal hold, a Governance retention, or the bucket configuration is limited to the owner of the volume or bucket (the same owner the native authorizer already lets skip ACL checks), or an Ozone administrator. The owner can also bypass Governance retention. - Setting a Compliance retention is limited to Ozone administrators: setting it on a key (`PutObjectRetention` or the `x-amz-object-lock-*` headers), changing Governance to Compliance, and setting Compliance as a bucket default. Keys that inherit a Compliance bucket default do not need an extra check. Extending a Compliance retention or releasing its event hold only needs the owner, as in AWS S3 where it only needs `PutObjectRetention`. - @fmorg-git, this also answers the `READ_ACL` question: native ACLs no longer use `READ_ACL` / `WRITE_ACL` for Object Lock. Native ACLs have no actions, so instead of approximating them with ACL types, they use ownership and the administrator role, which is stricter. **Ranger**: - The doc now describes two authorization models, native ACLs and Ranger, and recommends enabling `enableActionMatcherInPoliciesCondition` for fine-grained permissions. I removed the STS flag combinations and the "fallback" wording. - The doc depends on HDDS-17054, so S3 Gateway always sends the S3 action. - @fmorg-git, on the concern about actions being set in several places: the new OM requests do not set S3 actions. - With Ranger, OM maps each operation to an access type, and `action-matches` only narrows a policy item. Requests without an S3 action (ofs, o3fs, CLI, native Java API) are matched only by items without the condition or with `*`, so switching to a non-S3 client cannot get around an action restriction. This is now described in the Trusted Boundary section; deployments with both S3 and non-S3 access should keep such items for non-S3 clients. -- 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]
