What is Kubernetes?
Kubernetes (K8s) is an open-source container orchestration platform known for its extensibility and portability. Most organizations that run container workloads and services use Kubernetes in some capacity, making it one of the industry's most rapidly growly application lifecycle tools.
Its ubiquity is a double-edged sword. While Kubernetes security tools and services are well-understood and widely available, the same is true for its attack surface and security risks. Misconfigurations, runtime security, worker nodes, and vulnerabilities associated with Kubernetes components like the API server and control plane provide opportunities for malicious actors and sophisticated attacks. The containers themselves also have their vulnerabilities, which tend to correspond closely to the phases of the container lifecycle.
The 4C's of Cloud-Native Security
Most conversations about cloud-native security revolve around the 4Cs: Cloud, clusters, containers, and code. As an extension of the defense-in-depth cybersecurity approach, the cloud-native security model consists of layers that build on each other, starting with the outermost layer first. While Kubernetes implementations have some additional, more specific considerations, the 4Cs are foundational to understanding Kubernetes security:
Cloud providers supply a trusted platform and computing base for Kubernetes clusters. Each cloud provider publishes guidelines and recommendations for running workloads securely in their cloud.
There are two critical factors in cluster security: 1. The protection of configurable components like the Kubernetes API, and 2. The safety of all of the applications running on the cluster. Cloud-native applications are typically built with microservices and APIs. A cluster is only as secure as the most vulnerable service or interfaces it hosts.
For micro service-oriented applications to function, containers and pods need to communicate via internal and external endpoints. These design patterns carry some inherent risk, as any compromised container potentially gives an attacker access to those same endpoints and network segments.
Even though code falls outside the scope of security issues specific to Kubernetes, it is still the most significant attack surface of any Kubernetes implementation.
Kubernetes Security: Beyond the 4C's
Truly understanding Kubernetes security requires looking at the container lifecycle and the security implications of Kubernetes components. The distributed nature of a Kubernetes cluster makes it imperative to manage Kubernetes security throughout the application lifecycle. The structure of the container lifecycle consists of 3 phases: Build, deployment, and runtime.
The Build Phase
Perhaps the most critical consideration in the build phase of the container lifecycle is building secure images. A best practice to ensure image security is eliminating unnecessary bloat in packages, libraries, and shell scripts. Developers should only leverage code from trusted sources and maintain updated versions of any application dependencies and components. Scanning is also critical to identify potential vulnerabilities in images and OS versions. Ideally, engineers should build automated scanning capability into CI/CD pipelines to identify vulnerabilities before builds are in production.
It's critical to securely and adequately configure all Kubernetes infrastructure and components before workload deployment. To do this, operators will need a comprehensive understanding of the clusters, namespaces, nodes, and pods that will deploy with the application. Here are some of the principal vulnerabilities and best practices of the deployment phase:
- Privileges- Only give containers the bare minimum privileges required to perform their functions.
- Application isolation within clusters- A critical best practice in Kubernetes deployments is to contain potential attacks by using namespaces to isolate sensitive workloads and maintain separation of duties between teams.
- Lateral movement between clusters- Best practices to prevent unauthorized lateral movement between clusters include network segmentation and maintaining tight control over communication between clusters.
- Unauthorized Access- Use Role-Based Access Control (RBAC) to limit internal and external user access to vulnerable systems.
Managing Kubernetes security effectively requires maintaining visibility and control of runtime environments so operators can respond to runtime threats before they compromise the system. System monitoring is crucial in this phase, particularly in observing communications between components, services, clients, and servers. The security of Kubernetes infrastructure elements like the API server, etcd, and worker nodes are all crucial elements maintaining security during runtime. Security teams must isolate and replace any compromised containers immediately, even before identifying the root cause of the attack.
In 2020, StackRox published the "State of Kubernetes and Container Security" report and found that 94% of respondents had experienced a security incident in their container environments over the past 12 months and that the majority of those incidents involved misconfiguration. Kubernetes implementations are prone to misconfigurations because many out-of-the-box security features and controls are not activated by default. If IT and security teams fail to configure Kubernetes components properly and apply access and identity management best practices to harden their systems, they will remain vulnerable. Organizations must apply firewall rules and network policies to regulate pod communications and limit compromises to individual pods or containers. There are also some specific tools that can scan for misconfigurations.
Kubernetes Security Recommendations Summary
Whether an organization is just getting started with Kubernetes or has been leveraging its container orchestration capabilities for years, it's vital to improve security practices across the application lifecycle continually.
One consistent recommendation that applies across the container lifecycle is the adage that less is more. Use minimal images that contain only the bare minimum of what is necessary for applications to run. Use the barest implementation of host OS possible. Remember that there is no such thing as a trusted source for both containers and OS images, so implement automated scanning capabilities throughout the build and deployment lifecycle.
Separation and segmentation are essential. Use namespaces and RBAC to segment the cluster and users, only providing access to the necessary resources and services. Use network segmentation to and correctly define ingress and egress policies to control communications and routing. Limit misconfigurations and make sure that built-in Kubernetes controls are activated before production deployments. Place emphasis on the security of clusters and components, particularly those with communications responsibilities like the Kubernetes API.
Finally, due to the dynamic nature of Kubernetes implementations, managing security proactively is critical. Keep privileges to the bare minimum, never allow processes to run as root, and monitor all process activity, network, and service communications.