DO Ideas 2

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
  • Attach files
  • Marco Lipparini commented
    September 11, 2018 15:56

    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!

  • Adam Fortman commented
    September 11, 2018 15:56

    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?

  • Anonymous commented
    September 11, 2018 15:56

    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 :)

  • C├ędric Ronvel commented
    September 11, 2018 15:56

    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.

  • Supun Budhajeewa commented
    September 11, 2018 15:56

    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.

  • Hannah Reedy commented
    September 11, 2018 15:56

    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.

  • Adam Fortman commented
    September 11, 2018 15:56

    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.

  • Graham Wheeler commented
    September 11, 2018 15:56

    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.

  • Anonymous commented
    September 11, 2018 15:56

    Read-Only Access Keys for files or spaces please!

  • Anonymous commented
    September 11, 2018 15:56

    The Read-only key for private files is a must! How else can you control what a system might do to the data?

  • Jorgen commented
    September 11, 2018 15:56

    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

  • MikeVL commented
    September 11, 2018 15:56

    We need this too!

  • Elliot commented
    September 11, 2018 15:56

    I agree, I also need this level of control

  • Ryan commented
    September 11, 2018 15:56

    We need this too.

    DO did suggest creating teams to accomplish this but it would be nice to have something closer to S3.

  • Wayne commented
    September 11, 2018 15:56

    Yes we need this ability to allow a single client to manage files in their own bucket / space.

  • Vishwa commented
    September 11, 2018 15:56

    This is a must. Also a key where we can give just *read only* access to a single/all spaces.