SDDC and the Ever Expanding Control Plane

The software defined data center has the potential to expand the control plane well outside of anyone’s control by the simple fact that we do not yet have a unified control mechanism for disparate hardware (networking, storage, and compute), for disparate hypervisors (vSphere, KVM, Xen, Hyper-V), new types of hypervisors (storage and networking), and new ideas at managing SDDC at scale. These all end up on the control plane of a software defined data center. In addition, we cross multiple trust zones while in that control plane such as going from user controlled portals to hypervisor management constructs. Add to this the ever increasing number of APIs and we have a very hard to secure environment.This is where the architecture of your software defined data center becomes paramount but this architecture must include such items as:

security compliance auditing data protection networking

monitoring analysis management operations storage

Each of these items has their own API, which talks to an application, which lives within an operating system.  So we need to not only harden the operating system, but the application, and finally the API as well as all the connections between all the APIs.  Let us look at just one possible SDDC control plane depicted in figure 1. In figure 1, we have two distinct areas of this control plane. Those accessible by the user (ITaaS Portal and the Workloads), and those accessible by automation tools and therefore by the cloud administrator (physical and virtual resources, virtual machines, and automation tools).

We need to understand how the control and tenant data moves around this environment in order to properly secure and protect the environment. If an automation tool can touch something, then so can a user, unless we properly lock things down. In figure 1, we explicit state Puppet and Chef, but this could also be other automation tools from hypervisor and cloud vendors.
The problem is, as we add even more to this diagram for operation and security controls on a per tenant basis, we proliferate even more cross zone traffic and use of even more APIs as seen in Figure 2. Just by adding some basic monitoring and reporting adds even more movement of data around the control plane into and out of the red zone to the orange zone. Where the orange zone is touched by tenants (users), and the red zone is touched by automation tools (administrators).

As we add even more to the control plane of a software defined data center, we need to consider up front who owns, what protects, and why of every element in the control plane. How will this element be accessed, we need to review each and every aspect in order to properly secure the environment. Most importantly we must realize that protecting the network and connection points is only the beginning, we need to further protect the applications from harmful manipulation through APIs that could be found to be faulty down the road.
This control plane we traditionally would place within its own trust zone, but we can see that we cross many traditional trust zones (security, virtualization, storage, networking, operations) as we enter the software defined datacenter. The use of APIs over user entry could also lull architects into a false sense of security. As wherever an API can go, so can an administrator, in addition many APIs delegate user actions such that once you finally make it to the hypervisor or hardware you have no clue who actually made the call, only that the call was delegated through a set of users. So was the API call to delete a workload legitimate or not?

Closing Thoughts

Now is the time to architect security into our SDDC solutions. We are at the beginning. We need good reference architectures that include security from the beginning, not as a bolt on, and not just the statement we will add a firewall here, here, and here and you will be safe. There is a proliferation of APIs that are relatively untried, a new way of thinking, and a proliferation of data that tenants wish to see. We should provide it to them, but safely and securely. How would you secure these control planes?