In today’s dynamic cyberlandscape, the rise of artificial intelligence (AI) has accelerated the transition to the cloud and the adoption of multi-cloud services. However, cloud and multi-cloud services require organizations to shift the workload to the cloud provider, meaning that applications must be highly portable. This can be achieved by leveraging Kubernetes, an open-source container system. According to a Cloud Native Computing Foundation (CNCF) report,1 containers such as Kubernetes have been widely adopted, and their use will only increase with time.
As organizations increasingly adopt Kubernetes for its scalability and flexibility, it is imperative to prioritize the security of both Kubernetes clusters and workloads. Implementing robust security measures, such as hardening cluster configurations, enforcing stringent authentication and authorization protocols, establishing comprehensive network policies,2 securing the supply chain, and maintaining vigilant observability, is essential. By adhering to these best practices, organizations can effectively mitigate risk and ensure the integrity, confidentiality, and availability of applications in dynamic cloud-native environments.
Understanding Kubernetes
Kubernetes is one of the most widely adopted open-source container orchestration platforms. It helps to provision, manage, and scale containers. Kubernetes has made running containers in a complex distributed environment easier than managing them manually or through any homegrown solution. Google originally developed Kubernetes as an internal tool. Now, Kubernetes is managed by the CNCF.3
Before discussing security best practices and methods to mitigate risk when setting up the cluster and workloads, it is necessary to examine the Kubernetes architecture and its components to better understand the security measures explained. As shown in figures 1 and 2, a Kubernetes cluster comprises a Master Control Plane and workers. Each has distinct components.4
Figure 1—Master Control Plane and its Components
| Component | Function |
|---|---|
| Kube API Server |
The core component exposing the HTTP API |
| etcd |
Key-value store to store the API server data |
| Kube-scheduler |
Schedules the pods on the desired Node |
| Kube-control-manager |
Controllers to manage the API behavior |
Figure 2—Node Components
| Component | Function |
|---|---|
| Kubelet |
Responsible for running the pods along with containers on the nodes |
| Kube-proxy |
Manages the network services |
| Container runtime |
Responsible for running containers |
The Center for Internet Security (CIS), which sets standards for security configuration, has provided several controls that organizations implementing Kubernetes must follow to ensure the safety of sensitive data and systems.5
Cluster Configuration Hardening
When using Kubernetes, hardening the cluster configuration6 is crucial because misconfigurations often lead to vulnerabilities. Users must log in and authenticate to the Kubernetes cluster to interact with the kube-apiserver. There are several ways to authenticate the users and services, including leveraging X.509 client certificates, OpenID Connect, and service accounts. Measures should be taken to avoid static passwords or tokens due to their diminished security posture, including the use of authorization mode and TLS communication.
Authorization mode—On the API servers, disable anonymous authentication and use role-based access control (RBAC) as the authorization mode. This ensures that only authenticated users with defined permissions can access cluster resources.
TLS communication—Transport Layer Security (TLS) communication is crucial. It secures communication between the master node components and worker node components by encrypting data in transit and enabling mutual authentication using certificates, ensuring only trusted components can exchange information within the cluster.
Worker Node Hardening
Organizations implementing Kubernetes should always choose a minimal and lightweight operating system (OS) suited for running container workloads. They should also implement a firewall to prevent unauthorized access to the worker node by restricting access to the necessary port only. Keeping access permissions as strict as possible ensures that users have appropriate access permissions.
To mitigate security risk, organizations should regularly patch OS and Kubernetes components for security vulnerabilities. It is also a best practice to drain the pods (a group of 1 or more containers) and move the workloads to new nodes, ensuring that no pod is actively running on unpatched servers.
Authentication and Authorization
Strategically building a robust RBAC with minimal permissions is crucial to reducing the blast radius during cyberattacks and preventing unauthorized access. Access control in the Kubernetes environment involves separating the cluster by namespace level, using roles and role binding, and using cluster roles and cluster role binding on the cluster level. There are several ways that unauthorized access can be mitigated in Kubernetes environments:
- Multifactor authentication (MFA)—Verifying identity through MFA during the first authentication and while performing specific operations such as creating a user or role or deleting a container can help the organization protect itself from impersonation.
- Limit service account permissions—Organizations must avoid using default service accounts. Instead, they should create a service account for a specific application and ensure that only the least privileges are granted.
Network Policies
Organizations can significantly enhance their security posture in Kubernetes environments by enforcing ingress and egress network policies. These policies act as a firewall for pods, ensuring that only the intended traffic flows in and out. By default, Kubernetes allows all pod-to-pod traffic; thus, a network policy must be defined to restrict inbound or outbound traffic.
To avoid overly complicated network policies, it is best to keep egress and ingress guidance simple by using purposeful labels and namespaces and keeping rules granular yet manageable.
Software Supply Chain Security
Scanning for vulnerabilities is crucial in Kubernetes environments and can occur during the continuous improvement/continuous development (CI/CD) process and during runtime inside Kubernetes. To this end, scanners such as Trivy7 are essential to finding vulnerabilities in containers. Another precaution involves hardening base container images (the images that will be used by the organization), which ensures that the organization uses trusted images, limiting outside vulnerabilities.
A tool suitable for this purpose is the Kubernetes admission controllers,8 a plugin that validates requests before they are executed. This plugin helps set protocols to run the application with specific settings, such as not running as a privileged container and requiring resource quotas for the pods.
Logging and Monitoring
Logging is crucial for gaining visibility into cluster activities, debugging issues, and improving organizational security posture. Logging inside Kubernetes should be gathered at cluster, node, and application levels to keep track of every single piece of the entire Kubernetes cluster. Additionally, it is best to export all the logs to a centralized log management system to ensure due diligence and transparency.
Moreover, it is crucial to check for vulnerabilities before deployment. Even so, vulnerabilities can still emerge after the application's deployment. To find vulnerabilities, organizations should implement a runtime detection system that continuously monitors and creates alerts for issues. Tools such as Falco, Sysdig, and Aqua look for vulnerabilities and cluster configurations against the CIS benchmarks for Kubernetes.9
Organizations must also be aware of several newly evolving threat vectors for Kubernetes.10 It is imperative to remain vigilant regarding how the workload is created and who has access to the Kubernetes endpoint. User behavior analytics will help the security team detect unusual resource patterns or API access.
Security and Best Practices
Organizational security remains a top priority even in Kubernetes environments. To maintain a robust security posture, organizations should avoid using keys or credentials for internal communications as much as possible. This is because credentials can be stolen. If credentials are required, such as API keys and passwords, it is critical to mount the secret data through Kubernetes volume (a directory for containers in a pod to share data) rather than hardcoding and ensuring that it is designated as read-only. Organizations can also consider an access control service, such as Vault11 or AWS Secrets Manager. By following these best practices, organizations can ensure that sensitive data and system access are managed and secure.
Conclusion
As organizations increasingly embrace Kubernetes for its scalability and flexibility, securing Kubernetes clusters and workloads must be a top priority. There are several crucial areas for enhancing Kubernetes security, including hardening cluster configurations, implementing robust authentication and authorization, establishing network policies, ensuring supply chain security, and improving logging and monitoring practices.
Organizations can minimize their attack surface and block unauthorized access by utilizing strong authentication methods, such as MFA, limiting service account permissions, and enforcing network policies. Strengthening worker nodes and using runtime security tools further bolsters defenses against evolving threats. Moreover, securing the software supply chain through vulnerability scanning and Kubernetes admission controllers helps reduce compromised images and misconfiguration risk.
Ultimately, utilizing Kubernetes demands a proactive security strategy. Organizations must routinely assess and update their security policies and remain vigilant about emerging threats. By emphasizing security best practices, organizations can confidently manage their containerized workloads in Kubernetes environments while protecting essential applications and data.
Endnotes
1 Thakkar, R.; “The Voice of Kubernetes Experts Report 2024: The Data Trends Driving the Future of the Enterprise,” Cloud Native Computing Foundation, 6 June 2024
2 Kubernetes, “Network Policies”
3 Cloud Native Computing Foundation (CNCF), “Kubernetes”
4 Kubernetes, “Kubernetes Components”
5 Google Cloud, “CIS Benchmarks”
6 Google Kubernetes Engine, “Harden Your Cluster’s Security”
7 Github, Aqua Security/Trivy
8 Kubernetes, “Admission Control in Kubernetes”
9 Github, Aquasecurity/Kube-Bench
10 Thevarmannil, M.; “Top 5 Kubernetes Security Threats/Issues – Must Read,” Practical DevSecOps, 11 January 2024
11 HashiCorp, “Kubernetes”
Nivathan Athiganoor Somasundharam
Is a technical account manager at Gravitational Inc. DBA Teleport. He specializes in Zero-Trust implementation, identity security, and DevSecOps. He holds a computer science degree from Texas A&M University (Texas, USA) and has extensive experience working with cloud providers such as Amazon Web Services, Google Cloud Platform, and Azure. An active contributor to the cybersecurity community, Somasundharam shares his expertise through blogs, webinars, and conferences, focusing on identity threat detection and response (ITDR) and cloud infrastructure security. He is also a key contributor to the open-source Vmware Carbon Black Harbor Adapter project.