Cisco Application Centric Infrastructure (ACI) is Cisco’s software-defined data centre solution. It brings with it a number of benefits that provide a high-performance, programmable, scalable and resilient architecture on which to operate your enterprise workloads. But what does it bring to the table from a security perspective? This post will explore some of the benefits.
What is ACI?
As mentioned, ACI is Cisco’s software-defined data centre solution. It’s based upon certain models of Nexus switches to provide the networking hardware, and components known as Application Policy Infrastructure Controllers (APICs) to provide centralised and programmable management of the infrastructure fabric.
Like most modern data centres, ACI is based on a CLOS architecture which consists of “spines” and “leaves”. This is in comparison to more legacy three tier architecture of access, distribution and core (which you will still frequently find in the campus). What this all means is a high-performing, predictable and horizontally scaling architecture on which to layer your applications.
The APICs are at the heart of the solution. They are the components which manage the entire infrastructure in a software driven fashion. Everything in ACI is object orientated allowing for programmability and consistent re-use of configuration. The APICs are where you define everything relevant to the operation of your network.
An ACI architecture moves away from the traditional architecture of just subnets and VLANs and instead moves to a solution with an underlay and one or more overlays. What is meant by this?
- Underlay – Under the hood ACI operates a layer 3, routed network between all spines and leaves. Each leaf connects to all spines. There are no interconnects between spines or between leaves. This provides a fast-converging and predictable topology on which to build overlay networks.
- Overlay – All actual data traffic flows through one or more virtual overlay networks that run on top of the underlay. One of the key technologies heavily used to provide this virtual network approach is VXLAN. Overlays allow you to design your L2/L3 networks how you like, regardless of the actual location of an endpoint in the network.
I won’t get too much into the underlying mechanics of ACI in this post, but just take away from this brief intro that overlay networks allow you to build logical networks however you see fit without worrying about the underlying hardware and physical implementation. The overlay networks often provide features to help reduce a lot of the overheads of associated with traditional networks such as the “flood and learn” type approach to Broadcast, Unknown unicast and Multicast (BUM) traffic.
The diagram below illustrates at a high-level how a typical ACI deployment may look (not necessarily best-practice mind you – just an example!)
If you want to get a better understanding of ACI and what it is all about then the following tutorials are a good place to start (though a little old and possibly out of date in some respects now) – https://adamraffe.com/learning-aci/.
ACI has security builtin from the ground up. Everything about the solution is ideally geared towards a zero-trust and security driven architecture. Let’s look at some of the main components from a security standpoint.
As the name “ACI” gives away, the whole solution is geared towards defining your architecture and policies based on your applications. Take a typical three tier architecture of web, application and database. In legacy networks these may have all resided in different VLANs separated by firewalls (or perhaps they could just route freely!). The problem with this approach however is as the network grows, the solution doesn’t scale well and bottlenecks tend to appear.
ACI uses a concept known as Endpoint Groups (“EPGs”) to help define segmentation policies. Everything connecting into the data centre fabric is assigned to an EPG and by default no traffic is allowed to flow between two different EPGs unless there is a specific “contract” in place to allow it. This is obviously a significant step in helping you work towards a zero trust architecture within your data centre and flips traditional networking on its head (whereby everything could communicate unless explicitly blocked). This approach helps ensure security is considered from the outset of connecting devices to the network and provides granular segmentation capabilities within your data centre environment.
So what exactly is going on with a “contract”. Well in theory it is nothing more than a stateless ACL based on two EPGs (a “provider” of a service and a “consumer”). But what this gives you is a very fast, efficient and scalable way of carrying out basic filtering in your environment without needing to deploy additional security devices. Security is builtin to the switching fabric and traffic is denied unless otherwise permitted (by default anyway – don’t go disabling that setting eh!).
ACI provides a resilient and scalable underlay network for efficiently getting packets across the network, but then you are free to build your overlay networks on top exactly as you see fit without worrying about where devices are physically plugging in.
Many of your usual networking tools are still available at your disposal, but they perhaps have different names than you’re used to. They are ordered in a hierarchical parent-child type relationship. Some of the common components include:
- EPGS – As mentioned, EPGs provide a grouping of endpoints that need to be treated similarly from a policy perspective. These can then apply filtering even within the same layer two domain.
- Subnets – The same as they usually are – an IP subnet to provide addressing and routing. As mentioned below, one subnet could contain multiple EPGs
- Bridge Domain – A layer two construct, largely equivalent to a “VLAN” in a most peoples eyes. In ACI you can have one or more subnets reside in a bridge domain (technically the term “VLAN” is used for other purposes within ACI now).
- VRFs – Also known as contexts or private networks. Again, very similar to what you’d expect in a typical non-fabric network. ACI allows you to define multiple VRFs for segmentation and isolation even within an individual “tenant”.
- Tenant – The highest level in ACI that allows you to virtualise and isolate everything below it.
The main thing to take away here is that ACI offers flexibility to define the overlay networks how you want without worrying about how the physical infrastructure pieces together.
ACI allows for true multi-tenancy of the network. Multiple tenants can be defined in the solution, each tied to relevant Role-Based Access Controls (RBAC) and kept completely isolated from each other, whilst still leveraging the same physical infrastructure. Each can be given full control of their own environment, without impacting on the others operation.
Perhaps you have a production and test/dev environment, managed by different teams. How would you manage this with a legacy network? You could go down the route of completely different separate networks or perhaps bodge something together by restricting access levels and rights with TACACS – but it isn’t true multi-tenancy. Maybe you were already using features like VDCs in your NX-OS Nexus switches – great, but they have some restrictions and limitations that ACI removes.
In lots of networks I’ve seen over the year there is often one common factor in mistakes – humans! It’s easily done, especially when tasks are carried out manually. ACI on the other hand is an object driven solution and provides administrators with repeatable chunks of configuration which they can use over and over. This helps to remove configuration drift and inconsistencies and helps ensure the environment remains secure.
APIC also provides you with a single-source of truth. So if you need to validate your environment’s policies and settings you can do so in one place, confident the whole infrastructure is adhering to it. No more reviewing individual configurations in case of ad-hoc changes you didn’t know about.
As we’ve already covered, ACI provides stateless filtering of traffic between EPGs without the need for any external security devices.
But stateless firewalling isn’t enough – I want to do more detailed inspection of my traffic…
Enter something known as “service graphs”! Service graphs allow you to integrate your existing security services (firewalls/IPS) and Application Delivery Controllers (ADCs – A.K.A Load Balancers) in a variety of ways and send traffic to them accordingly.
There are two main things to consider – how is my traffic going to get to the service device and how is the service device going to be managed. ACI has support for both routed (“GoTo mode”) and transparent (“GoThrough mode”) deployments of service devices.
For the getting traffic to the service device ACI offers you two main options – stitching the service into your virtual overlay using bridge domains/VRFs etc. as necessary (much like you’d do with your traditional networks but without the hassle of working out where to physical connect things) or by using a policy-based redirect.
The second option – policy redirects – are particularly powerful and offer a great deal of flexibility. You may well decide most flows will be filtered by way of EPG contracts, but selectively choose to send certain flows to an advanced firewall for further inspection and protection. This prevents the need to send all traffic through the device when you don’t need to – great for performance and ensuring solutions can scale.
ACI (via the APICs and components known as device packages) also offers administrators options for managing the inserted service devices. Simply put the options are managed, partially managed and unmanaged. What this means in a nutshell is that you can actually use ACI to deploy things such as IP addressing and policies to your firewalls.
The partially managed option allows you to use ACI just to control the addressing (and dot1q tagging etc.) and unmanaged just leaves the device alone. Which you choose will obviously vary based on your needs and what integration the “device package” provides. Many security services come with their own central managers anyway and you’ll probably want to use these to get the most out of the solution.
What does the “unmanaged” provide you? From what I’ve seen there’s not much difference between unmanaged and just stitching the device into the solution as an endpoint without defining it as a L4-L7 device, the main benefit to adding it specifically as a L4-L7 device is that ACI knows about it and can report on it’s health (e.g. if a port goes down) as well as providing a graphical representation of how traffic flows through the device from an EPG to EPG point of view.
This post was obviously not an in-depth look at ACI, but hopefully it’s given you a bit of an insight into the technology and how it may be able to help you from a data centre perspective, particularly from a security point of view.
2019-02-13 00:00 +0000