Scalable compute services.
Simple object storage.
Run managed Kubernetes clusters.
Tools & Integrations
Automate your infrastructure.
Deploy pre-built applications.
Connect, share and learn
DevOps and development guides
Questions & Answers
Development and systems Q&A
by Justin Ellingwood
Let us select which Spaces can be accessed on different API keys. Example: A key can only access a single Space.
This would be really important for me too.
I need to use different spaces for different clients and they must not be able to view/change anything in a space which is not one of theirs.
I really think that this feature is essential for the spaces product, many use cases cannot provide proper privacy/security without it!
Is there any status update on this idea/feature request? Is this something that is on the roadmap or may possibly be in the future?
In our case we are storing terraform state in a space, alongside a different space for a private docker registry. We also have a public space for static files for a platform we're building. We generated 3 different keys ( 1 for each section ) but just thinking of the fact that the public spaces key has access to our terraform backend makes me cringe :/. Definitely would be a sweet improvement :)
In a one-bucket:one-website scenario (eventually running for different companies), there is no reason that any website could mess with other website's buckets...
The way works API key is really surprising...
This is a show stopper.
I recently created a Support Ticket (#1670481) stating the following:
>Right now, when we generate SAKs, there's no way to limit access to different Spaces (Eg: One SAK for One Space, Another SAK for Another Space.).
>How can this be achieved?
To which I was prompted to share my voice here.
I am glad that there are other who share the same need.
I think this is a critical requirement, and the lack of this is a potential security issue.
I would be glad if this could be implemented ASAP.
Graham Wheeler said it best, having multiple sites with their own spaces shouldn't give them the ability to access each other's files.
What if the key and secret are somehow compromised? Not only do you have to generate a new pair, but data in ALL spaces can now be considered compromised. As soon as the 1-1 ability is possible, I'd be able to start using spaces for my customers.
I agree this is a much-needed requirement for a lot of us out there. A single key having access to *all* spaces on the account? That is a security concern and why I haven't started using spaces for my various projects.
It should be possible to generate an access key that has read/write or read-only access to a particular bucket/space. If I have a spaces account and multiple websites, each with its own space, they shouldn't be able to potentially read and write each other's files.
Read-Only Access Keys for files or spaces please!
The Read-only key for private files is a must! How else can you control what a system might do to the data?
We want to limit our attack surface, and would like to create several Spaces for different systems we use. System A should not be able to access information of System B; they should both get their own Space.
Why this should be a priority? Maximize Revenue for DO
I would create at least 3 seperate spaces if I was able to limit an API key to a specific Space;
This would mean we'd be throwing $15 to DO instead of $5 per month at a minimum.
Because we cannot limit an API Key to a Space at the moment we just have one Space with three virtual folders:
product : /production
product : /staging
product : /test
The benefit for DO: more revenue because of more Spaces
The benefit for Customers: being able to reduce the attack surface
We need this too!
I agree, I also need this level of control
We need this too.
DO did suggest creating teams to accomplish this but it would be nice to have something closer to S3.
Yes we need this ability to allow a single client to manage files in their own bucket / space.
This is a must. Also a key where we can give just *read only* access to a single/all spaces.
read only private keys please!
Massive +1 - this is the only thing holding me back from ditching AWS
Yes please +1
This is a must have for us.
For people that need this feature now. Take a look at https://www.minio.io/.
It can act as a gateway for digitalocean spaces in the meantime. I have used minio for some time. It works really well. It looks to be working with spaces aswell!
Please we need this done, its very important for enterprise customers
Create Two types of tokens:
Totally agree, should not be too complicated to add a bucket-specific key? Now you could create another project but if you want to combine a Kubernetes cluster with multiple apps with spaces you really need to seperate one bucket from another.
Agreed with others... need a way to isolate API access.
Different API access based on a "Project" is a good solution for me.
What about this topic? When can we expect a solution here?
Its really important that we have this, especially when managing a lot of projects. At the moment the projects arent that useful other than just for categorizing. Invoicing should be based on project as well as access per project. THIS IS A MUST
Even if you can't offer a more granular permissions system (ie. read only keys, keys that can only access particular folders, etc.), the ability to isolate API keys to a specific Space is absolutely fundamental.
Will keep using S3 for primary storage needs until this glaring oversight is addressed.
I really need this as well. I will have to move on to S3 otherwise, but I like the ease of use with DO, so it would be fantastic to see the feature here!
This is a major oversight, and as others have said, a blocker for using this in production.
This seems about the silliest design concept. Why would any key be able to access any space? A DO account can have tons of different groups and servers for different things. But when it comes to spaces it seems if one gets access we all get access?
Please dear god. Implement this. S3 is expensive and DO has a gaping large security vulnerability.
Totally dead breaker not having this for sooo many ppl.
Please, please, please DO, we beg you, prioritize this pleaaasee!!!
+1, this, etc, etc...
This really should have been a Day 1 feature, considering Amazon's offerings. I do trust DO security, but if one little thing goes wrong than all spaces across multiple projects become compromised, which i find disturbing.
The ability to isolate API keys to a specific Space (bucket isolation in cloud lingo) is absolutely fundamental.
Please DO, we need this, and personally - I'm prepared to pay extra for this feature.
Guys, it's a little worrysome one key can access all of our data. Is there a workaround?
How is this not done after > 1 year? So obviously necessary.
A Space doesn't seem to be all that versatile when you have a dedicated photo upload key, but that same key has access to all private backups of hundreds of other sites in a bucket that should be separate.
What is the reason for having more than one bucket if all are exposed to all keys?
Being able to restrict API keys to a subset of buckets is crucial for us to segment which site can affect which buckets. As is, we've decided to use Spaces for our main site and come up with terrible, hacked-together solutions for the less important sites. With restrict-able keys, even if the restriction is only possible at the bucket level, we'd be able to simplify our codebase and worry less about headaches from these hacked solutions. In the future, we may move to Amazon S3/CloudFront until this feature becomes available natively with DigitalOcean just to simplify our workload
It doesn't make sense that different projects share the same credentials... Please fix this.
It has been 14 months since this was first suggested. Where does this stand? I think as a customer and others have commented we need to come up with an alternative solution if one isn't on the horizon?
This feature, which honestly should have been implemented from day one, is preventing our team from utilizing spaces for more than the small amount we do now. We alone would be paying hundreds of dollars more a month if we could simply create space specific API keys with basic read/write permission options. I'm sure many other companies are in the same boat. It's beyond me that this hadn't gotten a single response from DO as it's such a fundamental and basic part of any data storage system...
PLEASE CONSIDER IMPLEMENTING EVEN THE MOST BASIC OF PERMISSIONS SYSTEMS!
Otherwise spaces are great. The price is right, it's compatible with standard S3 management tools, and the auto-CDN feature is great...buuut we absolutely can't use it for anything more than public files. The only time I ever dare use an API key is one off uploads from our build server that I perform manually. I'm afraid to continue to use Spaces at all once we switch to an automated build system as I don't want to have an all access key sitting around anywhere...
+1 on this feature request.
Without keys per bucket, we can't possibly host buckets that are visible without any user/key controls.
Please implement the bucket level access feature.
Agree, very need this feature..
Unbeblievable that this is still not implemented. Unfortunately this is also a dealbraker for us. Not possible to migrate several different customer projects to DO without this feature.
We need to separate different projects / customers!
It boggles my mind that the only way to compartmentalize access is creating whole new sets of teams and spinning up and managing what amounts a venn diagram of unique individual spaces.
It is really important. So far we have to create separate accounts for spaces
No reason to have multiple buckets and multiple keys if an key can access any bucket
Isolating key access to specific spaces is essential - spaces is unusable in the real world without it.
read only keys would also be nice
How is this feature going?
You won't be notified about changes to this idea.