Q:

Is there a way to customize iptables rules in filter table on kubernetes master/worker node?

I'm working on a project where we're attempting to transition legacy product (deployed as a standalone VM) to kubernetes infrastcurture.
I'm using KUBEROUTER as CNI provider.
To protect the VM against DoS(and log the attempt) we've added different chains in iptables filter table. (These include rules for ping flood, syn flood - I think network policies/ingress controller can manage syn flood, but not sure how icmp flood would be taken care of. )
When I deployed kubernetes on my VM, I found that kubernetes updates iptables and creates it's own chains. (Mainly k8s updates NAT rules but chains are added in filter table as well)
My questions are:

Is it possible to customize iptables on VM where kubernetes is running?
If I add my own chains (making sure that k8s chains are in place) to iptables configuration, would they be overwritten by k8s?
Can I add chains using plain old iptables commands or need to do so via kubectl? (From k8s documentation, I got an impression that we can only update rules in NAT table using kubectl)

Please let me know, if somebody knows more on this, thanks !
~Prasanna

A:

Is it possible to customize iptables on VM where kubernetes is running?

Yes, you can manage your VM's iptables normally, but the rules concerning application inside of Kubernetes should be managed from inside of Kubernetes.

If I add my own chains (making sure that k8s chains are in place) to iptables configuration, would they be overwritten by k8s?

Chains should not be overwritten by Kubernetes as Kubernetes creates its own chain and manages it.

Can I add chains using plain old iptables commands or need to do so via kubectl? (From k8s documentation, I got an impression that we can only update rules in NAT table using kubectl)

You can use iptables for rules related to the VirtualMachine. To manage firewall rules you should use iptables because kubectl can’t manage the firewall. For the inbound and outbound rules in Kubernetes cluster use Kubernetes tools ( .yaml files where you specify the network policies). Be aware not to create services that might be in conflict with iptables rules.

If you intend to expose application services externally, by either using the NodePort or LoadBalancing service types, traffic forwarding must be enabled in your iptables ruleset. If you find that you are unable to access a service from outside of the network used by the pod where your application is running, check that your iptables ruleset does not contain a rule similar to the following:

:FORWARD DROP [0:0]

Kubernetes network policies are application-centric compared to standard infrastructure/network-centric standard firewalls.
Which means that we do not really use CIDR or IP based network policies, in Kubernetes they are built on labels and selectors.
Concerning DDoS protection and details of ICMP flood attacks: the truth is that "classic" methods of mitigation - limiting the ICMP responses/filtering techniques will have an impact on legitimate traffic. In the "new era" of DDoS attacks with huge traffics, firewall based solutions are not enough as the traffic is usually able to overbear them. You could consider some vendor specific solutions or if you have that kind of possibilities - prepare your infrastructure to bear huge amounts of traffic or implement solutions like ping size and frequency limitations. Also, the overall DDoS protection consists of many levels and solutions. There are solutions like black hole routing, rate limiting, anycast network diffusion, uRPF, ACL's which can also help with application-level DDoS attacks. There are many more interesting practices I could recommend, but in my opinion, it is important to have a playbook and incident response plan in case of those attacks.

