Watch my talk “Start using Configuration Management in 5 steps”, at the CloudStack Collaboration Conference, Denver, Co, USA (April 9-11 2014).
Archives For 30 November 1999
Here are the slides from my presentation at the CloudStack Collaboration Conference in Denver:
As you might have noticed, I switched jobs on Feb 1st and was quite busy after that. I joined Schuberg Philis, a Mission Critical Outsourcing company in The Netherlands. I met the folks on the CloudStack Collaboration Conference in Amsterdam, back in November. I have a very cool job, as I work with a bunch of very skilled colleagues on our Mission Critical Cloud, that is powered by Apache CloudStack.
The last two months I spent quite some time working with CloudStack, debugging issues and most of all: building new capacity and migrating old so-called PODs to new ones. Recently, CloudStack 4.3 was released and I believe this is the best release ever. Feels “snappier”, has lots of fixes and new cool features. We upgraded our pre-production cloud (running ~600 VMs) and apart from one little issue everything went smooth. Impressed!
Next week, I’ll be in Denver, CO at the CloudStack Collaboration Conference. I’ll do a talk and explain why you should use configuration management and will show you how to implement configuration management in your existing environment using 5 steps. This can be quite challenging, because when a lot of manual work is done, people are usually very busy. How do you find the time to implement configuration management?
Meet me in Denver on April 9-11!
I’ve been working a lot with CloudStack Advanced networking and find it very flexible. Recently, I had another opportunity to test its flexibility when a customer called: “We want VM’s in your CloudStack cloud, but these VM’s are only allowed be reachable from our office, and not from the public internet”. Firewalling? No, they required us to use their VPN solution.
Is CloudStack flexible enough for this to work? Yes, it is. In this blog I’ll tell you how we did it. And it doesn’t even matter what VPN device you use. This will work regardless of brand and features, as lang as it supports a public ip-address to connect over the internet to another VPN device, and has a private network behind it. All VPN devices I know of support these basic features.
VPN (Virtual Private Networking)
The client’s office is connected to the internet and has a VPN device. We received another device as well to host in our data center and the two talk to each other over the public internet in a secure way. Probably speaking IPsec or similar but that is beyond the scope of this blog.
The VPN device in the data center has a public ip-address on its WAN port but also has some ports for the internal network. We configured it to use the same network CIDR as we did in the CloudStack network we created for this customer. Let’s use 10.10.16.0/24 as an example in this blog. And now the problem: this cloud network is a tagged network and the VPN device we received is not VLAN-capable.
VLANs in the Cloud
CloudStack Advanded networking relies on VLANs. Every VLAN has its own unique ID. Switches use this VLAN ID to keep the VLAN networks apart and make sure they’re isolated from each other. Most switches support VLANs as well, and that’s were we’ll find the solution to this problem.
Configuring the switch
We connected the VPN device to our switch and set its port to UNTAGGED for the VLAN ID the CloudStack network uses. In other words, devices connected to this port now do not need to know about the VLAN. The switch will add it as traffic flows. This means the VPN device will use an ip-address in the 10.10.16.0/24 range and is able to communicate with the VM’s in the same network. The CloudStack compute nodes have their switch ports set to TAGGED and the switch makes communication between them possible.
Overview of ip-addresses:
- 10.10.16.1 – the internal VPN device ip-address in the data center
- 10.10.16.11 – the first VM’s ip-address
- 10.10.16.12 – the second VM’s ip-address
The VM’s have their default gateway set to the VPN device’s 10.10.16.1 address. Also, the office needs to be configured in a way it knows the 10.10.16.0/24 network is handled by the VPN device located there. Users in the office will now be able to access the VM’s on the 10.10.16.0/24 network.
Conclusion
While the VM’s are hosted on our CloudStack cloud on the internet, they do not have public ip-addresses and thus are not reachable. The only public ip-address for this customer is the one configured on the VPN device in the data center. This provides the same level of security as you’d have with physical servers but adds the power of a cloud solution.
Thanks to the flexibility of the CloudStack Advanced Networking this cloud be done!
It just came to my attention that a vulnerability in Apache CloudStack was discovered, as John Kinsella writes in his post to the Apache CloudStack dev-mailinglist.
A malicious user could, for example, delete all VMs in the system. Addressing this issue is especially important for anybody using CloudStack in a public environment.
The vulnerability report has an easy work-around that I will mention here as well:
mysql -p -u cloud -h mgt-server-ip update cloud.user set password=RAND() where id=1; \q
Hugo Trippaers of Schuberg Philis discovered this issue. Thanks for sharing!
Remi Bergsma's blog 