Spaces: custom API key permissions
Let us select which Spaces can be accessed on different API keys. Example: A key can only access a single Space.
-
Erik Tobiassen
- Sep 11 2018
Related ideas
Let us select which Spaces can be accessed on different API keys. Example: A key can only access a single Space.
Erik Tobiassen
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!
Attachments Open full size
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?
Attachments Open full size
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 :)
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
Read-Only Access Keys for files or spaces please!
Attachments Open full size
The Read-only key for private files is a must! How else can you control what a system might do to the data?
Attachments Open full size
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;
productx-production
productx-staging
productx-test
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
Attachments Open full size
We need this too!
Attachments Open full size
I agree, I also need this level of control
Attachments Open full size
We need this too.
DO did suggest creating teams to accomplish this but it would be nice to have something closer to S3.
Attachments Open full size
Yes we need this ability to allow a single client to manage files in their own bucket / space.
Attachments Open full size
This is a must. Also a key where we can give just *read only* access to a single/all spaces.
Attachments Open full size
read only private keys please!
Attachments Open full size
Massive +1 - this is the only thing holding me back from ditching AWS
Attachments Open full size
Yes please +1
Attachments Open full size
This is a must have for us.
Attachments Open full size
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!
Attachments Open full size
Please we need this done, its very important for enterprise customers
Create Two types of tokens:
Attachments Open full size
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.
Attachments Open full size
Agreed with others... need a way to isolate API access.
Â
Different API access based on a "Project" is a good solution for me.
Attachments Open full size
What about this topic? When can we expect a solution here?
Attachments Open full size
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
Attachments Open full size
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.
Â
Questions:
Â
Will keep using S3 for primary storage needs until this glaring oversight is addressed.
Attachments Open full size
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!
Attachments Open full size
This is a major oversight, and as others have said, a blocker for using this in production.
Attachments Open full size
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?
Attachments Open full size
Please dear god. Implement this. S3 is expensive and DO has a gaping large security vulnerability.
Attachments Open full size
Totally dead breaker not having this for sooo many ppl.
Please, please, please DO, we beg you, prioritize this pleaaasee!!!
Attachments Open full size
+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.
Attachments Open full size
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.
Attachments Open full size
+1!
Attachments Open full size
Guys, it's a little worrysome one key can access all of our data. Is there a workaround?
Attachments Open full size
How is this not done after > 1 year? So obviously necessary.
Attachments Open full size
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?
Attachments Open full size
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
Attachments Open full size
It doesn't make sense that different projects share the same credentials... Please fix this.
Attachments Open full size
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?
Attachments Open full size
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...
Attachments Open full size
+1 on this feature request.Â
Without keys per bucket, we can't possibly host buckets that are visible without any user/key controls.Â
Attachments Open full size
Please implement the bucket level access feature.
Attachments Open full size
Agree, very need this feature..Â
Attachments Open full size
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.
Attachments Open full size
We need to separate different projects / customers!
Attachments Open full size
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.Â
Attachments Open full size
It is really important. So far we have to create separate accounts for spaces
Attachments Open full size
No reason to have multiple buckets and multiple keys if an key can access any bucket
Attachments Open full size
Isolating key access to specific spaces is essential - spaces is unusable in the real world without it.
Â
read only keys would also be nice
Attachments Open full size
How is this feature going?
Attachments Open full size