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.
Yet another web developer with multiple clients and websites going elsewhere because of this severely lacking feature.
If anyone from Digital Ocean is listening, you might want to do some analysis on how much money you're losing by not implementing this. Especially as it hits the power users the hardest.
Not holding out too much hope though since only 1 idea has been "shipped" in the last year and the copyright notice is stuck on 2018.
Did the staff just up and leave a couple of years ago or something?
This is a must for any serious organization using Spaces. Please add support.
Any update on this?
This is really a blocker
In case it helps anyone, I ended up going with Backblaze B2. They reputable, have the cheapest prices on the market, have an S3 compatible API (like DO), and they have per-space/bucket permissions! I honestly would have preferred to stick within the DO ecosystem even if it is 4x more expensive (since I don't need to store a lot of data anyway), but without this very basic feature, it's impossible for my use case. https://www.backblaze.com/b2/cloud-storage-pricing.html
Right now I need to create an intermediary service just to handle authorization to buckets and use presigned URLs. It would be a lot easier if I could just give the users rights to their specific buckets without needing a server in the middle.
I finally sat down to start migrating from S3 to DO Spaces, and quickly found out that every API key gives access to every Space.
It boggles my mind that there is no way to restrict an API key to a specific Space.
Until this is implemented, there is absolutely no way I can use Spaces.
This is more or a less a must have. Signed up for Spaces and started some experiments when I soon realised that an IAM-like system wasn't possible. Dropped Spaces immediately. Will revisit if this is implemented though.
Very basic feature, please implement that!
This an absolute must. Please. Has anything been said or done on this request?
Current naive security model is useable only for hobby projects. Not useable for anything serious.
Same with others DO APIs - you want one service to be able to update its domain records, you give it access to everything on your account.
As long as DO does not deliver, I've built a workaround for people willing to host their own solution to this problem: https://github.com/djmaze/s3-auth-proxy
It's kind of ridiculous that this isn't a thing. What's the point of having different buckets if you can't control them individually? My enthusiasm for Spaces is shrinking by the day. No static site hosting (announced years ago), no API bandwidth monitoring, and now I learn that access cannot be limited to one specific space. Next thing I find out I can have only one database passwords that grant you access to all the databases on my account.
This is super critical
We are another company that would use Spaces IF there was a way to restrict access to buckets. We can not allow our client websites to access each other's data, and I would assume this to be the case for anyone who serves multiple clients.
can we accomplish the same thing with bucket policies instead?
Any update on this ?
How is this feature going?
Isolating key access to specific spaces is essential - spaces is unusable in the real world without it.
read only keys would also be nice
No reason to have multiple buckets and multiple keys if an key can access any bucket
It is really important. So far we have to create separate accounts for spaces
You won't be notified about changes to this idea.