Private Networking and Digital Ocean Platform

May 28, 2014 1.7k views
"Moisey May 11, 2013 The first stage of the private network will be rolled out as separate from the public internet but much like other providers it will be visible to other droplets in your account and others so there will still be a need to secure it with iptables rules depending on the services that you are running. We are looking into the logistics of providing customer segmented networks but usually that entails some sort of vlan configuration which requires further networking automation as well as some hard limits on the number of vlans that can be supported by gear which creates a few barriers that we run into." I read this in another question and it has raised a couple of concerns for me. 1) Does this mean that our VPS are not on their own VLAN? seems like a major security flaw to me even with IP tables this creates a risk which would not exist if vlans were used... IP tables would also be hard to manage with large deployments, even with tools like ansible the orchestration required to make sure only your VPS could talk to eachother would be a nightmare and cause a lot of uneeded troubleshooting when stuff did not work as expected 2) I see you mention gear (openshift) I was under the impression that digital ocean was KVM virtual machines. Our vms are really docker images orchestrated by gear? 3) If number 2 is true that really sucks and I have been wasting my time with digitalocean... we were using your platform to create a gear deployment strategy of backend services. Docker suffers from write performance issues and running several dockers inside a docker with heavy systems like influxdb, mariadb, mysql, elasticsearch seems like there would be some serious performance issues. 4) I have scripted ansible to disable to public network interface on the droplets when they get created but there is a rather large window of opportunity for attack when deploying large clusters of droplets. First the droplets all get spun up which is a very time consuming process when created 20 - 100 droplets at once, then the ansible playbook connects to all those droplets and disables the public interface. During this window automated scanners could already do their damage with 0 day exploits. We would like the ability in the API to private_networking=yes public_networking=no this will make it easy to keep backend services secure that do not have a need to be accessed directly from the internet. 5) we would like to see Project Atomic images available to provision droplets with, for docker deployments and openshift "gear" they are the way to go, the boot times are extremely fast compared to a full blown fedora or centos image, they are more secure and rolling updates using the os-tree model makes it a no brainer for large clusters. the fedora images are ready, centos images will be ready when centos 7 releases. 6) this request relates to #4 above - Private network access - this one is not a huge deal because we can setup a vpn on a public droplet but it would be nice to see digitalocean out of the box supporting large application deployments with backend services that do not require public access. to make it easy to manage and access these backend service droplets you could deploy a private network vpn access solution that when a customer logs in, it will only give them access to their vlan. This is what has done, they call it the "management layer" Thanks a head of time for taking the time to answer all these questions, so far I am loving the API and how ansible can spin up and configure 100's of droplets in no time, readying them to be docker hosts that are managed by openshift gear
2 Answers
Hey Stephan,

Sounds like you're up to some interesting stuff. I'll definitely pass your suggestions around. To clarify, DigitalOceans droplets are KVM virtual machines not Docker containers. Moisey was referring to "gear" as in hardware not openshift gear. Though they are not on their own VLAN.

As for feature requests, the best place for those is over on our UserVoice page: It helps us gage user demand.

There's a lot of new stuff coming up in the pipeline including rolling out v2.0 of our API. So stay tuned!
thanks for the quick response, I added some votes to

seems others feel the same way I do, DO really needs this for people who have big projects they are working on where security is a must.

I also added this one for Project Atomic:

For those familiar with CoreOS, Project Atomic is the centos version of coreos and is supported by the mainstream Redhat Enterprise Linux instead of a 3rd party company, It is also easier to use and not as opinionated as CoreOS is... leaving people the freedom to use whatever suits them best for their project.
Have another answer? Share your knowledge.