As we’ve just discussed, the physical and virtual firewalls are
really the same old firewall model, just in different form factors. The
distributed firewall, on the other hand, is when the firewall is no
longer a form factor at all, rather the “Firewall” is now embedded
as-a-service in the programmable hypervisor kernel networking stack. All
participating hypervisors collectively become one “Firewall”. Every
virtual server is connected to a hypervisor. By consequence, in this
model, every virtual server is directly connected to one omnipresent
“Firewall”. A firewall that knows everything about those virtual
servers. Sound familiar? ALL YOUR PACKET…
Every packet sent from a virtual machine can be inspected by the stateful firewall
service present in the hypervisor kernel, before the packet even
touches the network. Only after packets have been permitted through the
stateful “Firewall”, they hit a network built with any standard
networking equipment and architecture of choice. No need to steer traffic.
No need to compromise the network design. And every packet delivered to
a virtual machine can be inspected one last time by the same firewall
service, at the destination hypervisor, before the packet finally hits
the virtual NIC.
The distributed firewall security policy is centrally defined (via
API) through a notion of logical “containers”. Workloads are then placed
in containers programmatically, and the enforcement is programmed into
the hypervisor kernels. The security rules are based on container
membership – not based on IP addresses (although you can still do that
if you want). For example, things in container “Web” can talk to
container “App” on TCP port X, and so on. Of course this means the IP
address of your virtual machines can change, without changing the
security policy. And container membership can be static or dynamic,
programmed to trigger on just about any arbitrary metadata about the
workload; such as user identity, the presence of a virus, various
operating system characteristics, etc. Thus, security policy is decoupled from IP addressing.
The distributed firewall is multi-tenant and capable by virtue of its
presence in the hypervisor kernel. It’s attached directly to the
workloads and follows them wherever they go. Just place the workload in
its security container and you’re done. Every packet sent or received
flows through a stateful “Firewall”, and the security policy follows the
virtual machine when it migrates to another hypervisor. With a
distributed firewall, traffic steering is completely removed from the
process of implementing security policy – for the simple reason that
it’s directly connected to every virtual machine. In other words, security is omnipresent, at the very first and last hop.
With security decoupled from both traffic steering and IP addressing,
it becomes possible to consider more simplified, flatter application
architectures. For example, Web and App “tiers” could be on the same
network segment, separated by their container membership.
Deploying an App in a virtualized multi-tenant cloud? No problem! The
App owner just describes the desired security from one group of virtual
machines to another. No need to fumble around with virtual firewalls,
and the infrastructure owner can enforce certain enterprise policies
right at the first hop. And if the App is removed later on its
associated security rules are removed along with it.
Bottlenecks? Choke points? Not anymore. The distributed “Firewall”
performance scales out with the hypervisors. Meaning, the theoretical
throughput of the distributed firewall is some calculation of (number of
Hypervisor machines) * (Specs of each machine).
The auditor just showed up? No problem! Go to the central policy console and view everything in real time, in one place.
Despite all of its awesomeness, the distributed firewall is not the
firewall to end all other firewalls. The slam dunk deployment will be
for securing east-west traffic within and between tiers of a virtualized
application, Web > App, etc. and virtual server (or desktop) access
control. At the north most edge of an App architecture you might still
want a traditional physical or virtual firewall providing an additional
set of perimeter edge services, such as NAT, VPN, etc.
Distributed Firewall: Key Takeaways
- Directly connected to virtual machines
- No traffic steering
- Omnipresent security at the first and last hop
- Security implementation decoupled from network architecture
- Not a choke point
- Scale-out distributed kernel resident data plane
- No device to manage – Firewall as-a-service
- Centralized policy automated with APIs
- Security rules decoupled from IP addressing
- Workloads added to “containers”, with static or dynamic membership
- Security enforced based on container membership
- Ideal for east-west application traffic, and access control
- Stateful security that migrates with the workload
- May be combined with traditional physical or virtual firewalls in an overall solution
No comments:
Post a Comment