Hi Serguei, On Thu, Nov 28, 2019 at 01:22:17AM +0000, Serguei Bezverkhi (sbezverk) wrote: > Please see below the list of nftables rules the code generate to mimic only filter chain portion of kube proxy. > > Here is the location of code programming these rules. > https://github.com/sbezverk/nftableslib-samples/blob/master/proxy/mimic-filter/mimic-filter.go > > Most of rules are static, will be programed just once when proxy comes up, with the exception is 2 rules in k8s-filter-services chain. The reference to the list of ports can change. Ideally it would be great to express these two rules with a single rule and a vmap, where the key must be service's ip AND service port, as it is possible to have a single service IP that can be associated with several ports and some of these ports might have an endpoint and some do not. So far I could not figure it out. Appreciate your thought/suggestions/critics. If you could file an issue for anything you feel needs to be discussed, that would be great. What about something like this: | table ip t { | map m { | type ipv4_addr . inet_service : verdict | elements = { 192.168.80.104 . 8989 : goto do_reject } | } | | chain c { | ip daddr . tcp dport vmap @m | } | | chain do_reject { | reject with icmp type host-unreachable | } | } For unknown reasons reject statement can't be used directly in a verdict map, but the do_reject chain hack works. > sudo nft list table ipv4table > table ip ipv4table { > set svc1-no-endpoints { > type inet_service > elements = { 8989 } > } > > chain filter-input { > type filter hook input priority filter; policy accept; > ct state new jump k8s-filter-services > jump k8s-filter-firewall > } > > chain filter-output { > type filter hook output priority filter; policy accept; > ct state new jump k8s-filter-services > jump k8s-filter-firewall > } Same ruleset for input and output? Seems weird given the daddr-based filtering in k8s-filter-services. Cheers, Phil
