Hacker News Reader

Comment by sergioisidoro | Hacker News Reader

S3 (and similar storages) have caused plenty of security issues in several occasions (usually because of misconfigured buckets, making all contents available to the public). Given this, it would be expected that companies would pay a bit more attention to the security of these data storage methods.

However, in Digital Ocean, by design, you can't restrict keys to certain buckets. Once you issue a key, it can access all buckets within your project, with all operations (list, read, delete) files.

The issue has been reported and is known for a long time. It's even the top voted "idea" in the company portal.

Posting this here in hopes to bring awareness of this issue.

View on HN

I'm afraid you broke the site guidelines by using the submission title to editorialize. Please see https://news.ycombinator.com/newsguidelines.html: "Please use the original title, unless it is misleading or linkbait; don't editorialize."

If you want to say what you think is important about a page, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so.... Alternatively, you could have made a text post to communicate what you think is important about the issue, and then your title would have been fine.

What's not ok on HN is to use the title field as a way to comment on an issue, because then the submitter gets a privileged position relative to other commenters. Since the title is by far the largest influence on a thread, we want to avoid that. Being the submitter of a page shouldn't confer any extra special power over the discussion.

Things like these are why I stopped using digitalocean.

They had issues with DNS PTR records too for years. Same for initial auth tokens being global. I had hopes for them and used them exclusively at 1 time.

Really? I have had no issues using them for basic hosting.

My read on this situation is that DO is holding out until they have a comprehensive IAM solution. If you need IAM, don’t use DO. If you can live without IAM, DO is pretty nice.

As a user, you can fix this by having a proxy that fits in front and manages ACL's.

Obviously you have to pay for resources for that proxy, and it's probably going to want a large bandwidth allocation. Lucky because DO doesn't charge for bandwidth.

If I have to implement and manage an ACL myself (such a basic feature!!), it's better to go ahead and implement something like min.io and ditch DO entirely.

This is mostly true, but there is a case where you use your transfer pool.

From their product docs:

Droplets have their own transfer allowance, independent of Spaces. Traffic from Droplets to Spaces does not count against your Spaces transfer allowance (because inbound bandwidth to Spaces is free), but does currently count against your Droplets’ outbound transfer allowance.

https://docs.digitalocean.com/products/spaces/details/pricin...

Isn't this usually solved through some form of IAM policies? Does DO not have this?

No such luck there, but this is kind of the MO for DigitalOcean, sadly.

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.

Reply on news.ycombinator.com