In This Section

NOTE - This section references the configuration using the Advanced Management menus. For new design, it is recommended to use the Onboarding Flow Management admin portal pages, which both simplify and streamline the onboarding and configuration of users, application profiles and policies.

Overview

The CoIP Platform provides architects with many, easy-to-use components to quickly build up complex hybrid networking and security environments. The goal of this article is to share the best practices Zentera's customers have used to deploy production environments.

This article is not a step-by-step "how to" manual. It is designed to help you think through building new deployments using CoIP capabilities. 

Considerations Before You Begin

When planning a CoIP deployment, it is helpful to have a good understanding of the application network you are trying to build. For instance, a Three-Tier Web Deployment might be deployed with many web servers deployed in regional public cloud providers (for global coverage and easy auto-scaling), while the business logic and database layers reside elsewhere.

Zentera CoIP has been deployed in both new and existing application networks. The thinking behind these two approaches isn't fundamentally different, however there are many optimizations an architect can use to achieve a better outcome with less effort. 

The fundamental unit of a CoIP deployment is an "Application Profile" that defines the networking and security policies that the system will enforce. The easiest way to learn how to build an App Profile is through the CoIP Controller's web interface where you will draw those policies in a visual way. Figure 1 shows an example App Profile in the portal's editor:

A Basic Application Profile

The App Profile above shows three "Cloud Domains", CoIP's term for a routable network domain.  For example, separate cloud domains could correspond to a VPC in a cloud service provider, such as AWS.  A VLAN segment inside a datacenter may also be considered a cloud domain - within it, all of the servers have routing already configured.

In the first two of those domains there exists a blue circle representing a Server Group, and those Server Groups are connected by a green line representing a CoIP WAN connection. This is a policy (also called "Compute Flow") that determines how the compute resources in one Server Group can communicate to the compute resources in the other group. 

The orange "Lock Box" rectangles indicate a zChamber "Security Policy" that is essentially a stateful firewall managed by the zCenter Controller.

In the third domain, there is an orange circle representing a collection of CoIP Access Users that have credentials to access the web servers in the top domain. See the CoIP Access Setup Guide for more information about CoIP Access.

An App Profile should reflect your desired application network.

Building App Profiles

There are two ways to create an App Profile. They can be drawn graphically through the zCenter Admin Portal or built through the use of zCenter's Application Programming Interface (API). In either case, the basic components of an App Profile are:

• Customers and Cloud Projects

• Cloud Domains

• Cloud and Fabric Server Pools

Customers and Cloud Projects

Because zCenter is inherently multi-tenant, all work is segregated by the concept of the Customer. A given Customer can have multiple Cloud Projects. This is the first level of differentiation required in architecting for CoIP. The decision for Enterprise deployments is to determine the level of granularity for the Customers in your zCenter. For instance, a best-practice for the engineering department is to segment different projects between different customers. The HR department should follow suit with ideas like "Hiring", "Benefits", and "Payroll". With the exception of key employees, what goes on in one department should not be visible in another.

Cloud Projects are the next level of segmentation that should be thought out. Using the HR department as an example, different aspects of HR software should, for security and ease-of-management, be segregated. Consider Payroll. There are multiple applications within a Payroll department, however, there are certain to be applications that have little overlap and should be safely segmented.

This segmentation is key to enhanced security.

Cloud Domains

A Cloud Domain is a logical concept in CoIP. Loosely following the idea of a discrete network domain (e.g. "The data center in building 3"), Cloud Domains segment types of networking in CoIP. CoIP WAN networks span different Cloud Domains while CoIP LAN networks are contained within a given Cloud Domain. Best practices are to logically segment your App Profiles accordingly but keep in mind that two or more Cloud Domains can existing in the same physical data center, connected by CoIP WAN's encrypted channels.

Cloud and Fabric Server Pools

