Share configuration across firewalls

A firewall can inherit configuration from another firewall in the same namespace by naming it as its parent. The parent's rules, exceptions, and upstreams then apply to the child's traffic, live: change the parent and every inheriting firewall picks it up within a few seconds, no copying or re-import.

This is how one baseline policy serves a whole organization. Keep the organization's non-negotiables (malware blocking, vulnerability thresholds, approved upstreams) in one baseline firewall per ecosystem, and let each team's firewall inherit it and add its own rules on top.

Set a parent

In the dashboard, the firewall form (create or edit) has an Inherit configuration from selector. It offers firewalls of the same ecosystem and hides any choice that would create a loop. The parent can be any firewall; nothing special marks it as a baseline, and it can keep serving its own traffic.

In config as code, the parent is the parentId field:

{
  "id": "3e7f5cb806f26e3beae2",
  "ecosystem": "npm",
  "parentId": "43b5799c6cb335570cad",
  "rules": [],
  "exceptions": [],
  "upstreams": []
}

Setting or changing the parent is a configuration change (fw:update:config). The server rejects a parent that does not exist, has a different ecosystem, or would close a cycle, including inheriting from itself.

What the child serves

At request time the firewall resolves the parent chain into one effective configuration:

Three consequences:

• Inheritance is additive. A child can add rules. It cannot delete, edit, or override an inherited one, and an inherited rule that blocks still blocks.
• Parents can inherit too. Chains work (baseline → division → team) up to a depth of 32.
• Editing and export stay local. The firewall's own configuration contains only its own entries plus parentId; bsfw config export does not embed inherited rules. The merge happens at serving time only.

Inherited rules and the child's own end up in one set, evaluated cheapest selector first rather than parents before children; see rule evaluation.

One thing a baseline does not give you: a child can add an exception on an inherited rule, scoped to that child, with a reason and an expiry like any other. Inheritance guarantees the policy is present, not that nothing is waived under it.

Override inherited behavior

• Upstreams: define an upstream with the same id as an inherited one to replace it, for example to point the child at a different registry mirror.
• Rules: an inherited rule cannot be deleted from the child, but the child can add an exception referencing the inherited rule's ID to allow specific packages through, for that child only.
• Publish target: set the child's own publishTarget to route its publishes elsewhere.

Inheritance or cloning

These are different features. Clone (fw:clone, "use as template" when creating a firewall) copies a configuration once; the copy diverges freely afterwards. Inheritance (parentId) is a live link; the child follows every parent change. Use clone for a starting point, inheritance for an enforced baseline.

Verify

• The firewall list shows the parent in Inherits. In Rules and Exceptions, the first number is the child's own entries and (+N) is the number inherited from parent firewalls. For example, 0 (+1) means the child has no local rules and inherits one rule.
• Trigger an inherited rule through the child firewall (install a package the baseline blocks). Select its log entry to open the complete detail. It records the child firewall ID in firewall and the baseline firewall ID in sourceFirewall, which is how you tell baseline policy from team policy.

Troubleshoot

Related

• Concept: Rule evaluation, Upstreams and caching
• How-to: Manage exceptions, Manage config as code
• Reference: Firewall config, Logs, Permissions