Security operations · 6 MIN READ · ETHAN CHEN · NOV 25, 2024 · TAGS: Cloud security / Managed security / MDR
The four Cs of Kubernetes security, and how Expel can help solve your Kubernetes security challenges
TL;DR
- This is part two of a two-part blog series on the fundamentals of securing Kubernetes.
- It covers the four Cs of Kubernetes security, and explores how Expel can solve Kubernetes-specific security challenges.
- Part one of the series will covered the definition of Kubernetes, its unique challenges, and architecture, and why it generates false positives.
The four Cs of Kubernetes security: code, container, cluster, and cloud
Defense in depth depends on multi-layered security. The 4C security model is designed to protect cloud-native applications running in containerized environments—like Kubernetes—by focusing on each layer of the architecture.
Code
As in any type of application development, automated security testing—both static (SAST) and dynamic (DAST)—is essential to uncover vulnerabilities in code before deploying it in a Kubernetes environment. Other best practices include auditing your software supply chain to remove vulnerable or unsupported dependencies, and ensuring a manual code review stage before software enters production.
Code-level Kubernetes security also includes two other requirements specific to this type of environment:
- Scanning for hardcoded secrets. Developers occasionally commit Kubernetes secrets, like API tokens, into source code. If they’re stored as plain text, they’re easily discoverable in an attack or inadvertently exposed in a version control system. They’re also hard to update or rotate regularly, and often fail compliance standards for the protection of sensitive data.
- Scanning for YAML security risks. Developers use YAML files as declarative manifests for the Kubernetes resources within a cluster. These files define attributes such as API version, kind of resource, metadata, and specifications. Applying the principle of infrastructure-as-code to Kubernetes, YAML files make it easier to replicate configurations across different deployments and to automate cluster management. However, misconfigurations in a YAML file will be replicated as well. This will multiply any vulnerabilities across a company’s hybrid environment. To prevent this, developers should scan YAML files to identify any potential security risks before deploying the files to a cluster.
Container
Container-level Kubernetes security includes measures to protect the Kubernetes environment from vulnerabilities within the container, and to protect the container from vulnerabilities in the Kubernetes environment.
- Container image scanning. Container images are a prime attack vector. Threat actors can exploit any vulnerabilities, malware, or misconfigurations these images contain. Developers should pass container images through vulnerability scanners prior to deployment as part of the CI/CD pipeline.
- Host hardening. The security of both containers and the Kubernetes cluster depends on the security of the underlying hosts. If a host is compromised, the attacker can gain access to all of the containers running on it, and even the entire cluster. Standard hardening practices such as applying software updates and security patches, minimizing running processes, and implementing strong authentication and least privilege are essential.
- Minimizing software packages in the golden/base container image. With fewer installed packages, there are fewer potential vulnerabilities for an attacker to exploit. Starting from a minimal base also gives developers more control over image contents, and smaller images can complete vulnerability scans more quickly.
- Container image signing. Digitally signing container images establishes a chain of trust from the developer to the runtime environment. Users can prevent malicious code or unauthorized changes from reaching production by verifying the source and ensuring the integrity of each image prior to deployment.
Cluster
The complexity and flexibility of Kubernetes make it easy for misconfigurations, default settings, and other vulnerabilities to go unnoticed. A comprehensive approach to cluster-level security includes the following best practices:
- Cluster configuration. Misconfigurations in a Kubernetes cluster can be deadly. For example, a compromised API server can be a gateway for incidents such as breaching the sensitive data stored in the cluster, deploying malicious workloads, manipulating cluster resources, and launching a DDoS attack. An exposed Kubelet API that allows anonymous, unauthenticated requests can give attackers access to nodes, secrets, or full control over clusters. Well-defined, consistently enforced standards for cluster configuration can help mitigate such risks.
- Role-based access control (RBAC). RBAC plays a key role in Kubernetes security by controlling access to the Kubernetes API and other cluster resources. By defining fine-grained permissions, enforcing least privilege, and setting up a different RBAC user for each integration, you can help prevent unauthorized access and limit the impact of compromised credentials.
- Namespace isolation. While not a security boundary itself, logically separating the resources within a cluster makes it possible to define resource-specific RBAC and networking policies across pods and namespaces.
- Secure computing mode (seccomp). Seccomp is a key Kubernetes security feature that restricts the system calls (syscalls) a containerized application can make to the kernel. Only allowing authorized syscalls to pass through significantly reduces the risk of kernel-level exploits and container breakout scenarios, where a threat actor uses a container vulnerability to gain access to the broader network.
- Continuous patching. In Kubernetes, patching takes a different form than in a traditional architecture. Instead of being applied to running containers, the latest security patches are regularly applied to base container images in the registry. These updated images are then used to rebuild and redeploy containers as part of the regular container lifecycle, without the need for downtime.
- Proper logging. Event logging in a Kubernetes cluster is essential for security monitoring, compliance, and forensic analysis. API server audit logs capture details of messages and requests within the cluster, including user identities, resources accessed, and operations performed. Node-level logs provide insights into container operations, and they help detect issues like unauthorized access attempts or container breakouts. Pod-level logs can reveal security issues within containerized applications.
- Admission controller configuration. Admission controllers act as gatekeepers for the API server, intercepting and processing authorized requests to the cluster. DevOps teams can set policies and rules to ensure that these requests meet security policies and compliance requirements, prevent privileged or vulnerable containers from running, and ensure appropriate limits on resource consumption.
- Secrets hygiene. As mentioned earlier, hardcoded secrets pose many security issues. Developers should also avoid storing secrets in environment variables or configuration files, which can be easily accessed and exposed. Storing inactive secrets in an external secret management system lets you protect them through encryption at rest and fine-grained access control. Like any password, you should rotate secrets regularly to reduce the risk of long-term exposure.
Cloud
Cloud-native applications run on cloud infrastructure, so any breach of a Kubernetes environment can potentially spread throughout the target’s cloud resources and network. Cloud-level Kubernetes security practices focus on limiting access and enforcing isolation between Kubernetes and its host.
- Least privilege. As a fundamental tenet of zero-trust security, the organization should already be enforcing the principle of least privilege throughout its environment. For Kubernetes, this includes creating the fewest possible user accounts, each limited to role-essential permissions.
- Network access. By default, Kubernetes allows unrestricted interaction between its components. Organizations should configure network policies to block all communications by default, and allow only necessary connections among pods, clusters, and the broader network environment.
- Isolation. Enforcing isolation between cloud environments, containers, and hosts helps limit the extent of a breach and container breakout. Tools and practices mentioned above—such as RBAC, seccomp, and namespace isolation—are all important ways to ensure isolation.
Solving Kubernetes security challenges with Expel
Expel is a leading managed detection and response (MDR) provider that helps organizations realize the full business benefits of cloud-native development while mitigating the risks involved. We provide advanced Kubernetes monitoring and expert analysis for our customers, freeing their DevOps teams to adopt Kubernetes at scale without increasing security concerns so they can focus on building and running the containerized applications that power their business.
Clear, actionable insights at scale
Expel MDR for Kubernetes helps SecOps teams stay one step ahead of attackers by taking on the responsibility of cluster monitoring as a managed service. It’s engineered for the extreme alert volume and analyzes audit logs, applies custom detection logic to alerts on malicious activity, explains findings using the MITRE ATT&CK framework, and offers clear steps for remediation.
Less burden on your team
With deep expertise in Kubernetes environments, Expel analysts work 24×7 to quickly interpret alerts, filter out noise and false positives, and handle real incidents efficiently. By ensuring that only relevant threats are prioritized and resolved, Expel MDR for Kubernetes reduces the burden on overwhelmed internal teams.
Faster detection and remediation
Expel MDR for Kubernetes eliminates blind spots to analyze alerts and detect threats throughout the Kubernetes environment. Automations and workflows help reduce total MTTR to 20 minutes for high/critical alerts.
Tailored security recommendations
To enable proactive risk reduction, Expel MDR for Kubernetes identifies cluster misconfigurations based on the Center for Information Security (CIS) Kubernetes Benchmark, and provides recommended best practices to improve Kubernetes security over time.
Greater value from your existing investments
Expel MDR for Kubernetes helps you strengthen security by working with the technologies you already have in place. The service is compatible with Amazon Elastic Kubernetes Engine (Amazon EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE), and integrates with container security vendors, including CrowdStrike, Wiz, Lacework, and Prisma Cloud Compute Edition (PCCE).
Need more Kubernetes? Here’s more resources to explore:
- Kubernetes Mind Map: A guide to the tactics used most often during attacks in Kubernetes environments, including the Kubernetes services where attacks originate, the API calls made, and tips for investigating related incidents.
- Expel MDR for Kubernetes data sheet: How Expel provides 24×7 detection and response for Amazon EKS, AKS, and GKE Kubernetes environments.
- Secure your Kubernetes environment: Service information, demos, and reports on trends and strategies in cloud and Kubernetes security.