These function as both a warehouse for registered, but unassigned compute resources as well as a management tool for registered and assigned machines. Server Pools contain registered machines after in the installation of the zLink agent. For Cloud Server Pools, these registered machines gain a CoIP address.

"Registration" is defined as a physical or virtual machine or container that has a zLink agent installed and connected to the zCenter Controller. Endpoints can be registered by the installation of the zLink Agent as outlined in Zentera Endpoint Agent Installation.

Adding Security Policies

There are two ways to create security policies in CoIP: manually, or automatically. In new deployments, it's often best to use the manual method as you can custom craft, and understand, what security policies you want to deploy. In the automatic methods, you can ask zCenter to monitor a running application network, learn normal traffic, and then enforce the derived rules as the only allowable traffic.

Manually - Via the Admin Portal UI

Manually creating security policies is easy in CoIP. You either draw or use the API to create the allowed traffic using a flexible group of components. For instance, you can create a one-way (uni-directional) WAN from one group of servers to another. As will be shown later, you can limit what traffic protocols are allowed, the allowed port numbers, and even control what IP addresses are allowed to communicate.

Security Policies in the UI are found in the Project Management → Security Profiles. 

Automatic - Via the zCenter API 

zCenter's API provides many of the Security Policy capabilities of zCenter when deploying network filtering capabilities like Traffic Whitelisting. These capabilities help automate much of the networking-based security like limiting traffic direction, protocols as described in the section below titled, "Security → zChamber".

Automatic - Via Smart Discovery

CoIP's zCenter admin portal allows you to monitor a running application for a defined time period and then enforce only the discovered traffic as a security policy. Accessed from Project Management → Security Profiles, Smart Discovery allows Admins to monitor traffic to and from selected compute resources. Smart Discovery can be run for a specified time and then use the discovered information to enforce those rules into either zChamber or Application Interlock (whitelisting).

Fundamental CoIP Components

Zentera CoIP provides capabilities that address overlay networking and additive security. This section lists the basic components of the CoIP system.

Networking

CoIP provides many overlay networking options that make hybrid deployments easy. The two primary networking capabilities are CoIP WAN and CoIP LAN. CoIP WANs are used  across "networking domains", and CoIP LANs are used within a given "data center". These two items are in double quotes for the simple reason that CoIP networking is an overlay networking solution that can reach across traditional physical networking structures.

CoIP WANs

The basic deployments of CoIP WANs are from Server Group to Server Group. In the CoIP world, a Server Group is a logical wrapper around one or more compute resources known as EndPoints. Any EndPoint server contained within a given Server Group inherits both the networking policies, as well as the security policies specified for that group.

When designing a CoIP deployment, it's easiest to think of CoIP WANs as cross-domain WAN connections between data centers, although CoIP WANs can connect different application domains within a single data center. To CoIP it makes no difference as long as those compute resources can "see" the CoIP Controller.

CoIP LANs

Like CoIP WANs, CoIP LANs connect computer resources within a given network domain, however, this definition is again not strictly true because CoIP is an overlay network and can actually join machines in a given server group that are not in the same local data center. One of the benefits of CoIP LANs over typical physical networking is that CoIP LANs can optionally be encrypted.

Compute Flows

Compute Flows allow CoIP deployments to interface to traditional networking components within a given network domain. (No. Really this time. These are traditional connections and not overlay networks).

These flows allow access to other critical compute infrastructure like DNS, LDAP, or AD servers contained within a given network domain.

Security

zChamber

The fundamental component of CoIP Security are the zChamber feature combined with various networking capabilities. This capability controls external access to a computing resource by implementing a Stateful Firewall on that resource. In Linux-based machines, zChamber manages this by manipulating the kernel's networking filters (via iptables). On Windows machines, it manages the Windows Firewall. Additionally, the zChamber is completely dark, except for Network Time Protocol (NTP). All other access is managed via CoIP WANs, LANs, or Compute Flows, each of which, can be further controlled by whitelisting specific traffic. The granularity of network traffic is:

