fmorg-git commented on code in PR #11053: URL: https://github.com/apache/ozone/pull/11053#discussion_r4278186434
########## 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: It was a good observation by @Gargi-jais11 that actions are only sent in S3Gateway and Ranger if STS is enabled (they were only needed for STS at that point). The reason STS flag was not defaulted to true is because the Ranger team defaulted their flag to false and if the STS flag is true and the Ranger flag is false, there would be security issues. However, I'm concerned that the approach outlined in this design would have actions being set in multiple places like S3gActionIamMapper and in these new requests like OMKeySetLegalHoldRequest so the maintenance becomes more difficult. Would it be feasible to separate the actions being sent in S3Gateway and RequestContext from the STS flag? @ChenSammi thoughts? -- 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]
