Add ZONE to a subnet

[jovandeginste]

With firewalld, interfaces can be added to zones (eg. public, mgmt, private, docker, ...).

I assign zones to subnets (public vs private), and add ZONE=$the_zone to the network device configuration file (eg. /etc/sysconfig/network-scripts/ifcfg-eth0)

This means I don't need to tell firewalld separately about the mapping of interfaces to zones, it is automatically added by ifup.

The question is: should this ZONE parameter be a "native" field in the subnet editor, or should it be added as a custom parameter (in the "Parameters" tab)?

The second means no code changes at all; the first means we can use this in the installation templates...

[ekohl]

I'm not sure it should be a "native" field because firewalld isn't really generic for every OS or even Linux so I'm leaning to parameter.

[jovandeginste]

Apparently, I can not access subnet parameters from the provisioning templates ...

There was an error rendering the [...]: The snippet '[...]' threw an error: undefined method '#parameters' for Subnet::Jail (Subnet::Ipv4)

(Which is correct according to the code):

class Subnet < ActiveRecord::Base
  [...]
  has_many :parameters, [....]
  [...]
  class Jail < ::Safemode::Jail
    allow :name, :network, :mask, :cidr, :title, :to_label, :gateway, :dns_primary, :dns_secondary,
          :vlanid, :boot_mode, :dhcp?, :nil?, :has_vlanid?, :dhcp_boot_mode?
  end 

Should this be changed?

[ares]

Normally we don't access parameters on specific subnet/domain/os etc but we check host parameters which contains parameters defined on these objects. You could do something like

<% zone = @host.params['firewall_zone'] || "public" %>
firewalld --zone <%= zone -%>

even if the parameter would be defined on host's subnet, it would be available in @host.params

[jovandeginste]

I don't see the subnet parameters when I print out the host's params; additionally, a host can have multiple interfaces, each in a different subnet, and thus each with a differnet value for firewall_zone (fyi, firewall zone is per interface, not per server). How would this work?

[ares]

They should be present there as long as the host is attached to the subnet. But you're right about multiple subnets, I think we only take the primary interface subnet into consideration.

Now I understand what you're trying to achieve. We'd need to add :parameters in subnet Jail as you suggest. The native, optional, free form text field on subnet would better indicate that firewalld could setup zones though. If we provide explanation in the field help, I think it would be better UX than defining custom parameter.

[jovandeginste]

Wat exactly do you mean by "The native, opotional, free form text field on subnet"? Something that does not yet exist?

[ares]

Yeah, your original question was should this ZONE parameter be a "native", so because of UX I'd lean towards the native field that we'd need to add instead of yet another custom parameter. Or adding some inline documentation in all "Parameters" tabs so users would know what parameters have special meaning.

[jovandeginste]

This has lingered for a long time; anyone care to decide which way to solve this?

[ares]

I'd still prefer a native field. But if you want to get it in fast, we added subnet_param to safemode long time ago (I think for this reason), so you can start using subnet parameters and access them in provisioning templates.

[lzap]

I think putting this as a native field into Subnet would be reasonable. Network interfaces and zones is a generally good concept available both in FirewallD and Windows systems. Having everything as a parameter is not the best experience, however I would only see added value when this was more integrated. For example, puppet/ansible modules to define those zones and only then picking a zone from it or something like that.

Adding the field just alone without any reasonable integration is probably not worth it. Then just stick with a parameter.

[jovandeginste]

The ZONE is a field in the ifcfg file. Does that count as reasonable integration?

[lzap]

I don't think so.

[tbrisker]

On behalf of the Foreman team, thank you for your contribution to the Foreman community templates repository! This repository is being archived and all templates are migrated to the relevant repositories. If you wish to pursue this issue, please re-open the issue against the relevant project in our issue tracker. For more information and background, please click here.