[lxc-users] Crucial LXD, Bind Mounts & Gluster Question

[Zach Lanich]

I would have to at very least chown the subdirectory to the same user the container is running on in order to have write access to it from with in the container, but that was my thought that the volume itself provides enough protection. My friend who is an experienced systems administrator seems to be very uncomfortable with the idea of bind mounting into the container, as he thinks it kind of breaks the isolation that the containers provide when adding write access to the mount, Thoughts?


Best Regards,

Zach Lanich
Owner/Lead Developer
weCreate LLC
www.WeCreate.com
814.580.6636

> On Aug 14, 2016, at 2:21 AM, Marat Khalili <mkh at rqc.ru> wrote:
> 
> Hello Zach,
> 
> > Gluster Volume subdirectories Bind Mounted into their respective containers (i.e. /data/gluster/user1 -> container:/data/gluster)
> 
> Considering this line, do you even depend on ACLs? I'd think bind mounts provide sufficient protection by itself, as long as server demons run outside containers.
> 
> (I'm currently facing similar problem, but don't have first-hand experience solving it yet.)
> -- 
> 
> With Best Regards,
> Marat Khalili
> 
>> On August 14, 2016 4:50:52 AM GMT+03:00, Zach Lanich <zach at zachlanich.com> wrote:
>> Hey guys, I have a crucial decision I have to make about a platform I’m building, and I really need your help to make this decision in regards to security. Here’s what I’m trying to accomplish:
>> 
>> Platform: Highly Available Wordpress hosting using Galera, GlusterFS & LXD (don’t worry about the SQL part)
>> - One container per customer on a VM (or ded server)
>> - (preferably) One 3 node GlusterFS Cluster for the Wordpress files of all customers’ containers
>> - GlusterFS volume divided into subdirectories (one per customer), with ACLs to control permissions (see *)
>> - Gluster Volume subdirectories Bind Mounted into their respective containers (i.e. /data/gluster/user1 -> container:/data/gluster)
>> - LXC User/Group mappings to make the ACLs work
>> 
>> My concerns:
>> - (*) Although the containers are isolated (all but the shared kernel), and that in itself is probably secure enough to feel ok about it, introducing a shared Gluster volume into the mix and depending on ACLs makes me a bit nervous. I’d like your opinions on what the norm is in the world (the PaaSs, etc) and if you guys think this is a terrible idea. If you think this is not a good way of handling my needs, PLEASE help me find a better solution.
>> 
>> My hangups:
>> - I know PaaSs have found incredibly efficient ways to provide containerized apps with high availability, and I tend to highly doubt they’re throwing up 3+ GlusterFS VMs for every single app they deploy. This to me seems like an impossibly cost-ineffective approach. Correct me if I’m wrong. That being said, I’m not 100% sure how they’re doing it.
>> 
>> Odd thoughts & alternative solutions that have crossed my mind:
>> - To avoid using a shared single Gluster Volume and ACLs altogether, while also avoiding too much infrastructure cost, I’ve thought of possible putting up a 3 VM Gluster cluster, each with matching LXD Containers on them with Gluster server daemons running in those containers. I could use those containers & networking to simulate having multiple 3 node Gluster Clusters, each being dedicated to a respective containerized app on the App Server. This to me seems like it would be an unnecessarily complex and annoying to maintain solution, so please help me here.
>> 
>> I hugely appreciate anyones help and this is a huge passion project of mine and I’ve dedicated an absurd number of hours reading to try and figure this out.
>> 
>> Best Regards,
>> 
>> Zach Lanich
>> Business Owner, Entrepreneur, Creative
>> Owner/CTO
>> weCreate LLC
>> www.WeCreate.com
>> 
>> 
>> lxc-users mailing list
>> lxc-users at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160814/dea458ee/attachment.html>