chungen0126 commented on code in PR #11053:
URL: https://github.com/apache/ozone/pull/11053#discussion_r4278985247
##########
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:
Thanks @fmorg-git, @ChenSammi, and @Gargi-jais11 for the great discussion!
I agree with @fmorg-git that setting S3 actions inside OM requests
duplicates the mapping logic in `S3GActionIamMapper` and makes maintenance
harder.
More importantly, from an architectural standpoint, OM should not be
responsible for injecting S3 actions: **S3 actions are strictly an S3-protocol
concept and should only be enforced when requests go through S3 Gateway.** For
users calling the Ozone Native Java API or CLI directly, we should assume by
default that they are operating under Ozone's native permission model rather
than S3's fine-grained IAM action model.
Therefore, I propose we divide the authorization model into two clear tiers
in the design doc:
1. **Strict S3-Compatible Fine-Grained Mode (S3G with Both Flags Enabled)**:
- We will explicitly document that fine-grained S3 action-level
authorization (`PutObjectLegalHold`, `PutObjectRetention`,
`BypassGovernanceRetention`, etc.) applies strictly to requests routed through
**S3 Gateway** and requires **both** `ozone.s3g.sts.http.enabled=true` and
`ranger.servicedef.ozone.enableActionMatcherInPoliciesCondition=true`.
- In this mode, S3G extracts and passes the `s3Action` via
`RequestContext` as it currently does, keeping the S3 action mapping cleanly
isolated within S3G without extra overhead when the flag is off.
2. **Fallback / Native API Mode (Native Java API, CLI, Native ACL, or when
either flag is disabled)**:
- Callers using the Ozone Native Java API/CLI (or when S3 action matching
is not enabled) do not use S3 fine-grained actions; instead, authorization
falls back to the base ACL permission table in OM.
- To prevent the privilege escalation issue @Gargi-jais11 pointed out
(where a user with plain `WRITE` could remove a lock or retention), we should
elevate the required base permissions for Object Lock management operations
from plain `READ` / `WRITE` to **`READ_ACL` / `WRITE_ACL`** (e.g., querying
lock/retention status requires `READ_ACL`, and configuring/clearing legal hold,
retention, bucket lock config, or bypassing governance requires `WRITE_ACL`).
This way:
- Architectural boundaries remain clean: S3G handles S3 actions, and OM
handles Ozone base permissions without hardcoding S3-specific concepts.
- Normal users with only `READ`/`WRITE`/`DELETE` data permissions cannot
tamper with locks via Native Client or when STS is off.
- Clusters using Native ACLs (without Ranger) automatically get sensible
admin-level protection for Object Lock out of the box.
- (We just need to make sure the base permission mappings for these new
actions in Ranger / `IamSessionPolicyResolver` align with `READ_ACL` /
`WRITE_ACL`).
How does this sound to everyone?
--
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]
