feature request: distributed firewall with attribute based access controls and policies via workload tags

[rolff]

Hey,

first of all thank you for a great product, which I've been using happily for about three years now in a home setting.

I've really enjoyed using the proxmox firewall which is configurable outside of the guest systems.
I'm also using local firewalls on the guest systems ('host based' sounds confusing in this context) to have multiple layers of defense in my firewall setup and have the layers reside in different attack planes. Ansible takes some of the boring out of that for me.

Having worked with vmware nsx in a commercial setting I'm very curious if there has been any thought or work around an implementation of the pve distributed firewall that uses attribute based access control (ABAC) with policies, implemented on the level of workloads that have a list of 'tags' (which are an attribute) attached to them.
these tags, when set on the vm configuration as metadata, will then be translated to the iptables implementation on the host.

This will allow the writing of 'policies' against these attributes that together constitute a simpler expression of the isolation you want to achieve between workloads.
It allows you to express intent of communication through policies and more natural language rather than (but not excluding) layer3/layer4 rules. Since an ip address or a port or a vm number, or a name is also an attribute of the workload, this can also be used in writing these policies


For example: tag three machines with [debian] and another with [repository] and yet another one with [git] and in the poiicy you can use {source:[debian,dmz], destination:[repository,git], action:allow, type: in-out} and have it translated to iptables implementation (or nftables? )
And voila, you now have three debian based linux machines that can now talk to their local apt mirror repository server for their software updates and also with a machine for git version control while other machines cannot (explicity deny).

Or, when you detect strange things happening coming from a system (eg via an IDS) you provision a tag on that machine of [sandbox] with a policy of {source: [sandbox], destination: *, action:deny, type:in-out} and there you go, the system is isolated from all machines and the internet.

I'm curious if there are any efforts ongoing. Or how I can possibly contribute here.. what is needed (general approach on how to solve/implement this)?

thanks

 

[dietmar]

I guess this feature is called "security groups":

https://pve.proxmox.com/wiki/Firewall#pve_firewall_security_groups

 

[rolff]

Hi @dietmar thanks, you can indeed use security groups to good effect and have the same type of result.
I guess the approach is just different to the one of VMware NSX, but that's ok of course.

There is a slight difference in that a security group is not an attribute of a vm, but also has 'policies' directly attached to it (you specify rule(s) per security group).
An attribute/tag of a vm can be used in multiple polices/rules, whereas a security groups implicitely is the policy.
So there is an indirection there and a tag is more of a functional classification in that regards, where you attach policies to the classification instead of directly to the vm.

A security group is 'attached' directly to the vm (and thus also the policies), so in essence there is no indirection as with tags where you would set a tag on a vm, and use the tag/vmname/id/etc to attach it to certain policies. The tag would create a 'dynamic' ipset (as an analogy to the ipsets in pve).

the security group webserver will be attached to a vm and then via the implicit policy would allow ingress on https.
in contrast, a tag 'webserver' would be attached to the vm and that tag will be coupled (not part of) a policy rule that would allow ingress on https, but can also be coupled to another policy rule that allows egress to a vm with tag 'database' (for example) where the policies would take

It would require different semantics on how the pve firewall is currently implemented. I can see that this is not needed because we can have the same functional result albeit in a slightly more convoluted way (don't take this as judgement please, I'd choose proxmox over vmware for personal use any day of the week).

The 'indirection' in an attribute based system is what makes it different. It would mean that we could reuse the attributes of vms in multiple policies/rules without having the policies directly attached to the workloads.
It would be the equivalent of having the ability to use pve firewall rules with dynamically created ipsets (ipsets are not dynamic in pve), since attaching an attribute to a vm would automatically include it in an 'dynamic ipset'

I guess that if ipsets could use attributes of vms (currently they support IP/CIDR ) then that would be a step closer to what I mean.

In any case, as said, we can reach the same functional result with the way pve fiewall is currently implemented through ipsets, aliases and the security groups.

RELATED?: the 6.1 release notes state this:
"General improvements for virtual guests

• Allow 'tags' in the guest configuration. This meta-information can be useful for things like configuration management (no GUI support yet)."