Task #6681
Updated by Nico Schottelius almost 5 years ago
h2. General idea
Instead of relying on opennebula (limited firewalling support) and iptables (we prefer nftables), we should have a more dynamic firewall.
This should also enable us to delegate /64 networks faster to our customers.
The general concept is that there is a virtual machine manager, that decides/writes rules for all hypervisor hosts to a distributed store.
The hypervisor hosts then apply changes on themselves and have rules for all possible VMs, so migrations don't affect rules.
h2. General rules
* Install nft ruleset that blocks forwarding of everything by default
** Ensure that bridging is also affected!
h2. VM rules
* Install rule for mac address per interface
* Install rule for the primary IPv4/IPv6 address
h2. Network rules / routing
If the customer requested a /64 for her VM
* Install rule for the IPv6 network
* Install route for the IPv6 network
h2. Workflow
The distributed firewall queries the VMM for a list of VMs and their IP address in CIDR format and saves it into a decentralised kv store (details see below)
* When keys are added/deleted hosts will update their firewall
* We are using a custom chain / table only for allowing traffic to/from VMs
h2. Data format
Data in the decentralised store is stored as follows:
* distributed-firewall/vm/<vmid> as a JSON object
Format of the JSON object:
<pre>
'{"ipv6":
["2a0a:e5c1:111:b::/64",
"2a0a:e5c1:101:b::/64"
],
"ipv4": [
"185.203.112.1/32"
]
}'
</pre>
h2. Generalisation attempt
Instead of building a decentralised firewall only for us, we might be able to generalise:
* assume "any" k/v store with json objects
* assume there is some kind of watch/notification mechanism to be notified about "any update"
** basically a trigger
* Assume by default deny
** or policy based
* How to handle custom chains/tables?
** version 2