2

I have enabled the privileged mode in the container and add a rule to it,

iptables -N udp2rawDwrW_191630ce_C0
iptables -F udp2rawDwrW_191630ce_C0
iptables -I udp2rawDwrW_191630ce_C0 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 4096 -j udp2rawDwrW_191630ce_C0

and kt exec into the container and use iptables --table filter -L, I can see the added rules.

/ # iptables --table filter -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
udp2rawDwrW_191630ce_C0  tcp  --  anywhere             anywhere             tcp dpt:4096

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain udp2rawDwrW_191630ce_C0 (1 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere

While when I logged into the node where the container lives, and run sudo iptalbes --table filter -L, I cannot see the same result.

I was thinking by default the previleged is dropped because the container might leverage it to change something like the iptables in the node, however it looks not like that.

So my question is "what is the relationship between K8S iptables and the one of a container inside a pod" and "why we stop user from modifying the container's iptables without the privileged field"?

Damon Yuan
  • 3,683
  • 4
  • 23
  • 31
  • Hi, I think this is because modifications done to Nodes `iptables` get lost in its dynamic modifications. Take a look at this part in [kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). – Piotr Malec Feb 14 '20 at 17:59
  • please explain "enabled the privileged mode in the container" : what command/yaml did you use? also is it plain docker container or k8s pod? – morgwai Feb 14 '20 at 21:08
  • @morgwai, the privileged mode is documented here: https://kubernetes.io/docs/concepts/policy/pod-security-policy/. It is container in k8s pod. – Damon Yuan Feb 15 '20 at 07:38
  • @PiotrMales, I don't think the Node's iptables has been modified by the container actually. I checked the node's iptables rules feel there're many rules related to the traffic but not reflected in the container. – Damon Yuan Feb 15 '20 at 07:40

1 Answers1

4

if you want to manipulate node's iptables then you definitely need to put the pod on host's network (hostNetwork: true within pod's spec). After that granting to the container NET_ADMIN and NET_RAW capabilities (in containers[i].securityContext.capabilities.add) is sufficient. example json slice:

  "spec": {
    "hostNetwork": true,
    "containers": [{
      "name": "netadmin",
      "securityContext": {"capabilities": { "add": ["NET_ADMIN", "NET_RAW"] } }

I'm not sure if privileged mode has anything to do with manipulating host's iptables these days.

morgwai
  • 2,513
  • 4
  • 25
  • 31
  • Thanks, I think if there's an option to enable the host network, then the default namespace on the pod should be different from the one of the host. – Damon Yuan Feb 17 '20 at 01:45
  • @DamonYuan you mean "iptables namespace" right? (not sure if "namespace" is the right term for iptables) So it would seem based on your experience, but to be honest I didn't know this before: I thought that an attempt to manipulate iptables without `hostNetwork: true` will basically result with some error. – morgwai Feb 17 '20 at 06:51
  • no it won't have any error - the container's iptalbes has been changed while the host's is kept as before. – Damon Yuan Feb 17 '20 at 10:31