S3 compatible services carry many of the same concerns as the original S3 service. This article highlights which assumptions break and what risks remain.
The way AWS S3 works has become the de facto standard for object storage in many cloud environments outside of AWS. It can be surprising to use a non-AWS cloud platform and still be asked to use the AWS CLI or another S3 tool in order to upload and download files in that environment by using API endpoints that are not AWS S3. It makes sense though for these new object storage offerings to avoid having customers learn a new tool, or build around a new set of APIs or concepts.
Some of the clouds out there with S3 compatible services include Nebius, Crusoe, Vultr, Lambda Labs, Cloudflare, DigitalOcean, and more. The S3 clones support only a small subset of the features, and some of these features work differently, but they still include a few of the same security concerns. This article will look at these S3 compatible services and highlights which assumptions break and what risks are still there.
Using the S3 clones
An example of how these S3 compatible object storage services work can be shown with Nebius:
aws configure set aws_access_key_id NAKIQPR18JKX14MVBWJRaws configure set aws_secret_access_key +RlLyp6paR/A08mpyB-REDACTEDaws configure set region eu-north1aws configure set endpoint_url https://storage.eu-north1.nebius.cloudaws s3 ls
Notice that the access key begins with a Nebius defined prefix of "NAKI" instead of the AWS prefixes "AKIA" or "ASIA". Also notice that the AWS CLI is being configured to use a Nebius URL instead of the usual AWS endpoints. These same concepts are used across the S3 clones: The cloud service vends out a custom access key and secret key and has its own API endpoint.
There are nearly 300 APIs associated with AWS S3 and its related services (such as S3 tables, S3 vectors, S3 express, and more). All sorts of specialized functionality has been added to S3 over the more than 20 years of its existence, with trillions of objects and hundreds of exabytes of data stored within it. As you should expect, not all of that functionality has been replicated, and some of these S3 clones work in unexpected ways. On one S3 clone, for example, the command aws s3api get-bucket-policy returned the contents of the ListBucket API instead, but weirdly formatted to fit in a response that looked like what the GetBucketPolicy command would return. Then when I called delete-bucket-policy out of curiosity, that deleted the bucket instead of any policy.
Public buckets
Let's get to the first question everyone has about anything similar to S3: Can it be publicly exposed? Public S3 buckets have been one of the biggest sources of security incidents on AWS, and as a result AWS has done many things to prevent these from continuing to occur, such as default enforcement of S3 Block Public Access for all new buckets. Luckily, some of the S3 clones don't even have a way to make their buckets public or shareable.
Of the S3 clones that do have a public bucket capability, they tend not to provide functionality to list the contents of the buckets, so someone would need to know or guess the name of the objects in addition to the bucket itself. Guessing the names of the buckets is made more difficult by some providers by only allowing creating buckets with random names.
Let's look at the S3 clones that can be made public. In this post I will refer to these S3 compatible object storage resources as "buckets" and the service as an "S3 clone" to avoid the longer terms or the cloud specific names.
Nebius buckets can be made public, but only through the Nebius API. This cannot be done with the web interface or the S3 compatible API they provide. As Nebius does not use the S3 API for this, the policies it uses look nothing like AWS S3 policies. The example policy from the Nebius docs is supposed to allow listing objects, but I was not able to find a way to view a list of the objects anonymously. I could only retrieve objects that I knew the names of.
Vultr implements both ACLs and bucket policies, which can each make buckets public as they do on AWS. To use Vultr buckets, you first create an "object storage" project. Each of these projects can contain a collection of S3 buckets, and additionally has an associated access key and secret key for interacting with the S3 compatible API. The API to list the object storages returns the access key and secret key for each of these projects which can be called at any time, which is a departure from AWS principles of only showing credentials at creation time. In order to determine what S3 buckets you have, and any information about them, you would list the object storages, and then use the returned access key and secret key to query the S3 compatible API service.
Lambda Labs does not appear to support public buckets, but it does something odd. This S3 compatible service supports the get-bucket-acl API, and the default ACL associated with its buckets includes the ACL grant that would make them public! However, I am not able to access the S3 bucket anonymously.
Cloudflare's R2 service allows for public buckets which is done via the Cloudflare API. Cloudflare interestingly does implement the S3 GetBucketAcl API (despite the docs saying otherwise), but not the PutBucketACL API or bucket policy APIs. When a bucket is public, it still does not allow public listing of the objects. The buckets are accessible through a domain that contains a per-customer random prefix subdomain, making them more difficult to find even if they are public.
DigitalOcean allows for public buckets through the S3 API PutBucketAcl. These buckets are publicly listable, but the individual objects must be given public read ACLs as well.
Service provider
Allows making buckets public?
Nebius
Yes, via Nebius API
Crusoe
No
Vultr
Yes, via S3 ACLs and policies
Lambda Labs
No
Cloudflare
Yes, via Cloudflare API
DigitalOcean
Yes, via S3 ACLs
Access keys
AWS access keys are incredibly useful, but also have a lot of risks associated with them due to their usefulness. One common cause of security incidents for cloud environments has been access keys (and their associated secret keys) being saved in source code and that source code ending up in a public repo. This is a common enough problem that there is even a quarantine process that is triggered when this happens on GitHub for AWS keys. However, these S3 clones do not have a similar process. There are other credentials detected by GitHub for DigitalOcean and Cloudflare through GitHub's secret scanning process, but not these.
These credentials for the S3 compatible services are also not commonly found by other secret scanners. Part of the reason is that some of these do not have patterns that can be used for this detection. Structured keys are generally viewed as a best practice (ex. this article from GitHub) where you have a prefix to help search for and identify secrets like this. Keys without a clear pattern may escape searches by attackers, but will also escape searches by security teams. The following table shows the regex patterns for the access keys and secret keys of the different S3 clones.
Service provider
Access key pattern
Secret key pattern
Nebius
NAKI[A-Z0-9]{16}Example: NAKIWYI775RP7BH43PKT
[A-Za-z0-9+/]{40}
Crusoe
CKIA[A-Z0-9]{16}
[A-Za-z0-9+/]{40}
Vultr
No prefix. Just [A-Z0-9]{20}
[A-Za-z0-9+/]{40}
Lambda Labs
No prefix. Just [A-Z0-9]{20}
[A-Za-z0-9+/]{40}
Cloudflare
No prefix, and not a normal S3 length.
[a-f0-9]{32}
[a-f0-9]{64}
DigitalOcean
DO[A-Z0-9]{18}
[A-Za-z0-9+/]{43}
(note the abnormal length)
Least privilege
AWS access keys can mitigate the risks of being publicly exposed through a variety of IAM policy mechanisms, such as limiting the actions they allow to only GetObject or restricting usage to specific IP addresses or VPC endpoints. The access keys of the S3 clones do not have these same mitigation mechanisms. These services have much less featureful privilege capabilities and are less fine-grained.
Cloudflare does allow you to create keys that can only list and read objects in a specific bucket and allows IP allow-listing and deny-listing. DigitalOcean can create keys that are read-only for specific buckets. Nebius has minimal features for its bucket policies, but still allows read-only capabilities. Vultr, Crusoe, and Lambda Labs do not have least privilege capabilities for their access keys.
Bucket squatting
The S3 clones have their own global namespaces. It's fun being able to create a bucket with simple names such as "example" on one of these clones and have it actually work. You have to be mindful though that other users could create buckets that follow patterns used by your tools (such as region based naming schemes), which could potentially result in you reading or writing data to buckets you assume you created, but are actually owned by an attacker. This threat is known as bucket namesquatting.
Presigned URLs
AWS S3 buckets can be accessed using URLs that contain the necessary authentication in what is known as a presigned URL. These can be useful in web applications to allow browsers to easily download or upload objects stored in S3, among other uses. However, this feature has security implications that need to be considered by application developers when they use it. For example, the URLs can be valid for up to 7 days on AWS and can be reused by anyone that gets access to them because they contain all of the necessary authentication information. This can have unexpected implications if these are logged somewhere, including when that logging is done by the clients (such as browser extensions that record the URLs visited).
S3 presigned URLs are a capability that results from how the S3 API works, so the S3 clones automatically all have this ability. Some of the S3 clones call this out in their documentation (ex. Crusoe), but some do not have any mentions of them.
As an example, here is what it looks like to generate a presigned URL for Nebius credentials that were mentioned earlier that can be accessed from a web browser:
All S3 objects uploaded to AWS since 2023 are automatically encrypted at rest. This prevents the risk that someone could break into a datacenter, steal the hard drives, and be able to read valuable data. Customers of the major CSPs may implicitly expect this mitigation. Of the S3 clones we looked at, all except one explicitly stated that they perform encryption at rest with at least AES-256. For that one exception we could not find any documentation about what encryption at rest they perform (if any).
AWS S3 also enforces TLS 1.2 or better for encryption in transit, but again the S3 clones may not enforce that. Cloudflare, for example, supports TLS 1.0 by default for its object storage.
Logs
AWS S3 has a concept of control plane and data plane logs. The control plane logs record the generally uncommon actions of creating and deleting the buckets, while the data plane logs record the much more frequent events of creating, reading, and deleting objects within the buckets (PutObject and GetObject calls). On AWS, the data plane logs are off by default because they produce a much greater volume of events and thus cost money. These data plane logs can be enabled for specific buckets, and have a number of filtering capabilities if only specific events are of interest.
Service provider
Data plane logs?
Nebius
Yes
Crusoe
No
Vultr
No
Lambda Labs
No (and no control plane events for object storage)
Cloudflare
No
DigitalOcean
Yes
Conclusion
AWS S3 is a powerful service, and as a result it has a number of security considerations. Any clone of that service is therefore going to have some of the same concerns, and also some new ones due to differences in the clone from the real AWS S3. When using services that are similar to what you're used to, it's important to not only apply the same knowledge of concerns, but also look for new ones or where your assumptions don't hold true.