Looking ahead to the next version of Firewall-as-a-Service in OpenStack

Introduction

At the Liberty summit in Vancouver, the networking team talked about the future of security groups and decided that instead of redesigning security groups to put that innovation into Firewall-as-a-Service (FWaaS) V2. The V2 API has been evolving over the subsequent releases.

The first step was to enable applying the Rules to L3 ports and also provide a means to specify the direction of traffic that needs firewalling. This puts the API more in line with traditional firewall models. Now with the Queens release, support for VM ports has been added. A notion of a Default FWG is supported, just as in security groups, to ensure security on bootup of a VM. You can find out more about the roadmap from the Summit session in Boston.

FWaaS V2 can run standalone or in combination with security groups. FWaaS V2 offers a rich API to describe rules for blocking, dropping, or accepting traffic as opposed to security groups who only have allow rules. FWaaS V2 also works on both router (L3) and VM ports (L2). It currently only works with OVS.

FWaaS V2 Building Blocks

FWaaS V2 distinguishes between egress and ingress policies which are assigned to a Firewall Group. Policies are made up of firewall rules. The Firewall Groups get assigned to router or vm ports and will handle traffic according to the rules in the policies.

For instance, a rule which allows ingress internet control message protocol (ICMP) traffic would look like:

Action	Protocol	ip-version	src-ip/port	dest-ip/port
allow	icmp	4	None	None

Similarly, if the action is “deny” or “reject” all ICMP won’t reach the port. Per default all traffic will be denied in both, ingress and egress, directions. A user has to explicitly allow traffic.

Let’s consider the following example:

Action	Protocol	ip-version	src-ip/port	dest-ip/port
allow	icmp	4	None	None
deny	icmp	4	None	None

In this example we have two rules: One allowing ICMP traffic and the other denying it. In this case, traffic will be allowed as the firewall rules are processed according to the order of rules.

Defense in depth

FWaaS V2 can run alongside security groups and an administrator could open all the IPs/ports they feel are safe in the network. This would allow users to focus on which ports/IPs are safe for their application. Vice versa, security groups could handle what’s safe for the app and FWaaS V2 with it’s deny rules could restrict that further.

Having two systems working with each other allows users to split concerns in a sane way and enables an in-depth defense. We’re hoping in a future version to have strata so users can’t change policies assigned by admins.

FWaaS V2 has some features like sharing of resources between tenants, an audit flag to quickly identify what needs to be reviewed and a default Firewall Group which works similar to the default security group. You can read more about it here.

Watch FWaaS V2 in action