The document provides guidelines and best practices for deploying Cisco® Virtual Security Gateway.
Some of the major topics covered in the document are architecture design components required for building a secured, virtual computing environment, interaction between components such as Vmware vCenter, Cisco Virtual Supervisor Module for the Cisco Nexus® 1000V Series Switches (VSM), Cisco Virtual Security Gateway (VSG), Cisco Virtual Network Management Center (VNMC), and deployment considerations and design best practices.
Cisco Virtual Security Gateway (VSG) is a virtual firewall for Cisco Nexus 1000V Series Switches that delivers security and compliance for virtual computing environments. Cisco VSG uses virtual network service data path (vPath) technology embedded in the Cisco Nexus 1000V Series Virtual Ethernet Module (VEM), offering transparent insertion and efficient deployment. The VSG solution allows IT security, network, and server teams to collaborate and help to ensure administrative segregation to meet regulatory and audit requirements. This also reduces administrator errors. VSG also introduces the Cisco Virtual Network Management Center (VNMC) which manages VSG(s) in a multitenant environment.
Benefits
Cisco VSG provides controls at the virtual machine (VM) level, using VM attributes, so that context-based policies can be applied. These policies are VLAN-agnostic, and can be applied to zones of virtual machines, thereby providing topology-invariant, policy-driven security controls. Traffic from external sources to the VMs and from VM to VM can be protected. The following sections describe some of the key benefits of deploying VSGs in a virtualized environment.
Dynamic (Virtualization-Aware) Operation
Virtualization can be highly dynamic, with frequent add, delete, and change operations on virtual machines. Live migration of virtual machines occurs through VMware's manual vMotion or Distributed Resource Scheduler (DRS) events.
Cisco VSG, operating in conjunction with the Cisco Nexus 1000V Series (and vPath), supports dynamic virtualization. Trust zones and associated security profiles for each line of business or tenant are created with the Cisco VSG and the Cisco VNMC. Security profiles are bound to Cisco Nexus 1000V Series port profiles (authored on the Cisco Nexus 1000V Series Virtual Supervisor Module [VSM] and published to VMware vCenter). When a new virtual machine is instantiated, the server administrator assigns the appropriate port profile to the virtual machine's virtual Ethernet port. The port and security profiles and the virtual machine's zone membership are immediately applied. A virtual machine can be repurposed simply by assigning different port and security profiles.
Nondisruptive Operational Model
With the introduction of the Cisco Nexus 1000V Series, Cisco VSG provides seamless integration with VMware vCenter. The operational model is still intact, in which the security administrators define the security rules and policies, the network administrators manage those policies and associate them with a particular port profile, and the ESX server administrators select the appropriate port group (the Cisco Nexus 1000V equivalent of a port profile) for the particular VM. Figure 1 depicts this operational model.
Figure 1. Administrative Segregation Between Server, Network, and Security Administrators
The tight integration with vCenter allows for the seamless and dynamic provisioning of port profiles and security policies to the virtual machines.
Multitenancy
Cisco VNMC is designed to manage Cisco VSG and security policies in a dense, multitenant environment, so that administrators can rapidly add and delete tenants and update tenant-specific configurations and security policies. Figure 2 depicts the multitenant deployment of VSG. In the architecture shown in the figure, Tenant A has its own VSG that provides security policies for its VMs. Tenant B has its own, separate VSG to manage its security policies for its VMs.
Figure 2. Multitenant Deployment with VSG Solution
Solution Architecture
Figure 3 shows the overall architecture of the Cisco VSG solution and the integration of the required components in the solution. This section covers the details of the communications across these components.
Figure 3. VSG Solution Architecture
Solution Components
The following components are required to set up the VSG environment.
Cisco Virtual Network Management Center (VNMC)
Cisco VNMC is a virtual appliance for centralized device and security policy management of the Cisco VSG.
Cisco Virtual Security Gateway (VSG)
Cisco VSG operates with the Cisco Nexus 1000V Series distributed virtual switch in VMware vSphere hypervisor, and it uses the vPath embedded in the Cisco Nexus 1000V Series VEM.
Cisco Nexus 1000V Series Switches
Cisco Nexus 1000V Series Switches are virtual machine access switches that are an intelligent software switch implementation for VMware vSphere environments running Cisco NX-OS. To support the Cisco VSG solution, the Cisco Nexus 1000V must be running Version 1.4 or later.
VMware vCenter
VMware vCenter Server manages the vSphere environment and provides unified management of all the hosts and VMs in the data center from a single console. You will need vCenter 4.0 and 4.1 with the Enterprise Plus license. To support vCenter 5.0 and ESXi 5.0, you will need Cisco Nexus 1000V Series Version 1.4a or later, VSG Version 1.3, and VNMC Version 1.3.
VNMC-to-vCenter Communications
Cisco VNMC registers to vCenter for visibility into the VMware environment. This allows the security administrator to define the policies based on the VMware VM attributes. VNMC integrates via an XML plug-in. The process is similar to the way the Cisco Nexus 1000V VSM integrates with vCenter. VNMC and vCenter communicate over a Secure Sockets Layer (SSL) connection on port 443 (see Figure 4). There is no specific network limitation for the communications between VNMC and vCenter, other than that the appropriate ports be open if there is a firewall between them.
Figure 4. VNMC-to-vCenter Communications
VNMC-to-VSG Communications
VSG registers to VNMC via the policy agent configuration done on VSG. Once registered, VNMC pushes the security and device polices to VSG. No policy configuration is done via the VSG command-line interface (CLI) once it is registered to VNMC. The CLI is available to the administrator for monitoring and troubleshooting purposes. Communications between VSG and VNMC take place over an SSL connection on port 443 (Figure 5).
Figure 5. VNMC-to-VSG Communications
VNMC-to-VSM Communications
VSM registers to VNMC via the policy agent configuration done on VSM. The steps to register are similar to those for VSG-to-VNMC registration. Once registered, VSM can send IP-to-VM binding to VNMC. IP-to-VM mapping is required by the VSG for evaluating policies that are based on VM attributes. VSM also resolves the security-profile ID using VNMC. This security-profile ID is sent in every vPath packet (discussed in the next section) to VSG and is used to identify the policy for evaluation. The communications between VSM and VNMC are supported over an SSL connection on port 443 (Figure 6).
Figure 6. VNMC-to-VSM Communications
VSG-to-VEM (vPath) Communications
VSG receives traffic from VEM when protection is enabled on a port profile. The redirection of the traffic occurs via vPath. vPath encapsulates the original packet and sends it to VSG. VSG has a dedicated interface (Data 0) with an IP address configured for this interface. When configured in Layer 2 mode, VEM obtains the VSG's MAC address by performing Address Resolution Protocol (ARP) to that IP address. From VSG Version 1.3 onward, Cisco VSG is no longer required to be Layer 2 adjacent to vPath. VEM needs IP reachability only to the tenant-specific VSG to redirect traffic from vPath to VSG for policy evaluation. VSG evaluates policies on the first packet of each flow that is redirected by vPath. VSG then transmits the policy evaluation results to vPath. vPath maintains the result in the flow table, and subsequent packets of the flow are permitted or denied based on the result cached in the flow table (Figure 7).
Figure 7. VSG-to-VEM Communications
vPath maintains the state of the TCP flows. In the event of reset (RST) or a finish (FIN) flag in the TCP flow, vPath purges the entry of that flow from the table. Inactivity of any flow will also result in clearing the entry in the flow table.
VSG supports stateful protocols, such as FTP, Trivial File Transfer Protocol (TFTP), and Remote Shell (RSH) Protocol. Future versions will support more stateful protocols, starting with the ones most relevant to a data center environment.
VSM-to-VEM Communications
There are two ways of connecting the VSM and the VEM:
• Over Layer 2: If the VSM and VEM are in the same Layer 2 domain, the best way to connect them is to use the Layer 2 connectivity mode.
• Over Layer 3: If the VSM and VEM are in different Layer 2 domains, the Layer 3 connectivity mode should be used. The Layer 3 mode will encapsulate the packet of the Layer 2 mode using Generic Routing Encapsulation (GRE). All communications between the VSM and VEM are encrypted using a 128-bit algorithm. The VSG implementation is independent of VSM-to-VEM communication (whether in Layer 2 or Layer 3 mode).
Figure 8. VSM-to-VEM Communications
VXLAN
Starting with Cisco Nexus Version 4.2(1)SV1(5), the Cisco Nexus 1000V Series will support Virtual Extensible LAN (VXLAN) technology with a 24-bit LAN segment identifier to provide segmentation at cloud scale. Starting from VSG Version 1.3, vPath will be able to secure virtual machines configured as part of VXLAN. Since the VXLAN header is decapsulated on a VEM, vPath does not need the VXLAN reachability information to make decisions on either rerouting packets to VSG or to permit/deny traffic based on the configured security policy. Currently VSG interfaces cannot be added into a VXLAN. This feature will be supported in future releases.
VSG Deployment Considerations
This section covers various aspects of Cisco VSG deployment in your network.
Cisco Nexus 1000V Series Infrastructure
Before installing Cisco VSG, you are required to install Cisco Nexus 1000V Series Software Version 4.2(1) SV1(4) in your environment and perform the basic configuration of the Cisco Nexus 1000V Series Switch. This will include the following:
• Installing and configuring the Virtual Supervisor Module (VSM)
• Providing access to shared storage
• Creating the necessary port profiles, including
– Uplink port profiles
– VMkernel port profiles
– VM-data port profiles
• Registering the VSM to vCenter
• Installing two or more Virtual Ethernet Modules (VEM)
• Adding the VEMs to the VSM
This deployment guide will not go into the details of how to install and deploy the Cisco Nexus 1000V Series. Please refer to the Cisco Nexus 1000V Deployment Guide for this information.
Note: The vPath feature is available on VEMs beginning with release 1.4.
Setup Requirements
Cisco VSG uses three network interfaces in the following order:
1. VSG Data interface
2. VSG Management interface
3. VSG High Availability (HA) interface
Create additional VLANs for VSG Data and HA on VSM and allow the VLANs to forward on the system uplink(s). Create these VLANs on the upstream switch. You can have the same VLAN for both the HA and Data interfaces, depending on the utilization of the Data interface.
The existing management VLAN in your setup can be used to manage VSG.
We recommend that you use the Open Virtual Appliance (OVA) for the VSG installation, which allows simplified installation. Since VNMC is the centralized management center for VSG, it will be located in your management VLAN. There are no specific network requirements for setting up VNMC. Please refer to the quick start guide for the steps to deploy the VNMC.
Installation and Initial Setup
Please refer to Part 1 of the VSG/VNMC Installation Guide to do the following (Figure 9):
1. Install the VNMC as a virtual appliance.
2. Install the VSG as a virtual appliance.
3. Register VSG to VNMC.
4. Register VSM to VNMC.
5. Register VNMC to vCenter.
Figure 9. Initial Setup of VSG and VNMC
After completing these tasks, you should be ready to start defining and implementing the policies for VSG. Figure 10 shows a typical network with all the necessary components in place for the VSG solution.
Figure 10. Network Topology with Cisco Nexus 1000V Series, VSG, and VNMC
Enabling the Firewall
To insert the firewall into the network, you need to attach the security profile to the port profile. All the traffic traversing through the virtual ports associated with that port profile is subjected to policy evaluation. The following commands turn on the firewall feature under the port profile:
The first command specifies the tenant where the firewall is enabled. The second command binds a specific VSG and security profile to the port profile. It enables the vPath to redirect the traffic to the VSG in the service VLAN. The third command can be used in place of the second command for Layer 3 communication between the vPath and VSG.
License Requirement
A VSG License is per CPU and follows the same model as the licensing for the Cisco Nexus 1000V Series. Each CPU requires one license, and there is no limit on the number of cores per CPU. The key point to note is that the licenses need to be installed on the VSM and not on the VSG. Since the licenses are based on physical host sockets, you can instantiate VSGs in a scale-out model without worrying about licenses. You must purchase enough licensing capacity to cover all installed CPUs. Licenses are not applied to a VEM unless the existing license has the capacity to cover all of its CPUs. Please refer to the licensing guide for the steps you need to take to install the license.
The licenses for Cisco VSG are floating. Once you install the licenses on the VSM, they are not applied to all the VEMs by default. VSG applies the licenses only to those VEMs that are hosting the protected VMs. The Cisco Nexus 1000V Series Release 1.4 software comes with a 60-day evaluation license for VSG.
Network Segmentation
VSG is a transparent firewall inserted at Layer 2 and acts like a "bump in the wire." It is not seen as a Layer 3 hop to connected devices. Inserting a Cisco VSG into the network do not warrant any reengineering of the existing network.
VNMC supports overlapping network space for a multitenant environment. This means that if your network segmentation exists that allows overlapping IP space (such virtual route forwarding [VRF]-Lite), VNMC will allow you to build policies for each tenant with overlapping networks.
Service VLAN MTU Size
Starting from Version 1.3, VSG can be either Layer 2 or Layer 3 adjacent to VEM. vPath intercepts the first packet of the flow and encapsulates the original packet with an additional vPath header. When the VSG to VEM connectivity is Layer 2, it increases the frame size by 74 bytes. With Layer 3 connectivity between VSG and VEM, the increase in payload will be 94 bytes.
For Layer 2 mode, vPath performs fragmentation if the encapsulated packet exceeds the outgoing interface MTU. Typically, this overhead will not affect TCP flows. It will not be subjected to fragmentation since the first packet of any TCP flow is a SYN packet, which will not be subjected to fragmentation after vPath encapsulation. You may see fragmentation with User Datagram Protocol (UDP) flows in which the packet is already 1500 bytes when it is intercepted by vPath. To avoid fragmentation, you can increase the MTU by an additional 74 bytes on the uplink port profile configured in Cisco Nexus 1000V Series and on the upstream physical switch to which other physical hosts are connected.
With Layer 3 connectivity between VSG and VEM, the payload increase is 94 bytes. In Layer 3 mode, vPath does not support fragmentation. So if the new packet size after adding the 94byte data is more than the outgoing interface MTU.Packet will be dropped and an ICMP (Error Code = 4) will be sent back to source.
Note: In VSG Layer 3 mode, IP fragmentation is not supported on VEM vmnic for traffic leaving the ESX/ESXi host. Hence, after the vPath encapsulation, if an IP packet is received by a VEM from a VM with a packet size greater than the outgoing interface MTU, it will be dropped and an ICMP "Error Code =4" message will be sent back to the source virtual machine.To avoid packet drops in this scenario, increase the outgoing server port MTU by 94 bytes. For example, if the MTU values of client and server VMs and uplink are all 1500 bytes, set the uplink MTU to 1594 bytes.
High Availability (HA)
Table 1 outlines the high-availability behavior for various components of the solution. Cisco VSG comes with HA, like VSM. It is not recommended that you use the VMware HA feature or the fault-tolerant or DRS feature for VSG and VSM. In case both the primary and standby VSGs are not available to vPath, you can configure the failure mode to Fail Open or Fail Close. This can be configured when you enable the security profile with vn-service command in the port profile.
Table 1. High-Availability Behavior for Cisco VSG Solution Components
High Availability (HA)
Behavior
VSG
Active Standby
Standby VSG takes over within 6 to 8 seconds
VNMC
VMware HA (VMware)
Hardware failure backup
VSM
Active Standby
Standby VSM takes over within 6 to 8 seconds
Note: A VSG pair shares an HA ID that should be unique to the pair, if you have more than one VSG HA pair sharing the same management or HA VLAN.
Tenant Management
One or more instances of Cisco VSG are deployed on a per-tenant basis, which allows a highly scalable deployment across many tenants. Tenants are isolated from each other, so no traffic can cross tenant boundaries. A tenant can be further divided to the following levels:
• Virtual data center
• Virtual application
• Virtual tier
Each instance in a tenant tree is classified as an org level. Depending on the use case, you can deploy a Cisco VSG at the tenant level, at the virtual data center (vDC) level, or at the vApp level. Figure 11 shows how a tenant tree structure can be built in VNMC.
Figure 11. VNMC Tenant Management View
Security Policy Management
The security policy in VNMC uses network attributes, VMware VM attributes, and VM custom attributes. You can define multiple policies for a tenant. All the policies are published to the VSG through a security profile. These policies can be applied at any org level within a tenant.
A general guideline is to apply more generic policies at a higher level in the tenant hierarchy, while more specific policies are closer to the org level within a tenant, where they are more meaningful. In Figure 12, VSG is placed at the tenant level (Tenant A), but the policies are applied at two different levels within the tenant. Policy P1 is applied at the data center level, which means that the entire data center DC2, and all the sublevels within DC2, are subjected to P1 policy evaluation. Policy P2 is specific to App2 only and is placed at that org level.
The general guideline is to have more generic policies higher in the org structure while more specific policies are placed closer to the org level where they are more meaningful.
Figure 12. VSG and Policy Placement in Tenant Hierarchy
Device Policy Management
The general settings for VSG are also done through VNMC. The settings include Simple Network Management Protocol (SNMP), syslog, Network Time Protocol (NTP), and fault logging. All these settings are part of device policy that is published to VSG along with security policy. When assigning a registered firewall to a tenant VSG, if you don't define a device policy, a default policy is pushed to VSG for these settings.
Scalability
VSG is designed to be scalable. As virtualized environments grow to accommodate business needs, you can instantiate more VSGs and apply the same policies to protect a larger environment. Table 2 can help you understand how you can scale from both the VSG and VNMC perspective.
Table 2. Scaling VSG and VNMC
Features
VSG
VNMC
Maximum concurrent connections
256,000
N/A
New flows per second
4096
N/A
Maximum number of VSGs
N/A
128
Number of zones
32
4096
Policy rules
1024
8192
Maximum flow supported on VSG
256 K
N/A
VSM
N/A
4
vCenter
N/A
2
Tenants
1
128
VMs
300
800 - 1000
(1600 vNICs)
Host (VEMs)
12
12
Currently, if you need to deploy an additional VSG to scale, it is a manual process in which you will bind one port profile to one VSG and another port profile to another VSG. In future versions, VSG will offer a clustering feature that will allow you to perform load balancing with two or more VSGs dynamically.
Cisco VSG Deployment Scenarios and Configuration Tasks
Figure 13 depicts the physical topology and network configuration that we will use in the sample deployment for the VSG.
Figure 13. Sample VSG Deployment Topology
Note: Standard practice for the Cisco Nexus 1000V Series VSM still applies, in which a separate VLAN is used for management and another VLAN is used for both control and packet VLANs. Our example uses this scheme. However, this configuration is not a requirement, and users can choose to have all three traffic types in the same VLAN or have a separate VLAN for each.
Three-Tier Access Control with Network Base Policies
Cisco VSG provide the standard 5-tuple network attributes that can be used in the security policies. Table 3 shows these supported attributes.
Table 3. VSG Supported Network Attributes
Name
Meaning
Value Type
src.net.ip-address
Source IP address
IP address
src.net.port
Source port
Integer
dst.net.ip-address
Destination IP address
IP address
dst.net.port
Destination port
Integer
net.protocol
Protocols specified in IP header (e.g. TCP, UDP)
string
Here is a sample security policy for Tenant A content hosting, which will be applied to this use case:
• Permit only port 80 (HTTP) for virtual machines in the web zone.
• Permit port 22 (SSH) for virtual machines that belong to the database zone.
• Allow communications only between web servers and database servers.
• Allow communications only between application servers and database servers.
• Explicitly deny all traffic to all zones.
Tasks for Security Administrators
The security administrator must perform the following high-level steps on the VNMC to create a policy using conditions based on network attributes. These steps create a policy for the three-tier use case used in our example:
1. Define Tenants
2. Add Zones for Tenant
3. Define the Security Policy
4. Create Rules in the Policy
5. Define a Policy Set
6. Bind the Policy Set to the Security Profile
7. Assigning a VSG to a Tenant
8. Verifying Security Policy configuration using CLI
Define Tenants
Log into the VNMC and choose the Tenant Management section. Right-click the root and create a tenant (Figure 14).
Figure 14. Creating a Tenant
Add Zones for Tenant
A zone is a logical group of virtual machines (VMs) or hosts. Zones simplify policy writing by allowing users to write policies based on zone attributes using zone names. Once you have created the tenant, you can go to the Policy Management section to define your security policy. Navigate to Policy Management > Security Policies > Firewall Policy > Tenant A> Zones (Figure 15).
Add three zones:
• WebZone
• AppZone
• DBZone
Figure 15. Adding vZones for a Tenant
After defining the vZone, choose the Conditions tabs to classify the zone, as shown in Figure 16. For this example, we are going to use network attributes to classify the zones.
Figure 16. Adding a Condition for vZone Classification
Similarly, define conditions for other two zones based on network attributes. All three zones should be displayed in the summary tab as shown in Figure 17.
Figure 17. Three vZones Defined for the Policy
Define the Security Policy
The predefined zones will be used to define the security policy for each tenant.
Navigate to Policy Management > Security Policies > Firewall Policy > Tenant A> Policies.
Add a new policy (Figure 18).
Figure 18. Adding a Policy for a Tenant
Create Rules in the Policy
Policy specifications outlined in the use case will be implemented by adding rules to this policy, as shown in Figure 19. In short, only allow HTTP traffic destined to VMs in Web zone, allow SSH traffic to VMs in database-zone. Only allow communication between Web and Database servers. Only allow communications between application and database servers and deny all other traffic.
Figure 19. Adding Rules to the Policy
Define a Policy Set
Next, you need to define a policy set and add this policy to the policy set. Policy sets allow you the flexibility of adding new policies in the future without changing the existing policy (Figure 20).
Figure 20. Assigning a Policy to a Policy Set
Bind the Policy Set to the Security Profile
The final step in creating a policy is to build a security profile and assign the policy set to it (Figure 21).
Figure 21. Selecting a Policy Set for the Security Profile
Assigning a VSG to a Tenant
All the registered VSGs show up under Resource Management. In order to push your policies to a VSG, you need to assign the VSG to a tenant. Once assigned, all the policies (security profiles) will be pushed to that VSG. We recommend that you add the compute firewall object directly at the tenant level.
Follow these steps:
1. In the Navigation pane, click the Resource Management tab and then the Managed Resources subtab.
2. Expand the root node.
3. Click the Firewall Profiles node where you want to add a compute firewall.
4. In the Work pane, click the Add Compute Firewall link.
In the Add Compute Firewall dialog box, do the following:
• In the General tab area, add a user-defined name and description.
• In the Firewall Details tab area, put the Data VLAN IP address as shown in Figure 22. This IP address will be used when the security profile is attached to the port profile.
Figure 22. Adding a Compute Firewall at the Tenant Level
Once a compute firewall is added at the tenant level, you can assign that compute firewall object to an available VSG, as shown in Figures 23 and 24.
Figure 23. Assigning a Compute Firewall Template to an Available VSG
Figure 24. Selecting a VSG from the Drop-Down Menu
After you've assigned the compute firewall object to the VSG, the VSG's Config State should be "applied," as shown in Figure 25.
Figure 25. VSG Assignment Status
Verifying Security Policy configuration using CLI
Log in to the VSG CLI and use show run policy to verify that the policy is being pushed successfully by the VNMC (Figure 26).
Figure 26. Verifying the Security Policy Using the VSG CLI
Tasks for Network Administrators
The configured security policy is made available to the network administrator via the security profile. This makes the network administrator's configuration task much easier since this person does not have to deal with security-policy-related details.
The network administrator now creates a port profile and can also bind the security policy to this port profile. Since the definition for the security policy does not require a separate port profile, a single port profile can be used for all the virtual machines. The sample configuration in Figure 27 shows how this is done.
Figure 27. Binding a Security Profile to the Port Profile
Tasks for Server Administrators
The server administrator will only need to go to the network settings of the virtual machine and select the port profile that the network administrator created with the security profile (Figure 28).The network profile and security profiles created will be dynamically instantiated when the virtual machine associates this network port profile.
Figure 28. Selecting a Firewall-Enabled Port Group
Three-Tier Access Control with VM Attribute Base Policies
Expanding on the sample use case in the previous section, this section describes how to build a security policy based upon VM attributes. The policy building blocks will be the same, except for the way we define the zones. In this example, we will use the VM attributes instead of network attributes to define zones.
Tasks for Security Administrators
The security administrator adds zones at the tenant levels as shown in Figure 29.
Figure 29. Adding Zones at the Tenant Level
In this example, we are using the VM name attribute and looking for keywords in the naming convention to assign the VMs in the logical zone (Figure 30).
Figure 30. Adding a Condition Based on the VMware VM Attribute
In the same way, you will define two more zones by using the DBZone and AppZone. All three zones should appear in the Zones section (Figure 31).
Figure 31. List of Zones Defined
Table 4 shows a sample list of the other VM attributes that can be used.
The task for the network administrator is the same as in the previous example. You need to bind the security profile with the port profile where you need to enable the protection (Figure 32).
Figure 32. Enabling a Security Profile on a Port Profile
Tasks for Server Administrator
The task for the server administrator is the same as in the previous example. The server administrator will need to go to the network settings of the virtual machine and select the port profile that the network administrator created with the security profile (Figure 33).
Figure 33. Selecting the Firewall-Enabled Port Group
Three-Tier Access Control with Custom Attribute Base Policies
To use custom attributes for the same three-tier use case, follow the steps in this section, in addition to the steps provided in the previous sections with VM and network attributes. The goal of showing this use case is to help you gain a better understanding of how you can use the customer attributes to build a security policy, which was previously done with VMware VM attributes and network attributes.
Tasks for Security Administrators
Define a Custom Attribute
1. Go to Policy Management > Security Policies > TenantA-> Security Profile.
2. Right-click and choose Add Security Profile Dictionary (Figures 34 through 36).
Figure 34. Adding a Security Profile Dictionary
Figure 35. Naming the Security Profile Dictionary
Figure 36. Adding a Custom Attribute to the Dictionary
Define Zones Based on Custom Attributes
Add three zones, WebZone, AppZone, and DBZone, as in the previous two examples. The only difference will be that here you will use a custom attribute that was added to the security profile dictionary "ServerType" (Figure 37).
Figure 37. Adding a Zone Condition Based on a Custom Attribute
Follow the same steps for the AppZone and DBZone.
Build the Security Policy
The policy rules will be exactly the same as in previous two examples, in which zones were added based on network and VM attributes.
Create Security Profiles
Creating security profiles using custom attributes involves an additional step. You need to create three security profiles, such as the following:
• Secure-Web
• Secure-App
• Secure-DB
For each profile, perform the following steps:
1. Select the policy set from the drop-down menu (Figure 38).
2. Give a value to the custom attribute on the Attribute tab (Figures 39 and 40).
The new profiles will appear in the list of security profiles (Figure 41).
Figure 38. Selecting the Policy Set for the Security Profile
Figure 39. Adding the Attribute to the Security Profile
Figure 40. Assigning a Value to the Custom Attribute
Figure 41. List of Newly Created Security Profiles
You have created three security profiles with different custom attribute values but the same policy set. The policy evaluation will be different depending on which security profile is enabled for the traffic flow.
Tasks for Network Administrators
Create three port profiles in the Cisco Nexus 1000V Series Switch:
• TenantA_Web_Servers
• TenantA_DB_Servers
• TenantA_App_Servers
All of these port profiles belong to the same tenant and share the same VLAN, but they have different security profiles (Figure 42).
Figure 42. Enabling Three Different Security Profiles on Three Port Profiles
Task for Server Administrators
The server administrator will have three port groups based on whether the VM belongs to the Web, App, or DB port group (Figure 43).
Figure 43. Selecting the Port Group Based on Server Type
Configuring a Syslog Server
Device settings for Cisco VSG are also done via the VNMC. These settings let you configure NTP (Network Time Protocol), syslog, and SNMP options. Please refer to the information on configuring device policies in the VNMC GUI Configuration Guide for the various options available on the Device Policies tab.
Once a device policy is defined, you assign this policy on the Resource Management tab. The following is an example of adding a device policy to set up a syslog server for logging the VSG.
2. On the Firewall Details tab, select the device profile that you created for syslog, and save the configuration (Figure 48).
Figure 49. Assigning the Device Profile to VSG
Conclusion
Cisco VSG integrates with Cisco Nexus 1000V Series Switches to enforce security policies for your virtualized environment. VNMC provides policy management for a multitenant environment. One or more VSGs are required per tenant. VSG uses the vPath intelligence in the Virtual Ethernet Module (VEM) of the Cisco Nexus 1000V Series to provide the security policy enforcement.
Glossary
VSM Virtual Supervisor Module of Cisco Nexus 1000V
VEM Virtual Ethernet Module of Cisco Nexus 1000V
VSG Virtual Security Gateway
VNMC Virtual Network Management Center
VM Virtual machine
OVA Open virtual appliance
vCenter VMware vCenter
vPath Virtual network service data path in Cisco Nexus 1000V
Service VLAN vPath redirects the traffic to VSG over the Service VLAN
Data IP VSGIP address used by VEM to obtain the VSG MAC address
