Kubernetes is proliferating within today’s IT strata because it is not just a container scheduler; it ships with impressive authentication and RBAC capabilities. With these features, Kubernetes could be used for things like data governance and networking. Thus, it could arbitrate more capabilities than first imagined.

“Four years ago, K8s was just a container scheduler,” says Gou Rao, CTO, cloud-native business unit, Pure Storage. But that’s actually just a small part of its capabilities, he says. According to Rao, Kubernetes is a declarative platform that always tries to converge to a source of truth. Yet, improperly using other technologies in conjunction that are not Kubernetes-aware threatens the security and efficiency of the overall environment.

“Kubernetes is more than just a container orchestrator — it is a new control plane for the datacenter,” Rao says. Below, we’ll consider why organizations should treat Kubernetes not only as a first-class citizen, but as an organization’s source of truth.

K8s: More Than a Container Orchestrator

Kubernetes is a container orchestrator, but it is so much more than that. According to Rao, Kubernetes “has defined a new lexicon, grammar and a set of rules for how infrastructure needs to operate.” He cites how Kubernetes-native ingress controllers and networking can be used to define complex software functions.

For example, Kubernetes ships with robust Role-Based Access Control (RBAC) capabilities. This helps segment access based on the roles of users and defines accessible resources and read/write qualifications.

“Security is a first-class citizen with K8s,” notes Rao. “It is well thought-through.” He points to built-in K8s security features, such as the ability to isolate access using namespaces, or using kubeconfig files to organize cluster access. It also supports various authentication methods, such as OpenID Connect.

“Kubernetes is, by definition, a multi-tenant platform,” says Rao. Therefore, RBAC becomes very important when sharing data among multiple business units, especially for high-risk financial scenarios. Organizations can use RBAC in K8s to ensure data cannot be accessed across namespaces. This could help platform teams enable a horizontal private or public cloud with compartmentalized, secure, container-based services, says Rao.

Square Pegs in Round Holes Undermine RBAC

According to Rao, problems arise when organizations attempt to use Kubernetes in ways the platform didn’t intend. This often involves external tools and dependencies that undermine Kubernetes. “People try to repurpose host-level technologies using these role based controls,” he says.

For example, he describes one situation in which a large motor company enabled RBAC and encryption in Kubernetes, yet their storage system was not designed to be Kubernetes-aware. “Users from Namespace A could see and mount data from Namespace B,” he describes. By adopting systems that weren’t designed for Kubernetes, they, in effect, defeated the security scheme.

Another example is data storage. Rao explains how teams often attempt to attach an external storage system to a cluster. But, by keeping data governance outside, Kubernetes can’t effectively enforce RBAC, and thus lacks control to natively ensure data governance.

K8s: The Single Control Plane?

The more you externalize, the more you introduce dependencies and potential flaws. Similarly, when you introduce additional control planes, you introduce conflicting agendas. Rao recommends organizations limit introducing additional control planes for data control and instead embrace Kubernetes as a single source of truth.

As Kubernetes can help define how applications are constructed and secured, it could thus play an essential role in controlling an application’s runtime infrastructure, networking, storage, monitoring, and other areas, says Rao. To Rao, implementing RBAC in a unified way with the K8s control plane is essential for maintaining unified command and control.

This doesn’t mean looping in other technologies is against best practice. It simply means we shouldn’t be repurposing them incorrectly. Instead, developers should be “embracing K8s-native concepts and embracing tech built for these new technologies and concepts,” says Rao.

New technologies should be introduced in a way that upholds the integrity of a single control plane. It’s especially important when selecting new tech, he says. “People need to look at products that were designed for being controlled by a single control plane,” Rao says.

Building Kubernetes-Aware

Out-of-the-box, Kubernetes comes with great networking, RBAC and security features. If applied correctly, these have powerful use cases. Yet, Kubernetes is complex to understand; when folks first start out deploying K8s, their top concern is likely to get it up and running. In doing so, they may take shortcuts that introduce missteps in terms of security and data storage.

It’s okay to loop in existing storage, yet incorrectly tying K8s to platform storage will cause things to break, says Rao. And, such shortcuts could be amplified amid the drive to deliver software throughout the pandemic. Thus, it’s important to revisit the technology adopted during this time to understand how your environment actually functions. “Thinking through problem statements holistically and figuring how how you’re going to use this new platform is important,” says Rao.

For Kubernetes deployments, context matters, and the platforms must be operated with technologies that are Kubernetes-aware, Rao stresses. When used in the wrong context, vulnerabilities and flaws can arise. To summarize, “stick with K8s as a single control plane,” Rao recommends, and ensure there are no networking overlays that Kubernetes is unaware of.

In terms of future concerns, Rao foresees more large enterprises maintaining multiple fleets of Kubernetes clusters. How to federate these clusters and whether a higher-level control plane is required to oversee them will likely be among the next iteration of problems to address.