Capirca Integration¶
The firewall model plugin provides the ability to integrate with Capirca for configuration generation. The authors have applied a very light opinion onto the translation from the firewall models to generate valid policy (.pol
), network (.net
), and service (.svc
) files that are consumed by Capirca.
FW Model | Capirca |
---|---|
Name (as applicable) | Header - Filter Name |
Zone (as applicable) | Header - to-zone/from-zone |
Source Address / Group | Term - source-address |
Destination Address / Group | Term - destination-address |
Destination Service / Group | Term - destination-port, protocol |
Action | Term - action |
Logging | Term - logging |
Address - IP | *.net |
Address - Prefix | *.net |
Address Group | *.net |
Service - tcp/udp | *.svc |
Service Group | *.svc |
Note
If this terminology is not familiar, please review the documentation at Capirca.
Special Considerations¶
- Capirca does not allow special characters in a majority of the named objects, as such named objects are modified to the ouput used when processed via a modified (to allow for capital letters) Django slugify, this includes:
- Policy name, policy rule name, address, address group, zone, service, service group
- e.g. Policy called "Allow to Internet" will be called "Allow-to-Internet"
- Note: This will not change barring a major update from Capirca
- FQDN and IP Range are not supported by Capirca and will fail if attempting to use those features
- The zone is only used where Capirca supports it, at the time of this writing is only Palo Alto and Juniper SRX
- Zone based firewalls have headers on every rule
- Both Juniper SRX and Palo Alto support using the named zone "all" to represent all zones, but in all cases a zone must be set
- The "Filter Name" is a concatenation of the Policies applied to a given firewall
- Not all firewalls get a filter name, such as zone or direction based firewalls, which require a
chd_
custom field (more details below)
- Not all firewalls get a filter name, such as zone or direction based firewalls, which require a
- An object (policy, policy rule, src-addr, dst-addr, etc.) is put into and out of use based on whether or not the status is
active
or as defined in your plugin configuration- Anything other than active or defined in plugin setting
allowed_status
is ignored
- Anything other than active or defined in plugin setting
- Removing the last active object in an source-address, destination-address, or service will fail the process to avoid your policy failing open
- The Platform
network_driver
must match the Capirca generator name- You can optionally provide a mapping in the settings
capirca_os_map
to map from the current platform name, to the Capirca generator name
- You can optionally provide a mapping in the settings
- The action of "remark" on a rule is not conidered, you can set the setting
capirca_remark_pass=False
if you want it to fail by default rather than silently skipping
In addition to the above, you can add to any header or term by creating specific custom fields on the PolicyRule
data model. They must start with:
chd_
- Capirca Header Data - will be applied to theheader
for any given rule.ctd_
- Capirca Term Data - will be applied to theterm
for any given rule.
The process is to create a custom field, such as ctd_pan-application
, this will be applied to the PolicyRule as you describe. This can become problematic if you share the model for multiple firewall OSs. This can be conditionally applied via a custom field to the Platform
model. This custom field must be named capirca_allow
and be of type JSON and be a single list. For each OS defined by the platform, you can allow that custom field to populate. This allows you to use the same model, and not let the custom fields for one OS conflict with another OS.
Note: This is pseudo-code and is technically the custom_field called
capirca_allow
that has the data["ctd_pan-application", "ctd_expiration"]
in this example.
As previously mentioned, there is only a small opinion that is applied from the translation between the model and Capirca. That being said, Capirca has an opinion on how rules and objects are deployed, and within this project there is no consideration for how that may not align with anyone's intention on how Capirca should work. All such considerations should be referred to the Capirca project. There is no intention to modify the output that Capirca creates in any situation within this plugin.
That being said, in an effort to provide flexibility, you can override the translation process. However, you would be responsible for that implementation. You can provide within your setting, a dotted path import_string to your own function. This is provided in the custom_capirca
setting within your Plugin Configurations. The signature takes a Device
object instance and must return a tuple of (pol, svc, net, cfg)
, none of which are required to have data.
Summary¶
To summarize, what this integration provides and does not provide.
Provides¶
- Integrations with Capirca
- The ability to manage per platform Headers and Terms
- A Job that generated the configurations at the time you want
- The ability to override the opinionated Capirca solution
Does not Provide¶
- An opinionated configuration management solution that matches anything other than Capirca-provided configurations
- The ability to push configurations directly and natively from Nautobot
- The immediate updating from data in a
Policy
orPolicyRule
that gets reflected in the configuration, instead when the job is ran - Any post processing of configuration or pre-validation of data (such as checking if object name starts with an integer)