Using IBM Cloud Object Storage Object Lock for Immutable Data Retention

Problem: Need guaranteed‑immutable storage for compliance workloads

Many regulated applications must retain logs, medical records, or financial transactions for a fixed period and guarantee that no user—including administrators—can delete or overwrite the data before that period ends. IBM Cloud Object Storage (COS) offers Object Lock, a Write‑Once‑Read‑Many (WORM) feature that enforces retention at the object level.

Thesis

By enabling Object Lock on a bucket and applying retention periods or legal holds via standard S3‑compatible headers, you can achieve immutable storage that meets Governance or Compliance requirements while still using the familiar COS API.

How Object Lock works

Object Lock can be enabled only when a bucket is created. Once enabled, the bucket cannot have the feature disabled; removing Object Lock requires deleting the bucket entirely. Objects stored in such a bucket can be assigned one of two modes:

• Governance mode: Users with the s3:PutObjectRetention permission (or a custom IAM policy that includes object-lock:bypassGovernance) can override or shorten the retention period.
• Compliance mode: No user, not even the root account, can alter or delete the object until the retention date expires.

Retention can be expressed as a duration (days or years) or an absolute date. A legal hold is an independent flag that also blocks deletion; it remains effective even after the retention date passes.

Worked example: Enabling Object Lock, setting retention, and verifying immutability

The following steps illustrate the CLI workflow. Replace placeholders with your own values and ensure you have the IAM policy Authorization Administrator or a custom policy that includes object-storage:bucket:create, object-storage:object:put, object-storage:object:read, and object-storage:object-lock:put.

1. Create a bucket with Object Lock enabled

   ibmcloud cos bucket-create --bucket lock-demo --object-lock --region us-south
   

   Required permission: object-storage:bucket:create with the --object-lock flag.

2. Upload an object with a 30‑day retention in Compliance mode

   ibmcloud cos put-object \
     --bucket lock-demo \
     --key example.pdf \
     --file ./example.pdf \
     --object-lock-mode Compliance \
     --object-lock-retain-until-date 2027-01-15T00:00:00Z
   

   Required permission: object-storage:object:put and object-storage:object-lock:put.

3. Verify the object’s lock metadata

   ibmcloud cos head-object --bucket lock-demo --key example.pdf
   

   Look for headers x-amz-object-lock-mode: Compliance and x-amz-object-lock-retain-until-date: 2027-01-15T00:00:00Z.

4. Attempt to delete the object (should fail)

   ibmcloud cos delete-object --bucket lock-demo --key example.pdf
   

   Expected response: 403 AccessDenied with a message indicating the object is locked.

5. Place a legal hold (optional)

   ibmcloud cos put-object-legal-hold \
     --bucket lock-demo \
     --key example.pdf \
     --status ON
   

   After the legal hold is set, deletion remains blocked even after the retention date passes.

6. Remove the legal hold when no longer needed

   ibmcloud cos put-object-legal-hold \
     --bucket lock-demo \
     --key example.pdf \
     --status OFF
   

Trade‑offs and limitations

• Irreversible bucket setting: Once Object Lock is enabled, the only way to remove it is to delete the bucket and all its contents. Plan bucket lifecycle carefully.
• Cost impact of long retention: Objects locked in Compliance mode cannot be deleted or transitioned to a cheaper storage class until retention expires, potentially increasing storage costs.
• API restrictions: While locked, only GET, HEAD, and (depending on mode) PUT with matching lock headers are allowed. Operations like DELETE, POST, or multipart upload abort return 403 AccessDenied; applications must handle these errors gracefully.
• Region availability: Object Lock is available in all multi‑region and regional COS locations, but verify that your target region supports it before bucket creation.

Actionable closing

If your workload requires immutable storage for compliance, start by creating a test bucket with Object Lock enabled, upload a sample object with a short retention period, and verify the delete‑blocked response. Use the CLI snippets above as a baseline, adapt them to your automation (e.g., Terraform ibmcos_bucket resource with object_lock = true), and monitor bucket metrics to ensure retention periods align with your cost expectations. Remember that the feature cannot be disabled without deleting the bucket, so treat the bucket creation step as a permanent decision.