F64116045 commented on code in PR #11053: URL: https://github.com/apache/ozone/pull/11053#discussion_r4001480104
########## hadoop-hdds/docs/content/design/s3-object-lock.md: ########## @@ -0,0 +1,470 @@ +--- +title: S3 Object Lock +summary: Design to support S3 object lock. +date: 2026-08-18 +jira: HDDS-15945 +status: accepted +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). +* FSO Legacy Buckets: Object Lock support for legacy FSO buckets is excluded. +* 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. + +## 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**: + * Get Object + * Get Legal Hold + * Put Legal Hold (Depends on permission) + +**Retention** + +* Definition: Configures a retention policy for an object to prevent deletion or modification. Retention can be duration-based (configured in days or years, establishing a fixed `RetainUntilDate`) or event-driven (**Event Hold / Event-based Retention**, where an object remains protected indefinitely until an external business or legal event triggers the final retention countdown). +* Retention Modes: + * Compliance Mode: The strictest protection tier. Once applied, no user (including root/admin) can remove the lock, shorten the duration, or overwrite the object before the retention period expires. + * Governance Mode: A flexible protection tier. Standard users are restricted by locking rules, but users with `BypassGovernanceRetention` permissions can bypass restrictions to modify or delete the object. +* Event Hold / Event-based Retention: + * Used for records management where the retention lifecycle depends on external events (e.g., contract termination, employee departure, loan closure). + * Keeps the object immutable while awaiting event notification; once the event occurs, the definitive expiration date (`RetainUntilDate`) is calculated and applied. +* Restricted Operations: + * Put Object / Copy Object (Overwrites) + * Delete Object + * Multipart Upload (Initial / Complete) + * Shorten Retention Period (in Compliance Mode) +* Allowed Operations: + * Get Object + * Extend Retention Period + +> _**Note**: +> * Background & Root Cause: A prerequisite for enabling WORM (Write Once, Read Many) in AWS S3 is that Object Versioning must be enabled. Under S3 architecture, executing a Put on a locked object generates a new version without affecting the protected prior version; thus, S3 Object Lock primarily restricts Delete Object. +> * Ozone Implementation Status: Because Ozone's versioning feature is still under development, to guarantee absolute immutability during the lock period, Ozone will directly block and reject all overwrite operations (such as any form of Put or overwrite) on locked objects. + +### Table Changes + +**Bucket Table** + +Two new fields: objectLockEnabled & defaultRetention. + +```protobuf + message BucketInfo { + // ... existing fields + required bool objectLockEnabled = 24 [default = false]; + optional RetentionConfig defaultRetention = 25; + } + + message RetentionConfig { + optional Rule rule = 1; + optional EventHold eventHold = 2; + + } + + message EventHold { + required bool enabled = 1; + required Rule rule = 2; + } + + message Rule { + optional RetentionMode retentionMode = 1; + optional uint64 days = 2; + optional uint64 years = 3; + } + + enum RetentionMode { + GOVERNANCE = 1; + COMPLIANCE = 2; + } +``` + + + +**Key Table** + +Two new fields: retentionConfig & legalHold. + +```protobuf + message KeyInfo { + // ... existing fields + optional RetentionConfig retentionConfig = 23; + optional bool legalHold = 24 [default = false]; + } +``` + + + +### Ranger Access Control + +Ozone Object Lock enforces a dual-gate mechanism combining **Ranger authorization checks** and **underlying WORM state validation**: + +* **Standard Data Operations (Put / Delete)**: Even if a user is granted standard Ranger `WRITE` or `DELETE` permissions, the operation is immediately denied with a `403 Access Denied` (`WORMProtectionException`) if the target object is actively locked by an unexpired retention period or an active Legal Hold. +* **Lock Management and Action Authorization**: Following the Ranger action-matching model introduced via the [STS](ozone-sts.md), Object Lock actions map directly to AWS S3 action names (without the `s3:` prefix). Access control separates underlying Ranger permissions (e.g., `READ`, `WRITE`) from fine-grained compliance actions: + * `GetBucketObjectLockConfiguration` + * `PutBucketObjectLockConfiguration` + * `GetObjectRetention` + * `PutObjectRetention` + * `GetObjectLegalHold` + * `PutObjectLegalHold` + * `BypassGovernanceRetention` + +#### 1. Legal Hold Access Control + +Authorization is decoupled from the payload value being set, aligning strictly with AWS S3 specifications: + +* **`GetObjectLegalHold`**: Allows querying the current Legal Hold status of an object. +* **`PutObjectLegalHold`**: Governs both setting and clearing Legal Hold status (status ON or OFF). Users must be granted the `PutObjectLegalHold` action (along with `WRITE` permission) in Ranger to toggle the hold. + +#### 2. Retention Access Control and Governance Mode Bypass + +For object retention, the interaction with Ranger policies depends on the configured Retention Mode: + +* **Compliance Mode**: Serves as the strictest compliance tier. Until the retention period expires, **no role or Ranger permission can bypass or overwrite the lock**, including cluster administrators. +* **Governance Mode and `BypassGovernanceRetention`**: + * **Mechanism**: Governance Mode allows authorized users to overwrite, delete, or alter the retention duration of a locked object before its expiration date. + * **Authorization Binding**: Evaluated at the **Key level** via the **`BypassGovernanceRetention`** action. + * **Enforcement Flow**: While regular users are strictly blocked from mutating locked objects in Governance Mode, any request attempting to overwrite or delete such objects requires explicit `BypassGovernanceRetention` entitlement in Ranger for that key. Without this permission, even administrators using standard client tools cannot modify or remove the locked object. + +### New Ozone APIs + +**ObjectStore** + +```java + public void addRetentionConfig(OzoneObj obj, RetentionArgs retentionArgs); + public void addLegalHold(OzoneObj obj, bool hold); +``` + +**OzoneBucket** + +```java +public void setRetentionConfig(RetentionArgs retentionArgs); +``` + +### Supported S3 APIs + +To ensure seamless integration with existing S3 clients (e.g., AWS CLI, Boto3) and applications, the Ozone S3 Gateway (S3G) will translate and support the following standard AWS S3 Object Lock APIs: + +**Bucket-Level APIs:** +* `GetBucketObjectLockConfiguration`: Retrieves the Object Lock status and the default retention configuration (if any) for a specified OBS bucket. +* `PutBucketObjectLockConfiguration`: Maps to the new Ozone API to enable Object Lock for an existing bucket. Configuring default retention rules (DefaultRetention) is optional. + +**Object-Level APIs:** +* `PutObjectRetention`: Places a retention configuration on an object, specifying the retention mode (COMPLIANCE or GOVERNANCE) and the `RetainUntilDate`. Review Comment: Thanks @chungen0126 for the detailed design doc! Following up on that [bucket-level retention is represented by days and years](https://github.com/apache/ozone/pull/11053#discussion_r3954617490), I was wondering how object-level retention is persisted. Here `PutObjectRetention` specifies an exact `RetainUntilDate`, while `KeyInfo` stores: ```protobuf optional RetentionConfig retentionConfig = 23; ``` and `RetentionConfig` currently represents retention using `days` and `years`. Is `RetainUntilDate` derived from these fields, or is it stored somewhere else? -- 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]
