Breaking Down The Silos In Kubernetes Security With Uptycs Unified Kubernetes Risk Insights

 Step 2: Unified Risk Assessment and Attribution

This is the Uptycs Blast Radius Mitigation Framework, consisting of five key steps for comprehensive cloud security:

1. Threat Detection in Workloads
2. Unified Risk Assessment and Attribution
3. Containment through Policy Enforcement
4. Root Cause Analysis & Image Provenance
5. DevSecOps Guardrails & Risk Mitigation

In this post, we cover Step 2: Unified Risk Assessment and Attribution, which builds on threat detection by providing critical context to understand each threat's potential impact. Once a threat is identified, this second step adds essential insights around asset exposure, lateral movement potential, and access to sensitive data, helping teams assess the threat’s broader implications. This comprehensive analysis enables security teams to prioritize their response actions, focusing on areas most vulnerable to escalation. In this blog, we dive into the importance of this second step, illustrating how it informs strategic, prioritized decision-making that strengthens organizational defenses​​.

Organizations have long taken a siloed approach to addressing Kubernetes security risks in their environment through static compliance and misconfiguration scanning or image vulnerability scanning. However, Uptycs intelligently combines insights and presents attack paths to crown jewel assets and presents a unified risk score for every container. This enables security teams to triage and prioritize the most critical risks based on runtime and Kubernetes context that assesses the likelihood of a breach and the potential severity of a breach for every container workload.

The move to Kubernetes across enterprises has been massive, with a recent CNCF survey showing over 95% of organizations using Kubernetes or planning to do so. Kubernetes has its superpowers when it comes to fault-tolerant orchestration and in-built controls inside the cluster for RBAC, governance, networking, and more.

Kubernetes security is crucial as the platform’s complexity presents a wide attack surface, often exploited by recent breaches including cryptomining attacks and privilege escalation. However, with greater control comes greater risk and the complexity of Kubernetes security presents a wide attack surface which has shown to be wildly exploited by recent breaches including the following:

• Kinsing Malware: This attack targeted exploitable vulnerabilities and exposed postgres containers for cryptocurrency mining. Once the attacker gained foothold in one part of the environment, they were able to move laterally in other parts of the cluster. 
• RBAC Buster: This persistence based attack was due to excessive permissions that came from the kube-system namespace where then a new cluster role with admin privileges was created and tied to a service account. Next the attacker was able to do anything - in this case create daemon sets to hijack resources and steal data in the cloud account.
• WireServing: This privilege escalation based attack was due to not securing the credentials while node provisioning in AKS. A pod with command execution can access TLS bootstrap tokens of the node. Using these tokens an attacker can steal secrets stored in the cluster.

With these types of attacks, the following is clear: Your CNAPP needs to go a level deeper than traditional agentless/image scanning for Kubernetes security:

• Runtime Insights: Without data from runtime, it is extremely hard to be able to prioritize the most critical risks and vulnerabilities in your cluster. A vulnerability that is loaded into memory and internet facing likely deserves more attention than others. Similarly a container that is being exploited for a real-time threat such as a reverse shell definitely deserves attention.
• Kubernetes security with RBAC: With identity being the initial attack vector into a cluster, it is important to not only be able to understand cloud permissions but understand the deeper context on what users, service accounts, and groups inside the cluster can access and what permissions they have that can lead to malicious attacks such as privilege escalations and container escapes.
• Build To Runtime Image Provenance: With attacks moving from exploiting vulnerabilities and malware to injecting malicious code, an understanding of what malicious code commits went into your runtime deployments and who is responsible is absolutely critical to root cause analysis.
• Deeper understanding of Kubernetes networking: The severity of an attack inside a cluster can be controlled via network policies. Similarly, many CNAPPs flag internet exposure without an understanding that the container may be protected because of network policies, which act as a final “firewall”. This creates many false positives when it comes to risk prioritization.
• Admission Controls: Risk remediation comes down to understanding the profile of the types of insecure deployments that can be blocked through governance based policies.

Fellow analyst James Berhoty summarizes this nicely in terms of Kubernetes security maturity in the CNAPP Market:

Source: The Kubernetes Gap in CNAPP

Uptycs Kubernetes Risk Prioritization

Risk Calculation

As seen above, factoring all these insights in isolation is extremely hard and creates a siloed approach where key attack paths and critical risks are missed. Uptycs takes the heavy lifting by correlating insights from runtime, Kubernetes control plane, audit logs, and cloud control plane. These are mapped to breach likelihood and severity and turned into a single risk assessment score, which significantly enhances Kubernetes security.

These include the following:

Breach Likelihood:

Runtime Threat Detections: such as reverse shells, cryptominers and more with correlation to potentially malicious Kubernetes control plane activity and code commits in the developer pipeline.

Internet Exposure: While many CNAPP solutions look at Kubernetes load balancers, node ports, and services as well as cloud security groups, NACLs, the missing ingredient is looking at Network Policies which act as means of defense against exposure and lateral movements. If your risk engine is not telling you if a network policy is active, you’re missing key context.

Uptycs not only provides visibility into the full internet exposure path and attack path to crown jewels in the cloud, but integrates with Cilium network policies to show you which network policy is active and whether it is causing internet exposure risk or not.

Pod Security Context/Misconfigurations: If a pod is running as root or has host network access, it has the ability to escalate into the cloud and get access to crown jewels such as S3 buckets with data.

Vulnerabilities: Exploitable vulnerabilities with packages that are in-use by running processes.

Malware: Images detected with cryptominers and ransomware that are deployed.

Impact severity:

RBAC: With identity being a key attack vector for escalation of privileges and lateral movements, it is extremely important to understand excessive permissions in the cluster. Many clusters also come with default service accounts which are great for dev/test but in production are very risky and when exploited can lead to loss of data and open attack paths.

Exposed Secrets: Credentials that are exposed are more likely to be exploited to access sensitive information and data.

Risk Prioritization

With this unified risk calculation, security teams can prioritize the most critical risks on a daily basis across their container and Kubernetes inventory.

Risk Remediation and Prevention

While this blog focuses on risk prioritization, here is a glimpse of what Uptycs can enable for security teams to mitigate risks in real-time and prevent future threats and risks from happening:

• Runtime Protection Engine: Stop malicious threats such as cryptominers, reverse shells and ransomware in real-time before they happen.
• Container Process Blocking and Remediation: block malicious processes from spawning or kill a container process if detected against a malicious threat.
• Kubernetes Deployment Hardening via Admission Controls: Control what is allowed for deployment in your clusters for any resource and make sure they are compliant/have the right posture.
• Image Hardening via Policies: Only allow hardened images to be built and deployed. If images contain exploitable vulnerabilities, malware, secrets, or do not come from trusted sources, fail builds and deployments across the development pipeline to only allow hardened artifacts into runtime. Trace vulnerabilities back to image layers in a Dockerfile to enable developers to fix at the source.

Why Uptycs For Kubernetes Risk Prioritization

With Unified Risk Assessment and Attribution complete, the next step in the Uptycs Blast Radius Mitigation Framework focuses on rapid threat containment— continue reading to understand each stage of our end-to-end protection approach.