Securing Kubernetes

Show notes

Evaluating a Kubernetes cluster can occur on several levels. Standard isolation questions include examining how traffic gets into a cluster, how people can access the nodes, and whether the API server is public or private.
The three common sources of compromise for Kubernetes clusters are supply chain risks, threat actors, and insider threats.
Most hosted Kubernetes systems, especially cloud provider systems, come with a hardened node image.
When companies get into feature delivery tunnel vision, security takes a back seat, and at some point, they might be left running an outdated node version.
Without smooth continuous delivery pipelines, the responsibility of managing your own infrastructure can be too much for an organization.
One preferred way of updating a Kubernetes cluster is to do a blue-green deployment, whereby there are two clusters behind the load balancer.
Misconfiguration is a main cause of security incidents, and preventing misconfigurations is about testing.
A Kubernetes namespace is not a security boundary in itself because there are things that are not namespaced, so there is no way to accurately correlate security criteria to the namespace.