Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DigitalOcean VPC

blog.digitalocean.com

Post reply on HN
Print view View original

151–160 of 169 posts

Re: DigitalOcean VPC

#151

Post by api »

beagle3 wrote: post #146
api wrote: post #137

Earlier quoted context omitted.

I don't get this. IPv4's address space is so small I can trivially scan any internal network, and there are a ton of ways to gather that data covertly from behind the firewall via maliciously crafted web pages or apps, abuse of any number of P2P apps or protocols (VoIP, video chat, WebRTC, etc.), and so on. IPv6 actually makes scanning harder since the address space is massive. E.g. if I have a /64 routed internally…

Mostly agree, but do want to clarify: Obscurity is NOT security. But obscurity as one layer in a larger defense-in-depth setup IS helpful. Do note that scanning IPv4 through a fishing page is still about a million times harder (literally) than targeting a known address. And NAT is not security, but in some context is still helpful as one layer in a defense-in-depth setup - you can’t directly attack something that’s n…

My approach is and was always edge-first. Security begins at connected devices; everything else is an afterthought. The only time you try to secure something primarily at the network level rather than the device level is when it's legacy junk you can't secure otherwise and that you must use.

I am not opposed to network firewalls and such, but they're just defense in depth. If the whole network wouldn't remain secure if it were connected to the Internet with no firewall, it's not secure.

Given that these things are afterthoughts, I am not willing to prioritize them much over efficiency, complexity reduction, and user experience. Afterthoughts should be sacrificed to complexity reduction because complexity negatively impacts security a lot more. Inefficiency and poor UI/UX also have security implications. They increase the amount of "shadow IT" type activity and also seem to make phishing easier. If you secure something in ways that prevent people from getting their work done, they will get their work done insecurely.

Treating NAT as a must-have or should-have rather than the ugly hack you don't want to have increases complexity and negatively harms UI/UX by making P2P stuff not work and making people have to work harder to do simple things. If removing NAT makes you insecure, you were insecure to begin with.

Needless to say I am a fan of the BeyondCorp/deperimeterization approach. Ideally physical networks should be dumb pipes and everything should be virtual. The LAN itself is legacy baggage.

Re: DigitalOcean VPC

#152

Post by beagle3 »

api wrote: post #151
beagle3 wrote: post #146

Earlier quoted context omitted.

Mostly agree, but do want to clarify: Obscurity is NOT security. But obscurity as one layer in a larger defense-in-depth setup IS helpful. Do note that scanning IPv4 through a fishing page is still about a million times harder (literally) than targeting a known address. And NAT is not security, but in some context is still helpful as one layer in a defense-in-depth setup - you can’t directly attack something that’s n…

My approach is and was always edge-first. Security begins at connected devices; everything else is an afterthought. The only time you try to secure something primarily at the network level rather than the device level is when it's legacy junk you can't secure otherwise and that you must use. I am not opposed to network firewalls and such, but they're just defense in depth. If the whole network wouldn't remain secure…

I do not disagree.

If you look at my original message, I was not suggesting NAT was useful - on the contrary, I was cautioning against relying on your internal NAT as a mitigation of the other enterprise's change processes. My whole post was about complexity reduction (as it relates to inter-enterprise conections)...

> Needless to say I am a fan of the BeyondCorp/deperimeterization approach. Ideally physical networks should be dumb pipes and everything should be virtual. The LAN itself is legacy baggage.

I also like it. But the post I was originally replying to implied a server->server connection between two enterprises, which is afaik not at all addressed by BeyondCorp or any of the projects it inspired - specifically, you need to treat the other corp like a Google user at home, rather than a Google employee in a hotel because you cannot enforce trusted hardware, inventory tracking, or any of the other things that make BeyondCorp as useful as it is.

Re: DigitalOcean VPC

#154

Post by terrywang »

freedomben wrote: post #139
terrywang wrote: post #106

Earlier quoted context omitted.

That stack was most likely legacy middleware + database backend, a combination of fusion middleware, oracle database, CRM, etc. running on physical hardware or virtualized. Not automated, very basic HA, not easily scalable. Nothing to do with Oracle Cloud (although Oracle Cloud won't be on my list unless it's marginally cheaper than other cloud service providers). BTW: Talking about Oracle Cloud, my free tier trial e…

Geez, thanks for sharing your experience. I run a number of things that I pay for myself and my cloud bill each month is becoming non-negligible. Even tho it kills me inside I considered looking at Oracle, but this is enough to steer me away. Thank you :-)

Looks like you should have a good look at DigitalOcean to run your personal side projects or fun stuff, which has a much more simpler and transparent billing model (capped, no nasty hidden cost).