• Traffic direction (bi- or uni-directional)

• Whitelisted IP Addresses (including DNS names, single addresses, or ranges of addresses)

• Whitelisted Protocols (TCP, UDP, and ICMP)

• Whitelisted Ports (single port or port ranges)

Adding a zChamber to an Application Profile is achieved via the Project Management → Security Profiles pages

Application Interlock

CoIP has the ability to interlock applications with the CoIP network (think Application Whitelisting). One of the primary uses of App Interlock is to use Smart Discover to monitor a running set of applications and record the compute resources, applications using the physical network prior to enforcing those rules into the security policy.

Advanced Components

In addition to the components mentioned above, CoIP provides other components that can be used to enhance and extend a given deployment for added flexibility, enhanced performance and throughput, and special conditions.

Edge Gateways (EG)

CoIP is usually implemented via the zLink Agent. These agents run in user space on the EndPoint machines and are responsible for implementing the networking and security policies held by the Controller. Edge Gateways can be thought of a translator between a CoIP overlay network and traditional networking equipment. This allows CoIP to connect to servers and devices that do not, or cannot carry a zLink Agent. Zentera has customers deploying EGs to various networked devices like manufacturing equipment, robots, gene sequencers... you know. Really expensive pieces of equipment that we cannot deploy EGs on.

From a security aspect, EGs can be wrapped with zChambers, and can be configured to listen to specific whitelisted IP addresses on the L3 side. This helps harden these devices from other intrusive behaviors on the physical network. As an example, an EG can be programmed to listen to a range of IP address (say 10.10.1.1-20) but will ignore traffic from other machines on the same subnet (10.10.1.21-254).

EGs can also be deployed for Agent to Physical, or Physical to Physical traffic. These are the more advanced use cases known as "Type 2" and "Type 3" CoIP WAN connections:

• Type 1 - Server Group to Server Group

• Type 2 - Server Group to Physical Subnet

• Type 3 - Physical Subnet to Physical Subnet

Zentera Network Switches (ZNS)

The basic deployment of a CoIP Controller contains two parts, Command and Control, and a Network Switch. The Command and Control section manages the behavior and monitoring of a CoIP deployment by comparing network traffic with its networking and security policies. This section of the Controller uses Application Profiles drawn either by the Admin, or utilizing its API. In other words, it implements the CoIP Control Plane.

The switch section manages the flow of data through the Data Plane. Because CoIP deployments can be large and complex, additional switches can be deployed elsewhere, typically closer to the producers and consumers of the network traffic.

ZNS deployments are typically clustered for both throughput and high-availability.

Inline Devices

As their name implies, CoIP allows admins to craft more complex deployments by including the concept of Inline Devices. Inline Devices provide mechanisms to control and distribute CoIP network traffic to other devices like intrusion detection, packet capture, and network analyzers. Because CoIP traffic is protected by encryption, the Inline Devices decrypt outbound traffic before sending it to its destination, and can re-encrypt return inbound traffic making it easy to connect to traditional networking services and devices.

There are two types of Inline Devices available in CoIP: 

Security Tap Device

Tap Devices implement Port Mirroring in CoIP deployments. When using a Tap Device, a selected copy of CoIP network traffic can be unencrypted and mirrored to other processes for intrusion detection, packet capture, or other analysis systems.

The Tap Device also allows only selected traffic to be mirrored (think of a "SPAN" port). 

Security Inline Device

The full Inline device is used to feed unencrypted CoIP traffic to decision making devices like Web Application Filters (WAFs). With this device, traffic is feed out to the external process which makes a decision on whether that traffic is allowed to flow.

Summary

CoIP architectures are relatively easy to deploy using the methods described above. The key takeaway from this article is that a well-planned application network is where the focus of your thoughts should be. 

Oh and if you craft a deployment that isn't quite right, CoIP allows you to make changes as easily as your first implementation.