By Billy Downing, Sterling Cloud Architect
.
Security is no longer implemented as an afterthought of the deployment of an IT environment. It is no longer tacked on in the hopes of avoiding some cyberthreat. In an era rife with cybercrime, we must give cybersecurity primacy.
.
In today’s tech environments, within public or private clouds, security must be implemented at the outset, coupled just as tightly as compute, storage, and networking. For security principles and practices to be adopted seamlessly, the solutions required must be embedded in the lower-level platforms, as is the case with the NSX-T platform. NSX-T provides a security solution – the tools are enabled directly within the network infrastructure itself.
.
NSX-T provides a software-defined network that creates a centralized management and control plane combined with a distributed data plane. The intelligence of the network (and its source of truth) is placed within the control plane at the direction of a single point of management and then distributed for implementation onto every data-plane host in the environment.
.
NSX-T’s tight integration with VMware’s vSphere affords us unique insights into traffic flows from a network perspective. When deploying NSX-T on top of vSphere, we are essentially moving network service complexity from the traditional routers and switches at the top of physical racks down to the vmnics (virtual-machine network–interface cards) themselves, inside the virtualized environment. Using this model, NSX-T can place security tools as close to the workload as possible without having to redirect traffic or cause any differentiation in data flow to accommodate security scanning — as the traditional model does by forcing traffic through a centralized security appliance. Each rule created, from layers 2 – 7 of the OSI model, is implemented directly at the point of connection for a virtual machine or container within the esxi host workloads they are running. This distributed model adds not only the ability to enforce policy as close to the application as possible but provides efficient scaling and unique insights into the workload through vCenter and VMware tools integrations.
.
In sum, distributed security-enforcement provides distinct benefits:
.
The traditional model for security requires dedicated appliances to sit centrally in the network, adding the requirement to manipulate traffic flow and force pathing through the appliance or to send copies of flow data to the appliance to ingest for inspection. In either scenario, a cost is associated— either in network bandwidth or efficient traffic pathing. Using a distributed enforcement model in the data plane removes the need for a centralized appliance and provides a point of inspection directly at the virtual machine or container interface without having to manipulate traffic.
.
Centralized controllers scale based on traffic load and inspection processes; however, they scale independently of the workloads themselves. If you add 1,000 virtual machines and six esxi hosts to an environment, the centralized security data plane must be reassessed to handle the new load. Scaling vertically has obvious limitations and creates a separation, or, decoupling, of security from the compute, storage, and networking environments — which we want to avoid. NSX-T’s data plane being directly deployed in the esxi hosts themselves results in efficient scaling, since each added esxi node results in added resources, not only for compute (vSphere) and storage (vSAN), but also network security (NSX-T). This removes the concern that a central security appliance will become a bottleneck in the environment and allows security policies to be implemented without hindering application performance.
.
NSX-T integrates with vCenter and as such can query the vCenter inventory on a granular basis, using VMware tools as well, to better understand the workloads it supports. In a traditional network environment, policies are written for IP-addressing schemes. With NSX-T, we’re able to abstract IP address away from application type. We can begin to enforce policies on all Windows machines, Linux machines, or machines with ‘Test’ in their name, and so forth. An application is not defined by its location or IP address; neither should the security policy built to protect it.
.
With NSX-T we can realize the direct and seamless adoption of security tools into the existing data flow of our application, allowing us to have security conversations up front, during the initial design of our environment, without compromising our architectural intentions.
.
.
.