Computer case

Openstack Neutron Security Groups

 

 

OpenStack Neutron Security Groups

OpenStack Neutron is a powerful networking service crucial in managing network connectivity for OpenStack-based cloud environments. OpenStack Neutron Security Groups stand out as a critical feature among its various components. In this blog post, we will delve into the significance of OpenStack Neutron Security Groups and understand how they contribute to enhancing the security of cloud deployments.

OpenStack Neutron Security Groups serve as virtual firewalls, controlling inbound and outbound traffic for instances within an OpenStack cloud. They are an essential aspect of network security, allowing administrators to define and enforce access rules for different types of network traffic.

 

Highlights: OpenStack Neutron Security Groups

  • Network-as-a-Service

The power of open-source cloud environments is driven by Liberty OpenStack and the Neutron networks forming network-as-a-service. OpenStack can now be used with many advanced technologies – Kubernetes network namespace, Clustering, and Docker Container Networking. By default, Neutron handles all the networking aspects for OpenStack cloud deployments and allows the creation of network objects such as routers, subnets, and ports.

For example, Neutron creates three subnets and defines the conditions for tier interaction with a standard multi-tier application with a front, middle, and backend tier. The filtering is done centrally or distributed with tenant-level firewall OpenStack security groups.

  • OpenStack is Modular

OpenStack is very modular, which allows it to be enhanced by commercial and open-source network technologies. The plugin architecture allows different vendors to enhance networking and security with advanced routers, switches, and SDN controllers. Every OpenStack component manages a resource made available and virtualized to the user as a consumable service, creating a network or permitting traffic with ingress/egress rule chains. Everything is done in software – a powerful abstraction for cloud environments.

 



Openstack Security Group.

Key OpenStack Neutron Security Groups Discussion points:


  • Introduction to OpenStack Neutron Security Groups.

  • Discussion on the control, network, and compute components.

  • Neutron components and connectivity.

  • Discssion on Linux and agents.

 

For pre-information, you may find the following helpful

  1. OpenStack Architecture
  2. Application Aware Networking

 

Back to Basics With OpenStack Neutron Security Groups

Security Groups

Security groups are essential for maintaining access to instances by permitting users to create inbound and outbound rules that restrict traffic to and from models based on specific addresses, ports, protocols, and even other security groups.

Neutron creates default security groups for every project, allowing all outbound communication and restricting inbound communication to instances in the same default security group. Following security groups are locked down even further, allowing only outbound communication and not allowing any inbound traffic at all unless modified by the user.

 

Benefits of OpenStack Neutron Security Groups:

1. Granular Control: With OpenStack Neutron Security Groups, administrators can define specific rules to control traffic flow at the instance level. This granular control enables the implementation of stricter security measures, ensuring that only authorized traffic is allowed.

2. Enhanced Security: By utilizing OpenStack Neutron Security Groups, organizations can strengthen the security posture of their cloud environments. Security Groups help mitigate risks by preventing unauthorized access, reducing the surface area for potential attacks, and minimizing the impact of security breaches.

3. Simplified Management: OpenStack Neutron Security Groups offer a centralized approach to managing network security. Administrators can define and manage security rules across multiple instances, making enforcing consistent security policies throughout the cloud infrastructure easier.

4. Dynamic Adaptability: OpenStack Neutron Security Groups allow dynamic adaptation to changing network requirements. As instances are created or terminated, security rules can be automatically applied or removed, ensuring that security policies remain up-to-date and aligned with the evolving infrastructure.

Implementation Example:

To illustrate the practical implementation of OpenStack Neutron Security Groups, let’s consider a scenario where an organization wants to deploy a multi-tier web application in its OpenStack cloud. They can create separate security groups for each tier, such as web servers, application servers, and database servers, with specific access rules for each group. This segregation ensures that traffic is restricted to only the necessary ports and protocols, reducing the attack surface and enhancing overall security.

 

OpenStack Neutron Security Groups: The Components

Control, Network, and Compute

The OpenStack architecture for network-as-a-service Neutron-based clouds divides into Control, Network, and Compute components. At a very high level, the control tier runs the Application Programming Interfaces (API), compute is the actual hypervisor with various agents, and the network component provides network service control.

All these components use a database and message bus. Examples of a database include MySQL, PostgreSQL, and MariaDB; for message bus, we have, for example, RabbitMQ and Qpid. The default plugins are Modular Layer 2 (ML2) and Open vSwitch. 

Openstack Neutron Security Groups

Ports, Networks, and Subnets

Neutrons’ network-as-a-service core and the base for the API are elementary. It consists of Ports, Networks, and Subnets. Ports hold the IP and MAC address and define how a VM connects to the network. They are an abstraction for VM connectivity.

