The 2022 Cloud-native Application Protection Platform (CNAPP) Analysis Report found that “96% of organizations are either using or evaluating Kubernetes, and 93% of them are currently using or are planning to use containers in production” (Research and Markets).

This confirms what we all know to be true—the present and future of enterprise computing is in the cloud, managed by tools like Kubernetes.

The advantages of cloud orchestration tools like Kubernetes over older server management approaches are clear: scalability without manual intervention, portability on multiple cloud providers, and declarative configuration that allows for less management by humans. For these reasons, we’ve seen a massive shift towards Kubernetes implementations.

Great popularity can also bring great vulnerability. With the proliferation of Kubernetes use, cyberattackers have learned how to exploit the same weaknesses among enterprises that utilize this open-source software.

In the rush to take advantage of better tools, enterprises should proceed with caution. Security teams must pause to think through the basic questions about security for their data and systems. Basic doesn’t mean easy: what we’re talking about here is understanding how your systems issue digital certificates to your Kubernetes nodes and whether you can really trust those identities to mean something.

Just using a service mesh in Kubernetes is not enough. The defaults typically stand up a software-based certificate authority that automatically issues identity certificates to all nodes in the cluster.  This is very convenient, and very insecure. The default configuration essentially assumes your system is already secure, instead of helping you to make it secure.  For example,

1. If an adversary can create a node, then it will automatically get a certificate. From that point the counterfeit node will be trusted by all the other nodes in the cluster.
2. If an adversary starts poking around the “secrets” data type it can unearth the certificate authority’s root key and then impersonate the CA – issuing false but trusted certificates to other nodes.

The right approach to Kubernetes security is to use an external certificate authority that uses proper hardware security and policy enforcement. It’s a small extra step, but it’s vital to ensuring you’re actually in control of your systems.

Velocity is great—failing to secure your systems because your team doesn’t know all the details of the new tools is not.  SecureG can help ensure that your virtual device identities—like the nodes in Kubernetes—are done on a solid foundation. Contact us for more information.