chungen0126 commented on code in PR #11053:
URL: https://github.com/apache/ozone/pull/11053#discussion_r4278282353


##########
hadoop-hdds/docs/content/design/s3-object-lock.md:
##########
@@ -0,0 +1,612 @@
+---
+title: S3 Object Lock
+summary: Design to support S3 object lock.
+date: 2026-08-18
+jira: HDDS-15945
+status: draft
+author: Chung En Lee
+---
+<!--
+  Licensed under the Apache License, Version 2.0 (the "License");
+  you may not use this file except in compliance with the License.
+  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License. See accompanying LICENSE file.
+-->
+
+# S3 Object Lock Design Doc
+
+## Summary
+
+This design document aims to plan and implement the Object Lock mechanism for 
OBS buckets integrated with Ranger.
+The primary objective is to provide data immutability and tamper-proof 
protection through the object locking feature.
+
+## Problem statement
+
+With growing demands for data security and compliance, ensuring that critical 
data stored in OBS (Object Storage) is
+protected from accidental or malicious deletion and overwriting has become an 
essential system protection requirement.
+To establish a more rigorous data protection mechanism, we plan to introduce 
the Object Lock feature.
+
+Considering the current system architecture and access control strategies,
+this design integrates with existing Apache Ranger to manage Object Lock 
permissions on OBS buckets.
+Meanwhile, to accelerate core feature delivery, we have decided to exclude 
complex multi-version locking (Versioning Lock),
+Legacy buckets, and FSO buckets from this initial release. In addition, 
support for Native ACLs is excluded; Native ACLs typically grant permissions 
+at the granular bucket or object level, whereas Object Lock permission 
management favors broad, role-based authorization,
+creating a conflict in design philosophies. Narrowing the scope allows us to 
focus on the core functionality and ensure a rapid, 
+stable rollout of baseline tamper-proof protection.
+
+**Goal:**
+
+* Implement the Object Lock feature on standard OBS buckets, fully integrated 
with Ranger for permission and access control. 
+* Support single-version objects only.
+
+## Non-Goal
+
+* Versioning Lock: Support for locking across multiple object versions is 
deferred (multi-version core features are currently under development).
+* Legacy and FSO Buckets: Object Lock support for legacy and FSO buckets is 
excluded. The following considerations are deferred to a future phase:
+  * Lock Granularity: FSO separates files and directories across FileTable and 
DirectoryTable, requiring explicit policy decisions on whether lock semantics 
apply at the file level, directory level, or both. 
+  * Rename & Move Semantics: Renaming or moving paths alters namespace 
hierarchy without mutating object content; rules must be defined to either 
block operations on locked paths or preserve lock metadata across the same 
objectID
+* Native ACL Support: Native ACLs will not be used for access control or 
advanced configuration such as Retention Mode (Governance); access management 
is centralized exclusively via Ranger.
+
+## Differences from AWS
+
+* Single-Version Model: Locks apply to the current key rather than individual 
object versions. 
+* Direct Overwrite Blocking: Unlike AWS S3 (which writes a new version), Ozone 
strictly rejects Put, Copy, and MPU requests on locked keys with 403 Access 
Denied (WORMProtectionException). 
+* Ranger-Dependent Auth: Lock governance relies exclusively on Apache Ranger 
and STS action matching (enableActionMatcherInPoliciesCondition). Object Lock 
is not supported on clusters without Ranger: OM rejects all Object Lock 
configuration requests unless the Ranger authorizer is in use.
+
+## Technical Description
+
+### Terminology
+
+**Legal Hold**
+
+* **Definition**: Applies an indefinite lock status to an object. The object 
remains protected until an administrator explicitly removes the lock (Remove 
Legal Hold). 
+* **Restricted Operations**:
+  * Put Object 
+  * Delete Object 
+  * Multipart Initial / Complete
+* **Allowed Operations**:

Review Comment:
   Done. Head Object and Get/Put Object Tagging are listed as allowed 
operations for both legal hold and retention.



-- 
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]

Reply via email to