ChenSammi commented on code in PR #11053: URL: https://github.com/apache/ozone/pull/11053#discussion_r4290230022
########## 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: @chungen0126 , since we don't have these fine grained permissions in native ACL than Ranger, so instead of using READ_ACL or WRITE_ACL, I would like to propose, for object and bucket - READ permission for lock information receive - owner for lock information update(except the compliance update action) for compliance mode update - Only ozone admin And fallback is not supported, if Ranger is configured, when always use Ranger for the authorization; If Native ACL is configured, when always use Native ACL. So if user wants the fine grained permission control, then he/she use Ranger, which is our recommendation too for this feature. If Ranger is not available, then Native ACL can be used, which provides the same(or even stricter) level of security protection. @symious @xichen01 @ivandika3 , will this meet your requirements if in future you guys want to use this feature? -- 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]
