Live data from Hacker News

In Digital Ocean, S3-like space keys can access all your buckets

ideas.digitalocean.com

71–80 of 104 posts

Re: In Digital Ocean, S3-like space keys can access all your buckets

#71
post #33

The lack of ACLs or comparable permissions is by far the biggest thing that prevents me from recommending DO for production workloads. This kind of thing is absolutely essential. You can't even separate dev resources from prod resources, every API key has godmode on your whole account. This is a security disaster. For a simple example, I'm running externaldns on a kubernetes cluster. For production use, I'd want to a…

I agree, probably the biggest point Digitalocean is lacking. I think the only workaround is creating several projects? But that probably becomes annoying and hard to manage quite easily if you want a lot of separation.

IIRC projects only group resources under the same account. API keys are still account-wide, so projects provide no isolation there.

There is a other mechanism DO has to allow multiple accounts under one billing context (I think it might be called 'teams'?) but sadly this is still extremely coarse grained, and doesn't allow you to lock a key down to a particular resource, or even a class of resources.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#72
post #41

Earlier quoted context omitted.

Wow, this just confirms my belief. There is precisely zero circumstance where it is ok to give private customer data to another customer. The fact that you think it had anything to do with an API or how it is used is all anyone needs to know about it. The idea that warning your customers of your vulnerabilities is "irresponsible" is only true if you care more about revenues than your customers' security.

Unless I misunderstood something and one has to explicitly opt out of scrub for this to occur, I agree 100%. This is surprising. And they were mad that a customer thinks this is undesirable? I was using DO. It is not a serious project but I think I'll be moving on nonetheless.

For what it's worth, neom has moved on from DO a while back.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#73
post #54

I don't know if they've improved it, but 5 years ago I basically couldn't delete a DO Space because they had no way of doing a mass deletion. I even got technical support who basically told me I was doing it the best way possible. My delete operation took several months to run.

That is a limitation that comes along with having to be S3 compatible; the best you can do is to combine ListObjectsV2[1] + DeleteObjects[2] (1000 objects in a single API call). [1] https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObje... [2] https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteOb...

While S3 doesn’t have a REST API to do it, you can trigger it through the console and it applies pretty quickly if you don’t have a lot of objects (hundreds of thousands if I recall correctly) and will apply in the background otherwise. The way to do it via the s3 API is to install a lifecycle policy to delete everything.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#74

The lack of ACLs or comparable permissions is by far the biggest thing that prevents me from recommending DO for production workloads. This kind of thing is absolutely essential. You can't even separate dev resources from prod resources, every API key has godmode on your whole account. This is a security disaster. For a simple example, I'm running externaldns on a kubernetes cluster. For production use, I'd want to a…

Agreed. We had solved it at PhishDeck back in the day through the use of multiple projects, i.e., Platform Production, Platform Staging, Tooling Production, Tooling Staging etc.

Still not ideal, but it minimised security risk and kept things organised.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#75
post #72

Earlier quoted context omitted.

Unless I misunderstood something and one has to explicitly opt out of scrub for this to occur, I agree 100%. This is surprising. And they were mad that a customer thinks this is undesirable? I was using DO. It is not a serious project but I think I'll be moving on nonetheless.

For what it's worth, neom has moved on from DO a while back.

Yeah, I read a bit further and it was not scrub by default but had to be opt-in. And today is the first I heard that all API keys have ridiculous access. I'm done.

Now I just need to find a cloud hosting service that will do a low cost easy k8s cluster, preferably not AWS.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#76
post #28
post #19

Earlier quoted context omitted.

Some of the comments by DO on that GitHub thread, are really surprising, and disappointing to say the least...

I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) inste…

> there isn't actually a security issue

The official blog from DigitalOcean is here:

https://www.digitalocean.com/blog/transparency-regarding-dat...

While it does not call it a “security issue” directly, it details several changes to the service to prevent customer data leaking between accounts. That seems to contradict your position that there was no problem.

> 10 years later and I still remember how pissed off I was that day, hah.

I would have hoped that after 10 years you would be able to admit that letting customers read each other’s data was a mistake. The existence of a disk scrub API, the problem being improperly reported, and DO being advertised as “not for production use” are not valid excuses.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#77
post #72

Earlier quoted context omitted.

For what it's worth, neom has moved on from DO a while back.

Yeah, I read a bit further and it was not scrub by default but had to be opt-in. And today is the first I heard that all API keys have ridiculous access. I'm done. Now I just need to find a cloud hosting service that will do a low cost easy k8s cluster, preferably not AWS.

Looks like OVH does managed k8s, and they're pretty solid at this point for the most part. https://us.ovhcloud.com/public-cloud/kubernetes/

Re: In Digital Ocean, S3-like space keys can access all your buckets

#78
post #53
post #35

Earlier quoted context omitted.

I think DO is doing fine addressing their target market. I also wish they had IAM but you have to admit IAM is huge and messy and is often more about managing your employees than your infrastructure. I’m okay waiting for them to get it right rather than rushing out a quick half baked idea that ruins their entire product stack err platform.

I don't care for the full on flexibility of IAM, but I'd kill for a simple "this key is for this bucket" feature. That doesn't seem so far fetched, I don't need per-object permissions within a single bucket!

Since the bucket namespace is global you can always just use different accounts. But I agree it doesn't seem that hard to add this small feature.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#79

Earlier quoted context omitted.

That is a limitation that comes along with having to be S3 compatible; the best you can do is to combine ListObjectsV2[1] + DeleteObjects[2] (1000 objects in a single API call). [1] https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObje... [2] https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteOb...

While S3 doesn’t have a REST API to do it, you can trigger it through the console and it applies pretty quickly if you don’t have a lot of objects (hundreds of thousands if I recall correctly) and will apply in the background otherwise. The way to do it via the s3 API is to install a lifecycle policy to delete everything.

At the time, the lifecycle policy didn't seem to be an option on DO unfortunately.
Post reply on HN