I've been a long time DO customer and overall happy for the past 7 years. I've write my personal experience [1] with DO in another post.

[1]: https://news.ycombinator.com/item?id=23016669

Re: DigitalOcean VPC

#155

Post by james33 »

freedomben wrote: post #42

I'm glad they plugged their outbound network transfer fees compared to the others[1]. I was shocked and horrified when my AWS bill (which I pay myself) quadrupled due to outgoing network transfer fees. It's truly outrageous what they charge. I use Digital Ocean a lot now simply to avoid nasty surprises like that. I hope AWS and Google change that. [1] https://blog.digitalocean.com/its-all-about-the-bandwidth-wh...

This is precisely why we switched from AWS to DigitalOcean. This cut out monthly hosting costs by 80% and vastly simplified our entire setup. We also saw some solid performance gains in some areas (wrote up our benchmarks: https://goldfirestudios.com/blog/150/Benchmarking-AWS-Digita...).

Re: DigitalOcean VPC

#156

Post by Tostino »

freedomben wrote: post #139
terrywang wrote: post #106

Earlier quoted context omitted.

That stack was most likely legacy middleware + database backend, a combination of fusion middleware, oracle database, CRM, etc. running on physical hardware or virtualized. Not automated, very basic HA, not easily scalable. Nothing to do with Oracle Cloud (although Oracle Cloud won't be on my list unless it's marginally cheaper than other cloud service providers). BTW: Talking about Oracle Cloud, my free tier trial e…

Geez, thanks for sharing your experience. I run a number of things that I pay for myself and my cloud bill each month is becoming non-negligible. Even tho it kills me inside I considered looking at Oracle, but this is enough to steer me away. Thank you :-)

I had the same experience on my trial, along with SUPER pushy sales people. In the end, after I gave them our setup on DO and they said they'd come up with a proposal for an equivalent setup in Oracle Cloud, they came back and said "can't do it" and their proposal was a little over 3x what our current bill was.

Re: DigitalOcean VPC

#157

Post by breakingcups »

kamaln7 wrote: post #120
thenameisflic wrote: post #108

Earlier quoted context omitted.

Me too, but they recently let me down with their managed Redis . They clearly mention that their offering has daily backups, but it actually doesn't (had to contact support to find out, though). Had to migrate away from them because of that.

Hey, Kamal from DigitalOcean here. I'm sorry that happened to you! You're right, managed Redis Databases do not support backups[0] currently. I found the page on the website that says they do and let the team know. They will correct it asap. [0]: https://www.digitalocean.com/docs/databases/redis/#redis-lim...

Hey Kamal, good to see you here. I'm sorry to hijack this thread, but I'm hoping someone from DO could provide an official response to this often-cited post on HN regarding security issues on your K8S offering: https://news.ycombinator.com/item?id=22490390

Is there a chance you could poke someone into looking into this?

Re: DigitalOcean VPC

#159

Post by WhiteOwlLion »

toyg wrote: post #118
MrBuddyCasino wrote: post #45

Earlier quoted context omitted.

Guess who‘s favorite evil corp cloud is a magnitude cheaper than AWS on transfer pricing? Oracle, which is why Zoom just signed a deal. https://www.lastweekinaws.com/blog/why-zoom-chose-oracle-clo...

“A magnitude cheaper” _today_ . As soon as the focus shifts from acquiring cloud customers to making them profitable, expect the screws to tighten. As long as Larry lives and breathes, Oracle gonna Oracle.

As long as you don't use vendor specific tools, who cares? That's the point of kubernetes and to abstract away the whole "cloud" provider. Let it become a commodity and a race to the bottom.

Re: DigitalOcean VPC

#160

Post by kamaln7 »

breakingcups wrote: post #157
kamaln7 wrote: post #120

Earlier quoted context omitted.

Hey, Kamal from DigitalOcean here. I'm sorry that happened to you! You're right, managed Redis Databases do not support backups[0] currently. I found the page on the website that says they do and let the team know. They will correct it asap. [0]: https://www.digitalocean.com/docs/databases/redis/#redis-lim...

Hey Kamal, good to see you here. I'm sorry to hijack this thread, but I'm hoping someone from DO could provide an official response to this often-cited post on HN regarding security issues on your K8S offering: https://news.ycombinator.com/item?id=22490390 Is there a chance you could poke someone into looking into this?

Hey, I ran this by the DOKS team and they confirmed that this was taken care of a while back. Just to clarify, that issue existed while the product was in Limited Availability (think alpha). Nodes are now bootstrapped in a different way that eliminates the need to expose sensitive info in metadata or anywhere within the cluster itself.
Post reply on HN