In today’s business world many companies face the necessity to store their important data on S3 storage and share it with only those who need it. This raises many questions on how to secure the data and restrict access to it so that it is not accessed by unauthorized third parties.
With VMware Cloud Director Object Storage Extension, these important questions are addressed. It helps providers and tenant administrators to manage the availability and security of the stored data, and pinpoint who will be authorized to access it. Object Storage Extension solves the security challenges that come with data access and sharing by providing multiple solutions for both data protection and user access.
Data in S3 storage is kept in S3 buckets, which require protection to prevent illicit access and loss of data. With Object Storage Extension, important data is protected by:
- Encryption – Applied on tenant or bucket level.
- Object Lock – Preventing the objects of a bucket to be either deleted or modified.
- Versioning – Keeping all versions of S3 objects in a bucket.
The other important aspect of keeping important data on S3 storage is user access. With user access, you as a tenant administrator can use the following tools to strictly apply user access control on the data in your tenant org buckets.
- Cross-Origin Resource Sharing (CORS) – Helps tenants access the tenant org data outside the org domain. Enabled by either provider or tenant administrator.
- Access Control List (ACL) – Used to pinpoint which user roles can do read, write, and delete operations on the S3 bucket data.
- Security Credentials – S3 storage has the powerful option to provide users with a pair of security credentials that strengthens authentication with the S3 storage. This option is available also through Object Storage Extension and helps you create new pair of security credentials, rotate existing ones or delete them.
- Subordinate Roles – On top of VMware Cloud Director (VCD) user roles, Object Storage Extension offers an additional set of user roles that are specific to working with S3 storage. These roles define explicitly what the users of the tenant org can do with the S3 storage objects.
The encryption through Object Storage Extension happens on a tenant and bucket level. By default, encryption is not enabled. To change that, you need to enable the encryption as a provider administrator for a specific tenant or change the encryption for a bucket as a tenant administrator.
These are the encryption methods available:
- None – Data is not encrypted. This option saves on performance but can introduce security risks.
- SSE-S3 – Uses AES-256 algorithm for data encryption and S3 server-managed primary keys.
- SSE-C – Data encryption is applied based on encryption algorithms and primary keys provided by the customer.
This feature protects from the deletion of S3 storage objects. It is enabled on a bucket level. It can be either enabled during the creation of a bucket or later. With the object lock set up, you need to specify a retention mode that specifies the retention period and who will be able to stop it before it expires. Object lock is tight with versioning and protected the versions of objects from deletion for a specific period.
Objects of a bucket can be modified or accidentally deleted. To keep track of the changes made with S3 objects or restore from deletion an S3 object, versioning needs to be enabled. File versioning keeps the latest saved changes in a separate file. It scans the file for changes in the body and checks if other metadata attributes are the same as the file currently uploaded. If a file with similar content but with a different name is uploaded, then this file will be considered new, and it will be separately shown in the bucket.
Versioning can be applied by all tenant users.
In the following example, we have uploaded a file, and later uploaded it again but this time with changes. In this case, the object storage extension will show only the latest version of the file but will keep the previous ones as well. In this example, the original file version appears at the bottom of the list (next to the file name), while the latest version is labeled with (Current Version).
Amazon S3 Bucket Policies can be applied to the content of a selected bucket. These policies fine-grain who can access the content of an S3 bucket and what operations they can do. The principals of the S3 bucket policy could be either AWS users or policies.
Cross-Origin Resource Sharing (CORS)
The CORS policy allows access to tenant org S3 object buckets outside the org domain. There are several options to configure this access:
As a provider administrator, you can enable CORS globally for the tenant org. Global CORS allows cross-origin requests to visit S3 API in virtual hosting style by the origin allow list. The following options can be applied:
- Deactivate global CORS – When the global CORS is deactivated, the bucket access from outside the org domain is made based on the bucket CORS rules.
- Activate global CORS with any origin – Allows access from all cross origins to all tenant buckets.
- Activate global CORS with custom origin allow list – When set, specific cross-origin access to tenant buckets is allowed but access from other origins is made based on the bucket CORS rules.
As a tenant administrator, you can apply CORS on a bucket level. You can specify for a particular tenant org bucket whether it can be accessed from different domains outside the tenant org domain or not, and what the properties of the API calls should be. The bucket level CORS would come into effect if the global CORS managed by the provider administrator, has been selected to consider the bucket CORS rules.
Access Control List (ACL)
The Access Control List (ACL) of a bucket can be changed by either the tenant storage administrator or the tenant storage user. ACL helps tenant storage administrators and users share the content of a particular bucket with other users (part or outside the organization) and allows them to perform read and write operations.
Every tenant storage administrator and tenant storage user has access and a security key that can be used to access the content of their buckets. The access and security key of a user can be used to access the content of a bucket, for example, from an S3 third-party client application. The API endpoint of a bucket that needs to be specified when accessing the bucket from outside OSE, is specified on the same page as the security credentials of the user.
Security credentials can be rotated to strengthen secure access to the bucket content.
OSE has three main application user roles – Provider Storage Administrator, Tenant Storage Administrator, and Tenant Storage User. These roles are mapped to Cloud Director user roles that have the following rights.
OSE also has subordinate roles, in addition to the application user. The OSE subordinate roles define what tenant storage users can do with vApps, Catalogs, and guest Kubernetes clusters in OSE.
The tenant storage administrator by default has all these subordinate roles enabled but a tenant user has none of them. To enable them to use OSE features, apply any of the following subordinate roles.
- vApp Contributor – Captures and restores vApps.
- Catalog Contributor – Creates, publishes, and imports catalogs.
- Kubernetes Contributor – Backups and restores guest Kubernetes clusters.
Object Storage Extension employs the classic S3 API and thus provides a myriad of options for securing access to S3 bucket content. Organizations with complex structures and models of work can greatly benefit from using Object Storage Extension capabilities for managing user access to the S3 buckets part of the organization. Authorized users can access the content of a bucket outside the organization in a highly secure way.