Change-Id: Ib924de131cca35052b50555c280484ef0161ebaa

Customer-Found
Prod-Related: CEEMCP-19
Prod-Related: PROD-22620

Change-Id: Ib14838becc409c2f735d93b5fa8a8ead6ea1a5ec

There is a way to manage tables in rules, but there is no way to
manage tables for chains when setting policy.

Looks like pillar structure is bad from the beginning and to
not break backward compatibility, as same chain names may occur in
different tables, so it is proposed to check if 'chain.policy' is
map. And if it is, specific policies would be ensured for specific
tables, otherwise table 'filter' would be used as a fallback.

To ensure chains in specific tables we iterate over all rules in
each chain.

This hash is valid:

parameters:
  iptables:
    service:
      enabled: true
      chain:
        OUTPUT:
          policy: ACCEPT
        FORWARD:
          policy:
          - table: mangle
            policy: DROP
        INPUT:
          policy:
          - table: nat
            policy: ACCEPT
          rules:
          - jump: ACCEPT
            protocol: icmp
        POSTROUTING:
          rules:
          - jump: MASQUERADE
            protocol: icmp
            out_interface: ens3
            table: nat

Prod-Related: CEEMCP-12
Prod-Related: EME-313

Change-Id: Ib5ba97dad165d3ef2dec7e053b391ea36a996103

Change-Id: I9d93052cfc197a364b42240448344d5543e8805f

* Allow custom chains to be present, other than the INPUT, FORWARD, OUTPUT default chains.

* Adding missing endif

* Require the packages to be installed first.

* Test should use rules as key, not rule.

* Making it a array list, instead of a dict.

* convert rules to a list instead of a dict.

* Only if policy is defined, include this statement.

* Only ensure chains if not container :)

* The chain is only ensured if we are not a container.

* Do not run at all for containers.