This introduction combines best practices from the CNCF, NSA, and CISA to help organizations mitigate risks and adopt a multi-layered security approach.
Join the DZone community and get the full member experience. This is an article from DZone’s 2021 Kubernetes and the Enterprise Trend Report. For more: As more organizations have begun to embrace cloud-native technologies, Kubernetes adoption has become the industry standard for container orchestration. This shift toward Kubernetes has largely automated and simplified the deployment, scaling, and management of containerized applications, providing numerous benefits over legacy management protocols for traditional monolithic systems. However, securely managing Kubernetes at scale comes with a unique set of challenges, including hardening the cluster, securing the supply chain, and detecting threats at runtime. This introduction to Kubernetes security combines best practices from the Cloud Native Computing Foundation (CNCF), National Security Agency (NSA), and Cybersecurity and Infrastructure Security Agency (CISA) to help organizations mitigate risks and adopt a multi-layered security approach. Securing a Kubernetes environment starts with hardening the cluster. For users of a managed Kubernetes service (e.g., GKE, EKS, AKS), the respective cloud provider manages the security of the master node and implements various secure-by-default settings for the cluster. GKE Autopilot takes additional measures, implementing GKE hardening guidelines and GCP security best practices. But even for GKE standard or EKS/AKS users, there are guidelines maintained by the cloud providers to secure access to the Kubernetes API server, container access to cloud resources, and Kubernetes upgrades: For self-managed Kubernetes clusters (e.g., kube-adm, kops), kube-bench can be used to test whether the cluster meets the security guidelines laid out in the CIS Kubernetes Benchmark. Key recommendations include encrypting the secrets stored in etcd at rest, protecting control plane communication with TLS certificates, and turning on audit logging. By default, Kubernetes allows communication from any pod to another pod within the same cluster. While this is ideal for service discovery, it provides zero network separation, allowing bad actors or compromised systems unlimited access to all resources. This becomes extremely problematic for teams using namespaces as the primary means of multi-tenancy inside Kubernetes. To control the traffic flow between pods, namespaces, and external endpoints, use a CNI plugin that supports the NetworkPolicy API (e.g., Calico, Flannel, or cloud-specific CNI) for network isolation. Following the zero-trust model, the best practice is to implement a default deny-all policy to block all ingress and egress traffic unless it is specifically allowed by another policy.
