Configure containerVM firewall to enforce intent

[hickeng]

Story
As a VCH user I expect containers using container networks to have the same degree of network security and isolation as they would when using NAT & port forwarding.

Detail
Two primary scenarios for attaching a container directly to a container-network:

1. exposing a service, e.g. tomcat
   a. configure firewall to permit incoming only, and then only on exposed ports, e.g. 8080
   b. configure firewall to support port forwarding directly, e.g. 80 -> 8080
2. consumption a resource on that network, e.g. NFS server
   a. configure firewall to reject all incoming on that network, and only permit outbound to the target resource (protect network against containers as well as container against network)
   b. the general "container needs internet access" case - permit outbound only,

There is the additional case when (1) and (2) apply for the same network.

Undecided whether the firewall should drop or reject.

Acceptance

• examples of docker commands that express each of the intents, variants and combinations
• detail of the configuration data needed in the container to apply appropriate iptables rules for enforcement
  • preferably not just direct iptables config as it's tether's responsibility to map config to implementation in the OS environment it's built for
• tests that run a port scan against containers configured with the variations to confirm non-exposed ports are not reachable
• tests that confirm that permitted outbound traffic is successful, and that restricted outbound traffic is not

#microsegmentation #nsx #firewall #iptables

[hickeng]

#648 is related on the appliance side.

[mlh78750]

We should drop all inbound packets by default in the container VM's firewall configuration.

When a port is "expose"d through the docker configuration then the firewall should allow the port to accept inbound packets on that port from other containers in the bridge.

When a port is "publish"ed through the docker configuration then the firewall should allow the port to accept inbound connections from all.

When containers are linked then they allow inbound connections from each other.

More advanced firewall features from vSphere networking including networking and networking security features from NSX will be mapped to externally scoped networks and the configuration of those features will remain on the vSphere management plane. see: https://github.com/vmware/vic/tree/master/doc/design/networking

Docker port/publish/expose commands will affect the firewall on the container VM.

[hickeng]

@hmahmood this is the issue relating to container firewall config - the implication of this is that the ports to expose need to be present in the tether extraconfig.

[mdubya66]

GA feature from SSOD. @hickeng assigned in SSOD.

[hickeng]

@hmahmood I don't recall - does this require the iptables binary or not?

[hmahmood]

This would require the iptables binary. Any other way to allow only certain ports through?

[hickeng]

Changing this to high to elicit conversation specifically about firewall rule being applied when a container makes use of NFS volumes.

Setting to 8 as we'll either need to inject iptables into the containers, or implement libiptc in Go.
IPTC examples: http://wiki.tldp.org/iptc%20library%20HOWTO

[hickeng]

Short term alternatives to iptc based impl:

1. inject iptables & libiptc into containers and invoke via tether
2. document/provide scripts that:
   a. add iptables via Dockerfile
   b. add script that configures iptables rules inside the container
   c. add wrapper script that launches both iptables config and the container binary

[hickeng]

@fdawg4l I think you'll have addressed all of this once you're done with you're current work. If that's correct can you add this to the Release (release column and Release field) so that we make sure to doc and close it.

[hmahmood]

@stuclem need to document this.

[stuclem]

@hickeng I think that I need more information about #692 (comment) before I can document this.

[zjs]

Resolving as all children have been resolved.