Get the result of a command as a variable in salt stack to modify iptables - iptables

Question

I'm trying to put a new rule into iptables. What I would like is to put the rule into the penultimate line number (ie just before the DENY ALL statement). eg.
[vagrant#controller ~]$ sudo iptables -L INPUT --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
2 ACCEPT icmp -- anywhere anywhere
3 ACCEPT all -- anywhere anywhere
4 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
5 REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
then,
sudo iptables -I INPUT 5 -t filter -d 192.168.33.10 -m state --state NEW -j ACCEPT
would be:
[vagrant#controller ~]$ sudo iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
2 ACCEPT icmp -- anywhere anywhere
3 ACCEPT all -- anywhere anywhere
4 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
5 ACCEPT all -- anywhere 192.168.33.10 state NEW
6 REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
the issue is that I can not figure out how I can automate this with salt without explicitly knowing what the last line number is? Is there a way of running a command in salt stack and use the result of that command as a variable for the jinja template?
sudo iptables -L INPUT --line-numbers | tail -n1 | awk '{print $1}'

Answer 1

I'm not aware of any simple way to do this the way its described above. Some of the work-arounds that come to mind:
Define the last rule such that it depends on (i.e. requires) the one you need to insert. Salt would then make sure that they are in the right order.
Create an additional iptables chain. Insert a jump to the new chain somewhere into the original config, then alter the rules in the chain as needed. This gives you a lot of flexibility.
Write a shell-script which does what you want and call it with cmd.run. Quite inelegant but requires fewer changes to other parts of the config.
Neither of those options is perfect and may not suit your use-case. However, combining the first to methods will get you pretty far and also result in an over all cleaner setup.