As a co-founder at Valtix, I think a lot about control planes and more specifically, controllers. Recently, I’ve spoken to several customers about our SaaS-based controller – and what it can do. Those conversations have been stimulating and productive – and because of the interest I’ve seen here, I’d like to highlight some key points from these discussions. This is part 1 of a two-part blog – in which I’ll talk about the requirements I see from organizations for a control plane. In part 2, I will dig into why we made some of the decisions we did when we built Valtix.
First, let’s ground this conversation a bit – in any solution, a controller is the implementation of a control plane. And since we’re talking real-world and not pure architecture, we’re going to stick to a discussion on controllers. What is it? A controller is the brains of a distributed security system – it manages not only the enforcement points (provisioning, operations, decommissioning), but everything about policy, apps, and infrastructure.
This is different from a device or policy manager (e.g., PANW Panorama) – a much “thinner” layer passing configuration files to devices that were designed as stand-alone. A controller manages the state of the entire system – policy, apps, connectivity of both apps and enforcement points, load and health of enforcement points, etc. Compare that to a manager, which pushes an admin’s configuration files to otherwise autonomous devices, and sometimes monitors their uptime.
A good analogy is self-driving vs. cruise control. Self-driving is replicating everything a driver does – environmental awareness, route finding, rapid decision making, speed, etc. Cruise control maintains a set speed that’s it. The requirements are very different – visibility of a dynamic external environment vs. visibility of an internal metric and the processing capability to automate with agility vs. simple logic to maintain speed aka status quo. A controller is closer to self-driving, whereas a device manager is more like cruise control.
Cruise Control vs. Self-Driving
 |
 |
| Firewall device managers give you cruise control, which worked for the datacenter | Your dynamic cloud security requires something different: self-driving |
Why is a Controller Critical in the Cloud?
Main reason? The cloud is different. The old device manager way worked fine when computing environments and boundaries were defined by physical attributes, and infrastructure was static. With the cloud, nearly everything is delivered as a service – compute, storage, networking, etc. In each of these domains, you have control planes to manage the entire service and not individual instantiations. In other words, a control plane manages every instance of the service – acting on behalf of the admin. The SLAs/metrics are for the entirety of the service, not for individual instances. Additionally, there are functional, operational, and security advantages as well.
Functionally, the scope of a customer’s cloud environment is not easily defined. In a proprietary data center, the scope was easy to define, and trust boundaries were easy to establish with physical boxes that maintained the overall state of the security system (e.g., what apps and resources mapped to what policy, who can do what, when, and how). In the cloud world, not only is the scope harder to define, it’s dynamic, and involves lots more data – growing and changing with the customer’s needs. So the state of the system cannot be maintained by individual instances and is too dynamic for manual maintenance, it must be maintained by something with a view of the entire environment – a bigger picture than individual appliances and/or a device/policy manager can provide.
In part because of this dynamism and the desire for more automation, customers increasingly use IaC frameworks such as Terraform to manage the lifecycle of their infrastructure. So a modern Controller maintains state centrally and is thus more suited to support this configuration model, whereas a traditional appliance/device manager typically pre-dates IaC frameworks and isn’t “smart” enough.
Operationally, the controller offers a superior experience – instead of buying, provisioning, deploying, and maintaining individual appliances, a controller takes care of all of that and the customer worries only about policy. The business impact of this advantage is significant. Security can be deployed quickly or completely automated – which enables faster time to market for apps and lower ops costs overall.
From the security perspective, this system view ensures that far fewer things fall through the cracks. Because the controller is aware of all apps and controls the security infrastructure, the likelihood of an app being deployed without appropriate protections is nearly eliminated.
As stated above, the current solution that many organizations are trying to adapt to the cloud is the appliance/manager model, which falls down on almost every count. It’s challenged functionally, operationally, and from a security perspective. System state is on the customer’s whiteboard, and all the manager can do is push policy to boxes. Which is both unwieldy on the ops side, and risky on the security side.
Requirements: Cloud Native Security Controller
- Infinitely scalable to handle large amounts of resources, configurations, policy, and telemetry.
- Provide comprehensive visibility of customer cloud workloads across all accounts/clouds to expedite security policy definition.
- Support modern IaC (Infrastructure-as-Code) frameworks such as Terraform for defining security infrastructure and policies.
- Minimal operational overhead for the Controller.
- Enable security best practices in terms of both development and ongoing maintenance.
The Controller is the “Brain” of Cloud Security
Controllers are the cloud-native way to secure cloud applications. They are sophisticated – incorporating the visibility of a dynamic environment and the capability to automate with agility, much like a self-driving car. Contrast this with a device manager and its simple, cruise control-style logic. Trying to adapt appliance/manager implementations to the cloud will result in functional, operational, and security problems. In part 2, we’ll dig into how we did it at Valtix.
