You can set soft and hard quotas on a namespace and on buckets created within a namespace.
Soft quotas cause events to be logged to inform you that the quota has been reached; hard quotas provide a hard limit on the amount of object storage that can be used for a bucket or namespace - when the limit is reached, access to the bucket or namespace is blocked.
Quotas can be set from the ECS Portal or using the API and the CLI.
ECS provides the ability to prevent data being modified within a specified retention period.
Retention periods can be defined in metadata associated with objects and buckets and is checked each time a request to modify an object is made. Retention periods are supported on all object interfaces S3, Swift, Atmos, and CAS. However, CAS data is immutable so the retention period when applied to CAS refers to the ability to delete CAS objects.
While the retention period for a bucket can be set at the ECS Portal, the assignment of a retention period, or policy, to an object must be performed using the object interface.
There are two ways of defining retention: retention periods and retention policies.
Retention periods are assigned at the object or bucket level. Where a retention period is assigned on a bucket, each time an attempt is made to modify an object within a bucket, the retention period for the bucket is checked and an expiration time calculated.
For example, where a financial document must be retained for 3 years from the date on which it is created. It is also possible to specify that the object is retained indefinitely.
Retention policies enable retention use cases to be captured and applied to objects. For example, different types of documents could have different retention periods. You could require the following retention periods:
Financial - 3 years
Legal - 5 years
Email - 6 months
Where a retention policy is applied to a number of objects, by changing the policy, the retention period for all objects to which the policy has been applied can be changed.
How to create retention policies
You can configure the retention policies that are available for the namespace from the
ECS Portal, refer to:
You can apply retention periods to buckets at the ECS Portal.
When you create objects or buckets using the object service protocols, for example, when you create an S3 bucket using a client that supports the S3 protocol, you can apply the retention period or retention policy using x-ems headers.
When you create objects, you can apply the following retention period and retention policy headers:
When you create a bucket, you can set the retention period using the x-emc-retention-period header.
ECS provides support for metering the use of the object storage at the namespace and bucket level.
Metering using the portal
You can use the
ECS Portal to monitor the use of namespace and buckets. The
Monitor > Metering page enables a namespace or a specific bucket from a namespace to be selected and its metering data displayed.
Metering data is not available immediately as it can take a significant amount of time to gather the statistics for data added to the system and deleted from the system.
The controller API provides the ability to audit the use of the S3, EMC Atmos, and OpenStack Swift object interfaces.
The following operations on object containers (S3 buckets, EMC Atmos subtenants, and OpenStack Swift containers) are logged.
Set Bucket ACL
Change Bucket Owner
Set Bucket Versioning
Set Bucket Versioning Source
Set Bucket Metadata
Set Bucket Head Metadata
Set Bucket Expiration Policy
Delete Bucket Expiration Policy
Set Bucket Cors Configuration
Delete Bucket Cors Configuration
Audit logging at the portal
You can use the
Monitor > Events page to detect the generation of an audit log event.
The root user should only be used for initial access to the system. On initial access, the root user password should be changed at the
Settings > Password page and one or more new System Admin accounts should be created. From an audit perspective, it is important to know which user carried out changes to the system, so root should not be used, and each System Admin user should have their own account.