nautobot / nautobot-app-firewall-models

Model Firewall policies in Nautobot

Home Page:https://docs.nautobot.com/projects/firewall-models/en/latest/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

PolicyRules relationship change from M2M to ForeignKey

itdependsnetworks opened this issue · comments

Environment

  • Nautobot version: 1.3
  • nautobot-plugin-firewall-model version: 0.1

Proposed Functionality

The ability to more closely align PolicyRules to the Parent Policy. While it is clear that the current design is more flexible, that flexibility comes at the cost of complexity (both in code, mind mapping, and UI) vs the ForeignKey approach.

Use Case

  • Easy viewing when viewing PolicyRules, which Policy it is applied to
  • Easy viewing when viewing Policy, which PolicyRules it is applied to
  • Easier ability to find a rule (e.g. filtering via Policy)
  • More closely aligning to how rules are maintained in every firewall system I am aware of Palo Alto, ASA, Juniper SRX, Juniper Netscreen.
  • More closely aligning to domain managers I am aware of where they will have a construct like Panorama does where Device Group == Policy, a Policy has rules, and Policy can be applied to multiple devices. Similar for Panorama, Fortimanger, Juniper NSM, and Juniper Space.

Adding in a couple of discussion bullet points:

  • Easier creation of the mapping between Policy and PolicyRule - currently you have to know the name of the PolicyRule you want to assign to a given Policy, if it were a foreign key then this mental overhead could be saved
  • With #53 the cases where you do in fact need the same PolicyRule twice (or even more often) can be addressed with a simple cloning of that PolicyRule. I see that this is duplicating data in the database which should normally be avoided, but it also allows these two instances of that PolicyRule to potentially diverge from each other
  • Should the FK be a required field? (create policy first)
  • The weight would switch to being on the PR model not the through model
  • Clone to make up for the loss of reuse of PRs?

1/3 yes
2 first weight or index? For weight I would have thought on the policy model, but I suspect you have thought of that and it doesn’t work out.

How about having the following:

  • weight on the Policy model to express in which order they should be applied (if there are multiple policies with overlapping zones for the same device, such as a general, default one and a device-specific)
  • index on the PolicyRule model to express their order inside of the Policy

I meant index moving to PolicyRule, right now it is in the M2M releationship.

yea, index to PolicyRule

Resolved by #80