LXC Directions

Serge E. Hallyn serge at hallyn.com
Mon Jul 18 21:00:42 UTC 2011

Quoting Clint Byrum (clint at ubuntu.com):
> LXC has been something I've heard mentioned hand in hand with Ensemble
> since the very first time I heard about Ensemble at UDS-M. I think I
> understand the directions that have been proposed, and I think its time
> we had the discussion so that we can enable LXC for local dev at the very
> least, and hopefully also for many other purposes in Ensemble.
> Here are the ways I see LXC being useful in Ensemble:
> ::Unit isolation
> Multiple units per machines isn't just about saving money, but also about
> being able to serve multiple services with a single machine. "Cloud in the
> cloud". :) As some people have suggested, the wordpress example does not
> need two machines.  (Or even 4 if you were to go High-Availability). But
> putting the db server and the app server on the same box means there's a
> potential for privilege escalation.  The app server is probably going to
> be exposed to the internet, at which point it will be quite vulnerable. If
> its ever compromised, this may lead to an attacker finding the database
> available locally, and compromise of said data.
> LXC at least would hide the existence of the database server from the
> web app server. As far as the attacker is concerned, its just another
> host that will have to be compromised over the network, instead of
> locally. LXC's security model is not actually much stronger than chroot's,

It also might be worth the time to enhance your uec template to add some
apparmor isolation.  It won't help with the problem of system call
abuses, but we could clamp down on some /proc and /sys/ stuff.

> The really confusing part for me is how to do the network. Right now you
> have a hostname, and that hostname is useful, as it resolves to the IP
> that one can contact your machine on.
> But if you create a container, it needs an IP. You can't use NAT, because
> now you have to make sure ports don't collide. On EC2, I'm not aware of
> a way for a single machine to get more than one internal IP. There are
> elastic IPs for public access, but if you use these from inside EC2,
> you are going to pay bandwidth charges.
> Another option I see is to create a VPN between all of the machines
> so that all of the containers can directly address all of the other
> containers on a network. This seems overly complex. Because its being

Do you think it's feasible to pick a large private subnet (say
10.90.x.y), give each ec2 host a 10.90.x.0/24 subnet, give each lxc
container a 10.90.x.y ip address, and have an agent on each ec2 host
maintain forwarding rules?  That's just for communication between
the containers, of course.  Service access from the outside would
require intelligent forwarding by some external facing agent.

There might be a clever way to use openvswitch here, perhaps Nick will
speak up :)


More information about the Ensemble mailing list