Hacker News Reader

Comment by corresation | Hacker News Reader

Is this not bounded to a particular tenant? Meaning if I have a droplet I can hammer/DoS/or exploit test other tenants? Obviously people should be giving these private IPs the normal care and concern that they give their "public" IP, but with many other vendors these are by default externally limited to images that you own, effectively providing layers of defense.

EDIT: Note that I ask this specifically because the term private networking may be misleading to some. These are non-publicly routed, but they most certainly aren't private.

View on HN

That is correct, it's not bound by tenant.

Most other providers do not restrict private network either, I'm talking about the big ones like RackSpace, Amazon and others.

What you're talking about is dedicated private VLAN's or private subnet's and that is not common especially in a cloud environment.

That's not entirely true. While Rackspace does provide a shared private network for intra-DC communication, it also provides the Cloud Networks product that is capable of creating tenant specific networks. Think VLAN tagging for Cloud.

On that private network, you can use your own addressing, use multi-cast, etc. Much less limited and more secure than a shared private network. It's also free.

Mandatory Disclosure: I work for Rack.

Amazon supports this as well with their Virtual Private Cloud(VPC)

>> I work for Rack.

Can you give any insight into what RackConnect actually is?

Sorry for the late reply.

RackConnect is a product that allows us to link cloud servers in our public Cloud environment with servers in a dedicated configuration.

We are currently using RackConnect 2.0 which achieves this by attaching the shared private network to the dedicated environment and configuring the cloud servers network stacks to use the dedicated load balancer and firewall as their default gateway, so that all traffic flows through the dedicated config. Incoming traffic (or traffic from the dedicated configuration) will be routed out to the Cloud servers by the dedicated load balancer.

RackConnect 3.0 (coming soon) will provide the same service, but the connection from the cloud servers to the dedicated configuration will be provided by Cloud Networks, our SDN product. This simplifies the configuration and provides additional security to the traffic.

The last time I looked in the Rackspace docs, it looked like this was in the process of being rolled out ("production ready but will be available to customers in a phased release"). Is Cloud Networks considered fully supported now?

Sorry for the slow reply. Yes - Cloud Networks is fully supported.

>Most other providers do not restrict private network either

EC2 has security groups, and the default group would be that non-tenant machines could not access your services (this is external to your image, at presumably the hypervisor or networking level. What you do in ufw/iptables is above and beyond this). I don't see any similar mechanism in the Digital Ocean world.

AWS supports VPC (virtual private network). It lets you setup sub groups of VMs that are only network accessible to each other with explicit endpoints open (ex: just HTTP open to an ELB). It's recommended for all new deployments. We use it in our cloud deployment of JackDB and it's really pleasant to use. Plus it makes it really easy to setup a bastion SSH proxy as an end point (vs. having all your instances publicly accessible).

Memset (a UK cloud company) gives customers a vlan for private networking.

Azure supports private VLANs, any number, between any virtual machines or cloud services, with the possibility to VPN to that.

Other major cloud providers provide similar functionality as well. This is common in a cloud environment and taken for granted with dedicated hosting.

Assuming it's similar to Linode, nope, not bound. I ended up doing a very the very not-scaleable thing of dropping packets at the iptables layer from any IP that wasn't my other Linode.

Sounds like something VXLAN is well equipped to handle - VLANs tunneled over IP to create private networks in large cloud environments: http://en.wikipedia.org/wiki/Virtual_Extensible_LAN I wonder if DO will be using something like this to mitigate direct attacks (though VXLAN wouldn't solve the problems of link oversubscription—but there are other mechanisms in place to solve this)

Reply on news.ycombinator.com