Locking Down Kubernetes Containers with vcluster
Remember when containers were brand new, and we all worried about malicious actors being to jump from one container to another? I do. As Daniel Walsh, Red Hat Senior Distinguished Engineer, said back in 2014, “Containers do not contain.” Containers tend to be secure, but container breakouts, such as CVE-2019-5736 can happen. So, when Loft Labs, a developer tooling and Kubernetes multitenancy startup announced that its open source vcluster can now be used to an isolated mode for virtual clusters this is news you can use.
If you don’t know about vcluster, here’s the 411. Vcluster follows in the footsteps of k3v, which was a proof-of-concept for virtualizing Kubernetes based on the popular k3s Kubernetes distribution. Today, vcluster enables you to spin up lightweight, virtual Kubernetes clusters that run inside the namespaces of an underlying Kubernetes cluster. This approach reduces cluster sprawl, allows for more secure and better maintainable multitenancy, and aims for more efficient resource sharing, which ultimately saves infrastructure costs.
Separate Control Planes
Its new feature is that it spins up virtual clusters, which are logically isolated by having separate Kubernetes control planes. The workloads running inside these virtual clusters, pods, and their containers, however, are not isolated by default. Instead, they’re scoped within a namespace.
This can be very useful for such use cases as enabling tenants to set up the custom namespace, with appropriate role-based access control (RBAC) permissions, so they develop within their virtualized cluster without asking cluster managers or the site reliability engineering team to create or modify CustomResourceDefinitions (CRDs) for them. This means, Mike Tougeron, vcluster user and lead Adobe cloud engineer, wrote, “Suddenly the development team can run their custom operator however they’d like and it would still respect the multitenant nature of the host cluster.”
This is very handy. Virtual clusters are often used as development environments when engineers are building, testing, and debugging cloud native software. Virtual clusters can also be used as ephemeral environments for executing continuous integration/continuous delivery (CI/CD) pipelines.
Security Controls Enabled, Autoconfigured
Previously, any Kubernetes security mechanisms for vcluster workloads had to be created manually by the cluster administrators. Now, with vcluster’s isolated mode, a variety of Kubernetes security controls will be enabled and auto-configured without manual configuration. These include:
- Pod security standards (admission control policies)
- Resource quotas and limit ranges
- Network policies
Loft Labs sees this as a default best practices ruleset for virtual clusters. As Lukas Gentele, Loft Labs’ co-founder and CEO, said, “Before, admins had to add security constraints for virtual clusters themselves which added complexity and required ongoing maintenance. Now, with isolated mode, we as project maintainers provide a default set of security measures that we recommend as best practice for isolating virtual clusters.”
While Isolated mode enforces baseline workload isolation policies if you need more security, you can get it. Gentele continued, “Of course, admins can tweak isolation constraints to their use cases and to their organization’s security policies but we make it easier for them to kick the tires with vcluster while enforcing stricter security boundaries by default and right from the start.”
Kubernetes Multitenancy
Vcluster has other advantages in addressing Kubernetes multitenancy issues. These include:
- Better isolation than simple namespace-based multitenancy;
- Reduced cloud computing cost because virtual clusters are much more lightweight and resource-efficient than spinning up separate single-tenant clusters;
- Logical separation and encapsulation of application workloads from the underlying cluster’s shared infrastructure workloads (such as shared ingress controller or network plug-ins).
At the same time, virtual cluster users can expect that their virtual cluster behaves just like any regular Kubernetes cluster since vcluster is now a certified Kubernetes distribution. In other words, it passed all of the Cloud Native Computing Foundation (CNCF) Kubernetes conformance tests.
Tougeron sees a lot of potential in vcluster for CI/CD and canary or blue/green deployments. So do I. Cloud native developers should take a long hard look at vcluster. It may be a critical part of the secure development Kubernetes environment you’ve been looking for.
