Requirements for S3 Object Lock
You must review the requirements for enabling the global S3 Object Lock setting, the requirements for creating compliant ILM rules and ILM policies, and the restrictions StorageGRID places on buckets and objects that use S3 Object Lock.
Requirements for using the global S3 Object Lock setting
-
You must enable the global S3 Object Lock setting using the Grid Manager or the Grid Management API before any S3 tenant can create a bucket with S3 Object Lock enabled.
-
Enabling the global S3 Object Lock setting allows all S3 tenant accounts to create buckets with S3 Object Lock enabled.
-
After you enable the global S3 Object Lock setting, you can't disable the setting.
-
You can't enable the global S3 Object Lock unless the default rule in all active ILM policies is compliant (that is, the default rule must comply with the requirements of buckets with S3 Object Lock enabled).
-
When the global S3 Object Lock setting is enabled, you can't create a new ILM policy or activate an existing ILM policy unless the default rule in the policy is compliant. After the global S3 Object Lock setting has been enabled, the ILM rules and ILM policies pages indicate which ILM rules are compliant.
Requirements for compliant ILM rules
If you want to enable the global S3 Object Lock setting, you must ensure that the default rule in all active ILM policies is compliant. A compliant rule satisfies the requirements of both buckets with S3 Object Lock enabled and any existing buckets that have legacy Compliance enabled:
-
It must create at least two replicated object copies or one erasure-coded copy.
-
These copies must exist on Storage Nodes for the entire duration of each line in the placement instructions.
-
Object copies can't be saved in a Cloud Storage Pool.
-
Object copies can't be saved on Archive Nodes.
-
At least one line of the placement instructions must start at day 0, using Ingest time as the reference time.
-
At least one line of the placement instructions must be "forever."
Requirements for ILM policies
When the global S3 Object Lock setting is enabled, active and inactive ILM policies can include both compliant and non-compliant rules.
-
The default rule in an active or inactive ILM policy must be compliant.
-
Non-compliant rules only apply to objects in buckets that don't have S3 Object Lock enabled or that don't have the legacy Compliance feature enabled.
-
Compliant rules can apply to objects in any bucket; S3 Object Lock or legacy Compliance does not need to be enabled for the bucket.
A compliant ILM policy might include these three rules:
-
A compliant rule that creates erasure-coded copies of the objects in a specific bucket with S3 Object Lock enabled. The EC copies are stored on Storage Nodes from day 0 to forever.
-
A non-compliant rule that creates two replicated object copies on Storage Nodes for a year and then moves one object copy to Archive Nodes and stores that copy forever. This rule only applies to buckets that don't have S3 Object Lock or legacy Compliance enabled because it stores only one object copy forever and it uses Archive Nodes.
-
A default, compliant rule that creates two replicated object copies on Storage Nodes from day 0 to forever. This rule applies to any object in any bucket that was not filtered out by the first two rules.
Requirements for buckets with S3 Object Lock enabled
-
If the global S3 Object Lock setting is enabled for the StorageGRID system, you can use the Tenant Manager, the Tenant Management API, or the S3 REST API to create buckets with S3 Object Lock enabled.
-
If you plan to use S3 Object Lock, you must enable S3 Object Lock when you create the bucket. You can't enable S3 Object Lock for an existing bucket.
-
When S3 Object Lock is enabled for a bucket, StorageGRID automatically enables versioning for that bucket. You can't disable S3 Object Lock or suspend versioning for the bucket.
-
Optionally, you can specify a default retention mode and retention period for each bucket using the Tenant Manager, the Tenant Management API, or the S3 REST API. The bucket's default retention settings apply only to new objects added to the bucket that don't have their own retention settings. You can override these default settings by specifying a retention mode and retain-until-date for each object version when it is uploaded.
-
Bucket lifecycle configuration is supported for buckets with S3 Object Lock enabled.
-
CloudMirror replication is not supported for buckets with S3 Object Lock enabled.
Requirements for objects in buckets with S3 Object Lock enabled
-
To protect an object version, you can specify default retention settings for the bucket, or you can specify retention settings for each object version. Object-level retention settings can be specified using the S3 client application or the S3 REST API.
-
Retention settings apply to individual object versions. An object version can have both a retain-until-date and a legal hold setting, one but not the other, or neither. Specifying a retain-until-date or a legal hold setting for an object protects only the version specified in the request. You can create new versions of the object, while the previous version of the object remains locked.
Lifecycle of objects in buckets with S3 Object Lock enabled
Each object that is saved in a bucket with S3 Object Lock enabled goes through these stages:
-
Object ingest
When an object version is added to bucket that has S3 Object Lock enabled, retention settings are applied as follows:
-
If retention settings are specified for the object, the object-level settings are applied. Any default bucket settings are ignored.
-
If no retention settings are specified for the object, the default bucket settings are applied, if they exist.
-
If no retention settings are specified for the object or the bucket, the object is not protected by S3 Object Lock.
If retention settings are applied, both the object and any S3 user-defined metadata are protected.
-
-
Object retention and deletion
Multiple copies of each protected object are stored by StorageGRID for the specified retention period. The exact number and type of object copies and the storage locations are determined by the compliant rules in the active ILM policies. Whether a protected object can be deleted before its retain-until-date is reached depends on its retention mode.
-
If an object is under a legal hold, no one can delete the object, regardless of its retention mode.
-