Intro to Security with Cisco ACI

This article will by no means be a complete review of the security in Cisco’s Application Centric Infrastructure solution. What I’ll be concentrating on in this blog is the built in security you get with ACI as well as the security you’ll get in your virtual environment when you use ACI along with Application Virtual Switch, or the AVS. The AVS is a Cisco product that looks and feels like a Distributed Virtual Switch in your virtual environment, for example in vSphere vCenter. Also, I’m writing this prior to a large launch, on December 3rd 2015. So, while the information in this article will still be true and pertinent, there will be a lot of improvements and changes to security in ACI.

So, let’s start with the idea of micro-segmentation. Micro-segmentation is a buzzword that’s been thrown around, but it does have some merit. Essentially for the last several years, we’ve been protecting the networking at the perimeter mostly because our traffic has been mostly north/south traffic (coming from the outside, down to a server, and back out again). However, our east/west traffic has increased enormously (traffic going between servers) because of the introduction of virtual machines. Perimeter security is still absolutely necessary, but we also need internal security. For example, if a VM or server gets attacked or owned we need to ensure that it will not be able to attack other servers or VMs in our environment, specifically in our Trust, Internal, or whatever you call that zone in your network.

Micro-segmentation essentially means we want to create smaller security zones (groups of servers, a single VM, or even a container) in our networks and of course we want to do this easily. As we all know, adding more security can often mean reducing agility, but with a great product where security is built in we don’t have to sacrifice functionality. With ACI we have the concept of End Point Groups, or EPGs. Because ACI is a whitelist model there is essentially a stateless firewall between all EPGs by default. So you have to actually create a policy, or contract, to allow certain kinds of traffic between them. You may also place things like virtual ports in EPGs so that your management, IP storage, fault tolerance, and other portgroups are also protected.

EPGs can be created using the following:

  • VLANs
  • Virtual Port Groups
  • Physical Ports
  • IP Addresses
  • DNS Names
  • *VM Attributes

EPGs don’t necessarily give us isolated VMs, though, unless we were to put each VM in a different EPG. So, in order to offer this level of micro-segmentation we can now use *VM Attributes to create EPGs, and even create them dynamically.

VM Attributes Used to Create EPGs:

  • Layer 4 Ports and Protocols
  • Guest OS
  • VM Name
  • VM (ID)
  • VNIC (ID)
  • Hypervisor
  • AVS Port Group
  • AVS
  • Datacenter
  • MAC Sets
  • IP Sets

How does this work?

Let’s take the example of VMware vSphere. ACI uses open APIs in vSphere to find a specified attribute and then place the VM with that attribute (such as VM Name) in a particular EPG. This can only be done currently using the Cisco AVS. So the ACI admin will do this on the Application Policy Infrastructure Controller, or APIC, as they would for any other EPG.

Figure 1

In the picture above, I show an EPG being created through the use of VM attributes. I call the EPG Finance-Web, specify that the VM attribute we’ll be using is VM Name, and specify that any VM Name containing the word Finance will be automatically put into the Finance-Web EPG. Now we can apply policies to that EPG as we would with any other EPG.

The ACI admin will control the policy for the VMs now, but this will not disrupt the setup the vSphere admin has because the VM will actually stay in its original port group. Perhaps you wouldn’t want it in its original port group, though, because port groups can become cumbersome to maintain. You have to keep track of VLANs and other encapsulation protocols. With the use of VM Attribute EPGs, you could actually have one base port group (or maybe a few base port groups if you prefer). Because ACI separates identity from location, it doesn’t matter where these VMs reside. Policy will be attached to them according to the EPG in which they’re assigned.

Stateless vs. Stateful

Above I mentioned that ACI is a whitelist model, using stateless firewalling built-in between all EPGs. This basically means that traffic will get blocked automatically but there is no deep packet inspection in traffic between end points in different EPGs. However, if we’re using the AVS, we can now turn on stateful firewalling.

How does this work?

We use contracts in ACI to provide policy. If we want to allow (remember usually we’re allowing traffic, because it’s a whitelist model) https between two EPGs we create a contract and assign it to the EPGs where it’s necessary. In this case, when we’re using the AVS, we can simply click a button to toggle on Stateful firewalling. This feature is called a Distributed Firewall in ACI.

Figure 2

In the picture above, I’m showing how to create a filter within a contract. The filter will allow HTTP traffic between whichever two EPGs to which I assign it. I’ve toggled on the Stateful button so there will be stateful packet inspection as well. Even better, I can actually copy this contract and place it between two other EPGs in a matter of seconds with no human error.

Can I use regular firewalls?

The question I always get: can people only use our contracts to protect their data? No, this is just what’s built in to ACI to make it spectacularly secure. You can, and likely will, also include firewalls (virtual or physical, from multiple vendors) to protect your data in some cases. As I mentioned before, we still need perimeter security and you’ll likely have a physical firewall, which can be controlled through the APIC, in your network. You may also want to put them between your internal EPGs, along with other Layer 4-7 services. In ACI we call this service graphing. If you need a firewall and load balancer in between your Application and Database servers, for example, you can do this with ACI. As I mentioned above with contracts, it’s also fairly simple to copy these service graphs and automatically put them between two other EPGs as well…again in a few minutes with no human error!

Disclaimer: Lauren Malhoit works for Cisco, specifically on ACI.

Update: Here are some of the announcements made about ACI on December 3rd, 2015.

If you have any questions or comments feel free to leave them below or reach out to me on Twitter @Malhoit.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top