How are you deploying Kubernetes?

In my career, I feel like I’ve seen every combination of Kubernetes deployments from local, bare-metal installations via tools like kops, to hosted deployments like GKE and EKS, and hybrid solutions like GKE hosted in AWS.

What’s important about knowing how your Kubernetes environment built is there are different ways to secure it.

Kops, Terraform, Kustomize, kubeadm, are all tools that will deploy a cluster, and each make their own default security assumptions. Kops for example, disables a security feature called Node Authorization by default which will change where you may believe a security boundary exists in your threat model.

Hosted/managed Kubernetes offerings on the other hand can be more expensive and often come with their own proprietary features you’ll need to learn about. The biggest security win though, is many of the security decisions are made for you with these providers, and in some cases you can’t make any changes.

Services like OpenShift make very specific security decisions for you related to workload isolation, default network controls, namespaces, etc., that aren’t the same as something like Digital Ocean’s managed Kubernetes service.

When you’re building up a risk analysis, you will be hard pressed to say that self-hosted options are less of a risk than managed ones.

Here’s an example of some of the basic security features between the providers compared with a manual deployment tool like Kops:

The benefit of hosted services when you’re just starting out is:

• Documentation on the security expectations of the environment is usually more robust.

• Many of the major security choices have been made for you.

• Many providers provide specific guidance on how to identify gaps or harden the environments.

Once you’ve figured out how Kubernetes is deployed, your team can now set out to determine if it’s following best practices or if there are any gaps that need to be addressed.