Spaces Object Storage is an S3-compatible object storage service. Spaces buckets let you store and serve large amounts of data, and the built-in CDN minimizes page load times and improves performance.
Many Spaces settings are done via the command line. Please refer to the Spaces documentation for more information.
Spaces owners can create, destroy, and read all content in all the Spaces buckets for an account. They also make decisions and manage what everyone else can see. If an owner wants to allow one or more people to co-manage buckets, there are two options: Access Keys and DigitalOcean Teams.
Users who connect with access keys can create, destroy, read, and write to all of the buckets for the account. However, the privileges granted by Spaces access keys do not provide access to the control panel and do not extend to other DigitalOcean resources.
Teams allow members to use the control panel, including creating, managing, and destroying buckets associated with the Team account.Team members can also create, delete, and regenerate access keys for buckets.
Unlike Spaces access keys, members of a Team can also access other Team resources like Droplets, Firewalls, and more.
Managing access to your DigitalOcean Spaces Object Storage is important for:
Misconfigured permissions can either expose sensitive data or lock users out of the data they need to perform their jobs. Frequent changes in team structures or project scopes can exacerbate these risks as updates to access controls may not keep pace.
File listings are restricted by default.
Back to Security Best Practices Guides Intro
DigitalOcean Spaces Object Storage uses access and secret keys to control and manage access to data. Access and secret keys are used for authentication and authorization when accessing the Spaces service.
The access key is a public identifier for your account. It is used to identify the user making the request to a Spaces bucket. The secret key is a private key associated with your access key. It should be kept confidential and secure. This key is used in conjunction with the access key to sign requests to the Spaces API, ensuring that the request is authorized.
There are two scope options for access keys:
Creating access and secret keys is important for the following reasons:
While creating access and secret keys are considered a best Security practice, there are considerations to remain abreast of. For instance, if access keys are hard-coded into applications or stored insecurely, they can be exposed through source code repositories, configuration files, or logs, which increases the risk of unauthorized access. In addition, rotating or revoking keys without proper planning can lead to service disruptions. Furthermore, applications or users relying on the old keys might lose access until updated keys are deployed.
Below, please find guidance on how to create and edit Spaces Access Keys
For more information on creating and managing access to Access Keys, please visit our How to Manage Access Keys documentation.
Back to Security Best Practices Guides Intro
A lifecycle configuration rule is a policy or rule set to manage the lifecycle of objects in a storage bucket. These rules automate the process of transitioning objects through different storage classes or deleting them after they are no longer needed. The objective is to optimize costs and manage data efficiently without manual intervention.
There are several cross-platform command-line tools available to tools for managing S3 and S3-compatible stores, but this example offers guidance on s3cmd. For more information on S3, including local installation instructions, refer to DigitalOcean’s Setting Up s3cmd 2.x with DigitalOcean Spaces reference.
Creating a lifecycle configuration rule is important for the following reasons:
A significant risk associated with lifecycle configuration rules is unintended data loss. For example, if the expiration period is set too short, data might be deleted before its utility has expired. Another potential risk is not aligning lifecycle rules with compliance and security policies as that presents the risk of violating legal or regulatory requirements.
A lifecycle rule that deletes a large amount of objects can take hours or days to finish running. During this process, you are still billed for any objects that have not been deleted yet. To delete objects faster, use the S3 DeleteObject or DeleteObjects commands:
- s3cmd ls
- s3cmd getlifecycle s3://selected-space
- ERROR: S3 error: 404 (NoSuchLifecycleConfiguration)
Lifecycle rules can be used to perform different actions on objects in a Spaces bucket over the course of their “life.” For example, a Spaces bucket may be configured so that objects in it expire and are automatically deleted after a certain length of time. Lifecycle rules based on tagging are not supported.
Before creating lifecycle rules, set up s3cmd 2.x with DigitalOcean Spaces. After setting up s3cmd, follow the How to Configure Lifecycle Rules guide.
Back to Security Best Practices Guides Intro
A Spaces bucket’s file listing is a list of the bucket’s contents in XML. It displays the names (called keys) of every file in the bucket as well as other file information, like the file sizes and last modified dates.
Owners of a bucket set the visibility permissions of this file listing, which can be:
You can set the visibility of the file listing when creating a bucket. On existing buckets, you can view and edit the permissions on the bucket’s Settings tab. The bucket’s Settings tab can be found by selecting the individual bucket from the Spaces Access Keys landing page.
Setting the file listing permission is important for several reasons, including:
Setting the file listing to “Public” exposes individual files you may want to keep private. To keep files private, store them in a private bucket.
For more information, please review our How to Set File Listing Permissions documentation.
The permission to list the contents of a DigitalOcean Spaces bucket is Private by default.
Back to Security Best Practices Guides Intro
Spaces provides a built-in content delivery network (CDN), which is a network of edge servers that deliver content to users. Each point of presence (PoP), the location of a group of edge servers, sends content to the users that are physically closest to it. CDNs help deliver static and dynamic online content faster and more reliably, and provides a layer of redundancy for websites.
Enabling the Spaces CDN is important for several reasons, including:
We do not recommend or support using multiple CDNs from separate vendors with your Spaces buckets (such as the Spaces built-in CDN and another vendor’s CDN), as it can cause performance issues and be complex to manage.
The Spaces CDN can be enabled during bucket creation by identifying the CDN (Content Delivery Network) section on the Spaces create page.
Click Enable CDN. An Edge Cache TTL drop-down menu will appear. This setting determines the amount of time that the content is cached. You can keep the default of 1 hour or choose another value. You can also customize the CDN endpoint with a secure subdomain you own.
Finish choosing the rest of the settings for the bucket, then click Create a Space. Once the bucket is created, you can modify the edge cache TTL setting and custom subdomain at any time on the bucket’s Settings page.
The Spaces CDN can also be enabled for an existing bucket. From the Control Panel, navigate to the bucket’s detail page by selecting Spaces Object Storage and subsequently, selecting the name of the bucket. From there, click the Settings tab. The text in the CDN (Content Delivery Network) section will tell you if the CDN is currently Enabled or Disabled for the bucket.
To enable the CDN, in the same CDN (Content Delivery Network) section, click Edit. In the options that open, click Enable CDN. When you do, several options for the CDN will appear.
You can customize the CDN endpoint with a secure subdomain you own using the Use a custom subdomain menu. The Edge Cache TTL determines the amount of time that the content is cached. You can keep the default of 1 hour or choose another value.
When you’re done choosing options, click Save. Once the CDN is enabled, you can return to this page to modify the edge cache TTL setting and custom subdomain.
Back to Security Best Practices Guides Intro
Client web applications loaded in one domain can interact with resources in a Spaces bucket with Cross-Origin Resource Sharing (CORS) configured.
Configuring CORS for a Spaces bucket is important for several reasons, including:
Overly permissive CORS can expose your data to unauthorized applications.
You can configure CORS via the control panel by navigating to the designated bucket’s Settings page. In the CORS Configuration row, click Add.
This opens the following Advanced CORS Options window:
Within the Advanced CORS Options window, the following can be completed:
Origin: Specifies the complete domain of the client you want to access your bucket’s resources. The domain should start with a protocol identifier, such as http, end with a hostname or hostname and port, and optionally include a wildcard character (*) at the start of the hostname. For example, https://*.example.com. All other settings are only applied to requests from this Origin.
Allowed Methods: Determines which API methods can interact with your bucket. You can allow or prohibit the following methods:
Allowed Headers: Determines which non-default headers are accepted in your bucket. To verify that an incoming HTTP request abides by your CORS settings, your bucket checks the request’s list of headers. Each header describes a property of the request. For example, Content-Length and Content-Type are some of the default headers that CORS automatically accepts. However, if your client sends any non-default headers, you must first add them in your CORS configuration.
Access Control Max Age: Determines how long a request’s verification is cached, in seconds. While verification is cached, the bucket can accept more requests from the same origin without needing to be verified, which improves performance. The recommended value is 5 seconds. Lower values may be useful during development, and higher values may be useful if a single browser is issuing many requests at once. Some browsers may also limit this value to as high as 10 minutes.
CORS configurations unavailable via the control panel, such as ExposeHeaders, can be implemented by uploading a configuration XML file via s3cmd. Please visit this tutorial for more information about setting up s3cmd.
For more information on configuring CORS, please review our How to Configure CORS on DigitalOcean Spaces documentation.
Back to Security Best Practices Guides Intro
Destroying a Spaces bucket permanently and irrecoverably destroys the bucket and all of its objects. When you confirm the destruction of your last bucket, your Spaces subscription ends automatically and you are no longer charged.
Spaces buckets can be destroyed by selecting the designated buckets name on the Spaces page to go to its detail page. From there, select the Settings tab and identify the Delete this Spaces Bucket row. Select Delete to open the Spaces Destruction configuration window. Enter the name of the bucket and click Destroy to confirm destruction. As a best practice, ensure all data is backed up, as appropriate, before deletion.
Destroying a Spaces bucket is important for several reasons, including:
In the event buckets targeted for destruction no longer need to be destroyed, not cancelling bucket destruction before its destruction time leads to permanent data loss.
For more information on destroying a Spaces bucket, please review our How to Destroy Spaces documentation.
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.