Evolution of Firewall-as-a-Service in OpenStack

Slide Note

The evolution of Firewall-as-a-Service (FWaaS) in OpenStack from version 1 to version 2 has seen significant improvements and refinements. The history of FWaaS, its refactor before the Tokyo summit, and the implementation of FWaaS v2 have all contributed to a more robust and feature-rich firewall service within the OpenStack ecosystem. From supported models to API enhancements, the journey of FWaaS showcases a commitment to enhancing network security capabilities within OpenStack.

chance Follow

Uploaded on Aug 04, 2024 | 1 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript

FWaaS v2: A New Beginning Sridar Kandaswamy Yushiro Furukawa Chandan Dutta Chowdhury

FWaaS History FWaaS v1 supported from Havana Deployment model on all routers. It was thought that some of Service insertion blueprints will define Point of insertion keeping it outside the feature. Refactor to user specified list of Routers in Kilo with no clear direction on Service Insertion at that point. Router ports was proposed but the Router approach was advocated as a first step. 2/ 24

FWaaS refactor again Just before the Tokyo summit, there was interest in rebooting FWaaS. Router port association Interest in VM (L2) Ports Security Groups (SG) simpler API, whitelist based approach Provide richer functionality with the FWaaS API Internal attack profiles Co-exist with SG Multiple layers of enforcement (Admin, Tenant Admin, User) 3/ 24

FWaaS v2 API available from Newton L3 support available Port based association Ingress, Egress can have different policies L2 support will be available shortly in Pike Same API as L3 OVS based (consistent with Neutron evolution for SG) 4/ 24

FWaaS v2 Resources Firewall Rule Filter spec (protocol, src IP, dst IP, src Port, dst Port, action (permit or deny) Firewall Policy Ordered Collection of Firewall Rules A Rule can be present in multiple Policies Firewall Group Collection of policies (ingress, egress) and port(s) (all attributes optional) A policy can be present in Multiple FWG (ingress or egress) A port can only be a part of a single FWG 6/ 24

Firewall Group Egress Policy Ingress Policy FWG Rules FWG Rules Associated L2 and L3 Ports 5/ 24

FWaaS v2 Implementation Data model Reference Plugin FWaaS L3 Agent using L3 Agent Extension Significant clean up of code avoiding inheritance model and dependency across L3 Services and L3 Agent. Driver Implementation based on iptables in namespace Router for L3 7/ 24

Neutron Stadium Requirements neutron integration Continuous Integration (CI) Release Footprint Stable backports Client Library 19/ 24

FWaaS L2 Implementation Main issue on coexistence with SG on the iptables based implementation causing delays. Discussion in ATL PTG direction to move to an ovs based implementation in alignment with SG. Much cleaner approach Team is testing the implementation and coexistence with SG Patches in early review Target merge in few weeks this is the priority and focus for Pike 9/ 26

FWaaS L2 Agent Handles following events: Event Triggered method Port create/update handle_port ( ) with L2 agent extension Port delete delete_port( ) with L2 agent extension Firewall Group create create_firewall_group( ) for Plugin RPC callback Firewall Group update update_firewall_group( ) for Plugin RPC callback Firewall Group delete delete_firewall_group( ) for Plugin RPC callback 10/ 26

FWaaS L2 Agent Handles following events: Event Triggered method Port create/update handle_port ( ) with L2 agent extension That is VM port = On VM create/delete Port delete delete_port( ) with L2 agent extension Firewall Group create create_firewall_group( ) for Plugin RPC callback Firewall Group update update_firewall_group( ) for Plugin RPC callback That is On User updates Firewall Group delete delete_firewall_group( ) for Plugin RPC callback 11/ 26

CRUD Workflow with L2 Agent (1/2) On VM Create L2 agent extension: handle_port() is called Validate whether a port is VM port or not ( compute:foo in device_owner field) A default FWG will be applied before VM booting. On VM Delete L2 agent extension: delete_port() is called Validate whether a port is VM port or not ( compute:foo in device_owner field) Firewall rule will be removed from the port. 12/ 26

CRUD Workflow with L2 Agent (2/2) On User Updates Create Firewall Group If ports is specified, firewall rule will be applied. Update Firewall Group If ports is specified, firewall rule will be updated. If no ports are associated with user defined FWG, these ports are applied to default FWG. Delete Firewall Group If ports were specified, firewall rule will be removed from specified ports. Default FWG will be applied for these ports. 13/ 26

Default FWG Project wide Rule spec on Default FWG Ingress (to VM) deny all Egress (from VM) permit all When a VM comes up the VM port is associated with Default FWG If a User Defined FWG is deleted or disassociated from a VM port Default FWG is applied VM VM Port Port Default FWG Port Port VM VM 14/ 26

FWaaS OVS L2 Driver Overview OVS flow rules are mapped into tables FWaaS OVS driver is implemented using 5 tables [based on SG OVS driver model] Currently we use tables 41,42,43,51 and 52 associated with OVS integration bridge (br-int) Table 41: Base Egress Table Table 42: Egress Rules Table Table 43: Accept or Ingress Table Table 51: Base Ingress Table Table 52: Ingress Rules Table Packets are segregated into Ingress and Egress flows depending on the port of arrival Br-Int Traffic to/from other hypervisor VM1 VM2 Traffic within the same hypervisor 13/ 24

FWaaS L2 Driver Egress Tables Tables 41 is the base Egress table and contains basic rules like allow ICMP, ARP and DHCP traffic. Also contains rules to prevent MAC spoofing Actual user defined rules are populated in Table 42 (Egress Rule Table) and are used to forward the packets to Table 43 (Accept or Forward Table) 14/ 24

FWaaS L2 Driver Accept Table Tables 43 contains rules to accept a packet or forward it to the Table 51(Base Ingress table) to target traffic flow within the hypervisor Table 42 creates conntrack entries for established connection while Table 43 creates conntrack for new connection. 15/ 24

FWaaS L2 Driver Ingress Tables Tables 51 and 52 are ingress replica of table 41 and 42 In addition registers 5 is used to hold bridge port no on which the packet arrived and register 6 is used to track the virtual network of the packet. The value in register 6 is use to create conntrack entries for different zones. Current Status Debugging issues with port updates and default Firewall group Working on Co Existence with SG Driver 16/ 24

FWaaS Dashboard In demo quality More refinements, cleanup and UT WIP Target for Pike 17/ 24

Demo 18/ 24

FWaaS Roadmap Pike Priorities L2 Support (High) Horizon Dashboard (High) Improve stability with more Tests (High) Perf Improvement (High Medium) RPC improvements Conntrack (Netlink) Done for FWaaS v1 Refactoring for better integration with ODL (Medium) Firewall Rule Logging/Hit Counters (Low) 20/ 24

FWaaS Priorities Queens Priorities Spillover from Pike Vendor Integration Firewall Zones Common Classifier SFC Multiple Layers/Roles/Strata L4 L7 Rules 21/ 24