A network is a Layer 2 broadcast domain, represented as an external network (reachable from the internet), provider network (mapped to an existing network), and tenant network, created by cloud users, isolated from other tenant networks. Layer 3 routers connect networks; subnets are the subnet spaces attached to networks.

 

OpenStack Neutron: Components

OpenStack networking with Neutron provides an API to create various network objects. This powerful abstraction allows the creation of networks in software and the ability to attach multiple subnets to a single network. The Neutron Network is isolated or connected with Layer 3 routers for inter-network connectivity.

Neutron employs the concepts of floating IP, best understood as a 1:1 NAT translation. The term “floating” comes from the fact that it can be modified on the fly between instances.

It may seem that floating IPs are assigned to instances but are assigned to ports. Everything gets assigned to ports – fixed IP, Security Groups, and MAC addresses. SNAT (source NAT) or DNAT (destination NAT) enables inbound and outbound to and from tenants. DNAT modifies the IP address of the destination in the IP packet header, and SNAT modifies the sender’s IP address in IP packets. 

 

Open vSwitch and the Linux bridge

Neutron can be integrated for switching functionality with Open vSwitch and Linux bridge. By default, it integrates with the ML2 plugin and Open vSwitch. Open vSwitch, and Linux bridges are virtual switches orchestrating the network infrastructure.

For enhanced networking, the virtual switch can be controlled outside Neutron by 3rd party network products and SDN controllers via plugins. The Open vSwitch may also be replaced or used in parallel. Recently, there have been many enhancements to the classic forwarding with Open vSwitch and Linux Bridge.

We now have numerous high availability options with L3 High Availability & VRRP and Distributed Virtual Routing (DVR) feature. DVR essentially moves to route from the Layer 3 agent to compute nodes. However, it only works with tunnels, and L2pop enabled, requiring the compute nodes to have external network connectivity.

For production environments, these HA features are a welcomed update. The following shows three bridges created in Open vSwitch – br-ex, br-ens3, and br-int. The br-int is the main integration bridge; all others connect via particular patch ports.

 

Openstack Neutron Security Groups

 

Network-as-a-service and agents

Neutron has several parts backed by a relationship database. The Neutron server is the API, and the RPC service talks to the agents (L2 agent, L3 agent, DHCP agent, etc.) via the message queue. The Layer 2 agent runs on the compute and communicates with the Neutron server with RPC. Some deployments don’t have an L2 agent, for example, if you are using an SDN controller.

Also, if deploying the Linux bridge instead of the Open vSwitch, you wouldn’t have the Open vSwitch agent; instead, use the standard Linux Bridge utilities. The Layer 3 agent runs on the Neutron network node and uses Linux namespaces to implement multiple copies of the IP stack. It also runs the metadata agent and supports static routing. 

 

Linux Namespaces

An integral part of Neutron networking is the Linux namespace for object isolation. Namespaces enable multi-tenancy and allow overlapping IP address assignment for tenants – an essential requirement for many cloud environments. Every network and network service a user creates is a namespace.

For example, the qdhcp namespace represents the DHCP services, qrouter namespace represents the router namespace and the qlbaas represents the load balance service based on HAProxy. The qrouter namespaces provide routing amongst networks – north-south and east-west traffic. It also performs SNAT and DNAT in classic non-DVR scenarios. For certain cases with DVR, the snat namespaces perform SNAT for north-south network traffic.

 

OpenStack Neutron Security Groups

OpenStack has the concept of OpenStack Neutron Security Groups. They are a tenant-level firewall enabling Neutron to provide distributed security filtering. Due to the limitations of Open vSwitch and iptables, the Linux bridge controls the security groups. Neutron security groups are not directly added to the Integration bridge. Instead, they are implemented on the Linux bridge that connects to the integrated bridge.

The reliance on the Linux bridge stems from Neutron’s inability to place iptable rules on tap interfaces connected to the Open vSwitch. Once a Security Group has been applied to the Neutron port, the rules are translated into iptable rules, which are then applied to the node hosting the respective instance.

Neutron also can protect instances with perimeter firewalls, known as Firewall-as-a-service.

Firewall rules implemented with perimeter firewalls utilizing iptables within a Neutron routers namespace instead of configuring on every compute host. The following diagram displays ingress and egress rules for the default security group. Tenants that don’t have a security group are placed in the default security group.

 

Openstack Neutron Security Groups

 

Conclusion:

OpenStack Neutron Security Groups offer a robust solution for managing network security in OpenStack-based cloud environments. By providing granular control, enhanced security, simplified management, and dynamic adaptability, they contribute significantly to safeguarding cloud deployments. As organizations continue to embrace the benefits of OpenStack, leveraging the power of Neutron Security Groups becomes paramount in building secure and resilient cloud infrastructures.