What Does A “Secure” Cluster Look Like?

What we’re outlining here are methods to help you eventually make your Kubernetes environment “secure.”

OK, so what does that mean exactly? You can think about it at its bare minimums:

1. Securing the Kubernetes configuration (Control plan, cluster config)

2. Securing the container workloads (applications, runtime)

3. Securing the Kubernetes-adjacent infrastructure (CI/CD, exposed services)

In other words, you’re going to figure out how to first lock down the Kubernetes cluster by setting appropriate RBAC controls, designing a Namespace configuration, controlling remote access, and figuring out how to run applications.

Then you’re working on securing the workloads running within the cluster to limit the blast radius of a compromised Pod. Are you protecting from common container break outs? Have you determined which applications are at particular risk, like the ones running Perl CGI image processing?

Finally you’ll need to secure the services that are integrating with the clusters, like your CI/CD tools, build pipelines, image registries, secret stores, and ingress points. This is to ensure that a compromised cluster doesn’t immediately lead to the compromise of other services within your organization.

We’ll cover securing your cluster later in the Understanding Your Risk section.

But let’s not get ahead of ourselves, first let’s just try to gather information that helps us define risk within our environment.