Hey Benoit and Fajar, Thanks a lot for sharing those solutions. I will try those out soon and will let you know if I need help with anything.
On Tue, Oct 20, 2015 at 10:25 AM Benoit GEORGELIN - Association Web4all < [email protected]> wrote: > I'm using an openvswith to provide network isolation/rules. > > - Containers cannot change their own IP or MAC address. They will not > receive any traffic anymore. > - I'm also able to manage network queue and limit traffic > > Here is what I shared some time ago on that talk ( > https://www.mail-archive.com/[email protected]/msg03609.html > ) > > ------------------------------------------- > This is finally what I did with openvswitch : > > ovs-ofctl del-flows vswitch-vps > ovs-ofctl add-flow vswitch-vps "in_port=PORT_GW ip actions=NORMAL" > ovs-ofctl add-flow vswitch-vps "in_port=PORT_GW arp actions=NORMAL" > > # default drop communication with HOST_A > ovs-ofctl add-flow vswitch-vps "in_port=PORT_HOST_A priority=38000 > idle_timeout=0 action=drop" > > # default drop communication with HOST_B > ovs-ofctl add-flow vswitch-vps "in_port=PORT_HOST_B priority=38000 > idle_timeout=0 action=drop" > > # Allow GW communication + Hypervisor > ovs-ofctl add-flow vswitch-vps "in_port=PORT_GW priority=39000 > dl_type=0x0800 nw_src=IP_GW dl_src=MAC_GW idle_timeout=0 action=normal" > ovs-ofctl add-flow vswitch-vps "in_port=PORT_GW priority=38500 > dl_type=0x0806 dl_src=MAC_GW idle_timeout=0 action=normal" > > # Allow HOST A > ovs-ofctl add-flow vswitch-vps "in_port=PORT_HOST_A priority=38400 > dl_type=0x0800 nw_src=IP_HOST_A dl_src=MAC_HOST_A idle_timeout=0 > action=normal" > ovs-ofctl add-flow vswitch-vps "in_port=PORT_HOST_A priority=38300 > dl_type=0x0806 dl_src=MAC_HOST_A idle_timeout=0 action=normal" > > # Allow HOST B > ovs-ofctl add-flow vswitch-vps "in_port=PORT_HOST_B priority=38400 > dl_type=0x0800 nw_src=IP_HOST_B dl_src=MAC_HOST_B idle_timeout=0 > action=normal" > ovs-ofctl add-flow vswitch-vps "in_port=PORT_HOST_A priority=38300 > dl_type=0x0806 dl_src=MAC_HOST_B idle_timeout=0 action=normal" > > > To find port numbers: > > ovs-ofctl show BRIDGE > ------------------------------------------- > > I did a small video about how I can deploy an LXC container (unprivileged) > including network configuration. > > https://vimeo.com/142828076 > > > I'm working to make a better integrated solution and I'll share that on > github. > > Cheers, > > > Cordialement, > > Benoît Georgelin > > Afin de contribuer au respect de l'environnement, merci de n'imprimer ce > mail qu'en cas de nécessité > > ------------------------------ > *De: *"Fajar A. Nugraha" <[email protected]> > *À: *"lxc-users" <[email protected]> > *Envoyé: *Mardi 20 Octobre 2015 07:22:57 > *Objet: *Re: [lxc-users] Network isolation in unprivileged containers > > On Tue, Oct 20, 2015 at 6:11 PM, Akshay Karle <[email protected]> > wrote: > >> It would help to know, what level of isolation you're thinking about? >>> What is the final end goal? >>> >> >> I'm currently looking at ways to prevent any container from having the >> ability to discover other containers in the network and sniff their packets >> sent, which if sent over an unencrypted protocol (http for example) might >> be harmful as it could expose data. >> >> > "Discover" and "sniff other container's packets" are two different things. > > For example, on a routed setup where each container gets a /32 address, > they can still ping each other (thus discovering the others exist), but > they can't sniff traffic other than their own > > > >> I'm now considering setting up iptable rules on the host to achieve this >> but don't have much experience with iptables so will do my research now to >> see what is needed to setup the right iptable rules. >> >> > You mentioned you tried creating bridges for each container? > > Combine that with direct /32 routing and proxyarp, and you pretty much > confine each container to their own /32 address space. They will not be > able to sniff other containers traffic. They won't even be able to use > another IP address other than the one assigned to them. > > I believe there was also similar-resultng technique with openvswitch(?) > discussed some time ago on this list. Perhaps you can find it on the list > archives, I don't have the link handy right now. > > -- > Fajar > > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users > _______________________________________________ > lxc-users mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
