4 ms·

S3 (and similar storages) have caused plenty of security issues in several occasions (usually because of misconfigured buckets, making all contents available to

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.

karambir 3y ago
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.
- eek2121 3y ago
  Really? I have had no issues using them for basic hosting.
- dcow 3y ago
  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.
k8sToGo 3y ago
Isn't this usually solved through some form of IAM policies? Does DO not have this?
- Operyl 3y ago
  No such luck there, but this is kind of the MO for DigitalOcean, sadly.
  - dcow 3y ago
    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.
    - Operyl 3y ago
      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!
      - deleted 3y ago
        [deleted]
      - dcow 3y ago
        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.
londons_explore 3y ago
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.
- rmbyrro 3y ago
  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.
- undyingtrillion 3y ago
  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/pricing/#bandwidth https://docs.digitalocean.com/products/spaces/details/pricin...
dang 3y ago
I'm afraid you broke the site guidelines by using the submission title to editorialize. Please see https://news.ycombinator.com/newsguidelines.html 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&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang 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.

karambir 3y ago

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.

eek2121 3y ago
Really? I have had no issues using them for basic hosting.
dcow 3y ago
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.

k8sToGo 3y ago

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

Operyl 3y ago
No such luck there, but this is kind of the MO for DigitalOcean, sadly.
- dcow 3y ago
  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.
  - Operyl 3y ago
    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!
    - deleted 3y ago
      [deleted]
    - dcow 3y ago
      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.

londons_explore 3y ago

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.

rmbyrro 3y ago
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.
undyingtrillion 3y ago
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/pricing/#bandwidth https://docs.digitalocean.com/products/spaces/details/pricin...

dang 3y ago

I'm afraid you broke the site guidelines by using the submission title to editorialize. Please see https://news.ycombinator.com/newsguidelines.html 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&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang 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.