feat(firewall): add named sets to FirewallConfiguration

[riccardotornesello]

Description

This Pull Request (PR) extends the functionality introduced in PR #2966 (firewalling rules implementation within FirewallConfiguration).

The primary goal of these changes is to enable the creation and utilization of named sets within the FirewallConfiguration Custom Resource (CR) to support the definition of more complex nftables rules. Named sets significantly improve the readability and management of firewall rules, especially when dealing with large lists of IP addresses or other match criteria.

Changes

Mandatory Modifications

• sets Field Addition: The FirewallConfiguration CR now includes a new field, sets, allowing users to specify a list of sets to be created and used. This includes defining the key and value types for each set (at the moment only ipv4_addr is supported).
• Reconciler Logic Update: The FirewallConfiguration reconciler logic has been updated to handle the addition, modification, and removal of these named sets within the firewall configuration.
• IP Address Matching Update: The logic for matching IP addresses has been modified to support the use of named sets. Users can now reference a set by writing @<set_name> in the match value.
• Webhook Validation: The validation webhook has been updated to properly validate the defined sets and ensure that set names referenced in match rules are valid and defined.

Strongly Recommended Modification (Separate Commit)

• A dedicated commit has been introduced to modify the webhook validation for NAT rules. This change now enforces the same IP address match validation for NAT rules that was already in place for filtering rules, ensuring consistent configuration integrity.

Example Usage

This example demonstrates how to define and use a named set (test_set) containing multiple IPv4 addresses within a filterRule.

apiVersion: networking.liqo.io/v1beta1
kind: FirewallConfiguration
metadata:
  labels:
    liqo.io/managed: "true"
    networking.liqo.io/firewall-category: gateway
    networking.liqo.io/firewall-subcategory: fabric
  name: test
  namespace: liqo-tenant-milan
spec:
  table:
    name: test_table
    family: IPV4
    # New 'sets' field to define named sets
    sets:
      - name: test_set
        keyType: ipv4_addr
        elements:
          - key: "8.8.8.4"
          - key: "8.8.8.8"
    chains:
      - hook: postrouting
        name: test_chain
        policy: accept
        priority: 99
        type: filter
        rules:
          filterRules:
            - action: drop
              match:
                - ip:
                    # Referencing the named set using @<set_name>
                    value: "@test_set"
                    position: "dst"
                  op: "eq"

[adamjensenbot]

Hi @riccardotornesello. Thanks for your PR!

I am @adamjensenbot.
You can interact with me issuing a slash command in the first line of a comment.
Currently, I understand the following commands:

• /rebase: Rebase this PR onto the master branch (You can add the option test=true to launch the tests
  when the rebase operation is completed)
• /merge: Merge this PR into the master branch
• /build Build Liqo components
• /test Launch the E2E and Unit tests
• /hold, /unhold Add/remove the hold label to prevent merging with /merge

Make sure this PR appears in the liqo changelog, adding one of the following labels:

• feat: 🚀 New Feature
• fix: 🐛 Bug Fix
• refactor: 🧹 Code Refactoring
• docs: 📝 Documentation
• style: 💄 Code Style
• perf: 🐎 Performance Improvement
• test: ✅ Tests
• chore: 🚚 Dependencies Management
• build: 📦 Builds Management
• ci: 👷 CI/CD
• revert: ⏪ Reverts Previous Changes

[riccardotornesello]

I also added another side change: a fix to the port range parsing function that always returned an error.
In this commit, you will also find a test suite for firewall utilities.

[riccardotornesello]

@cheina97 I noticed that there are some conflicts in this PR. Do you usually squash and merge or use a normal merge commit? If you squash I can merge the master in the branch and resolve the conflicts, otherwise I have to do some cherry picking

[cheina97]

@cheina97 I noticed that there are some conflicts in this PR. Do you usually squash and merge or use a normal merge commit? If you squash I can merge the master in the branch and resolve the conflicts, otherwise I have to do some cherry picking

We always squash the PR in a single commit and then merge it using the rebase, if you have conflicts rebasing on top of master should be enough

[riccardotornesello]

@cheina97 @frisso
sorry for the late updates but I managed to rebase the branch on the master and fix the linting issues. The branch should be ready for review