Cloud Tenant Isolation: Lessons from a Kubernetes Attack Chain

Cloud security discussions often focus on customer misconfiguration: exposed storage, weak credentials, or publicly reachable services. A penetration test described by Securelist, however, examined a different failure mode—weaknesses inside a cloud provider’s own managed-service infrastructure.

The case study, conducted by Kaspersky Security Services as part of an official bug bounty program, describes how an external tester with ordinary tenant privileges combined weaknesses across managed Kubernetes, the Konnectivity control-plane tunnel, the provider’s overlay network, and several managed databases and messaging services. In the researchers’ test environment, the chain bypassed the boundary intended to separate tenants and created paths toward control of other managed resources.

The infrastructure and cloud provider were anonymized. Securelist reports that the provider was notified responsibly and that all security issues identified in the research were fixed. The report does not describe a confirmed criminal intrusion or identify affected customer organizations.

The central lesson: isolation is a system property

Tenant isolation is not delivered by a single firewall rule or Kubernetes setting. It depends on the interaction of admission controls, node privileges, control-plane services, service identities, network segmentation, secrets handling, and administrative tooling.

In this case, the initial weakness was in a managed Kubernetes cluster running a k0s-based distribution. The cluster allowed a tenant to create a privileged pod with access to host namespaces. That configuration gave the tester a route from a workload into the worker node’s host context and, ultimately, root-level access to that node.

Securelist presents this as a confirmed finding from the authorized test, not as a general claim that every k0s or Kubernetes deployment is vulnerable. The specific cluster configuration and provider-built components were important to the outcome.

From a worker node to the control plane

After reaching the worker node, the researchers inspected local configuration and found a Konnectivity service token. Konnectivity creates a tunnel between Kubernetes control-plane and data-plane components, allowing management traffic to reach worker nodes even where direct connectivity is unavailable.

The test team then analyzed the Konnectivity service used by the cluster. Securelist reports that the provider’s Kubernetes version used a fork of the Konnectivity server inherited from the earlier apiserver-network-proxy project. The service accepted agent messages containing connection requests. In the implementation examined by the researchers, a request from a worker-side agent could cause the control-plane side to initiate a network connection to an address supplied in the request.

That behavior created a server-side request-forgery capability in the control-plane context. The impact was not limited to ordinary network destinations: the researchers also reached local UNIX sockets exposed by the control-plane host. Through the system D-Bus environment, they obtained a non-root user context and were able to create a persistent user-level systemd service. This produced remote code execution on the control-plane host, although initially with limited privileges.

Securelist says Mirantis, which maintains k0s, confirmed the Konnectivity vulnerability. The report does not provide a CVE identifier, and none is included here.

Privilege escalation expanded the attack surface

The control-plane host was running a Salt minion and used Ubuntu 22.04 with a 5.15-series Linux kernel. Securelist reports that enabled user namespaces and an OverlayFS bug provided a path from the limited control-plane process to root privileges.

Once root access was obtained, the researchers discovered an interface on the cloud provider’s internal overlay network. Their assessment found that the overlay was effectively flat across managed services. This meant that a compromised host could see infrastructure belonging to other services and tenants instead of being restricted to the original Kubernetes environment.

This is a key distinction in the chain. The Kubernetes and Konnectivity weaknesses created footholds and execution paths; the flat overlay determined how far that access could travel. A vulnerability in one managed service therefore became relevant to the security of unrelated services on the same network.

Telemetry systems exposed tenant metadata and secrets

The researchers examined the provider’s VictoriaMetrics and VictoriaLogs components. According to Securelist, a VictoriaMetrics API disclosed target information for managed resources, including labels that could associate hosts with clusters and customer-related identifiers. A single query returned control-plane hosts belonging to other tenants in the test environment.

VictoriaLogs also exposed an API that allowed unauthorized access to logs from managed resources. Those logs contained a particularly serious secret-handling problem: cloud-init scripts generated private SSH keys for root accounts and printed them to standard output, where they were retained in shared logs.

By correlating metadata in the monitoring systems, the researchers say they could associate leaked keys with their target hosts and use them to access other tenants’ nodes. The finding illustrates why observability platforms must be treated as privileged infrastructure. Metrics and logs are not harmless metadata when they contain hostnames, credentials, private keys, or control-plane details.

Additional managed-service paths

Securelist describes several further avenues discovered from the shared network. These were not separate campaigns; they were additional attack paths available after the researchers had obtained access to the overlay.

• Kafka and JMX: A managed Kafka host exposed a Java Management Extensions registry on port 9999. The registry’s remote interface was reachable from the shared overlay even though the RMI service should have been restricted to loopback. The researchers used this exposure to demonstrate code execution in the Kafka process context.
• Redis exporter: A Redis exporter accepted a caller-supplied target for metric collection and reused the credentials associated with its primary Redis connection. Securelist reports that this logic allowed credentials to be disclosed to an attacker-controlled endpoint, potentially enabling access to other tenants’ Redis data.
• PostgreSQL and Patroni: An unauthenticated etcd service exposed Patroni configuration. The researchers found that modifying the configuration could turn PostgreSQL’s archiving behavior into a code-execution path on the database host.
• MySQL: The report also describes weaknesses involving configuration-parameter injection, database privilege escalation, dynamic library loading, and a privileged background service. Together, these issues provided a route from database-level access to host-level compromise in the tested service.

These examples reinforce the same architectural problem: management interfaces that are safe only when confined to a local host or tightly controlled network become dangerous when exposed across a shared tenant overlay.

What was demonstrated—and what remains unknown

Securelist’s findings are based on an authorized penetration test rather than evidence of a real-world breach. The researchers demonstrated a chain from regular tenant privileges to worker-node access, control-plane execution, privilege escalation, visibility into the overlay network, and compromise paths affecting other managed services.

The provider and infrastructure were anonymized, so the report does not identify customers, regions, production incidents, or data-loss events. It also does not establish that criminals used the same chain. The research organization’s conclusion is that the combination of vulnerabilities created a complete tenant-isolation bypass in the tested environment—not that all cloud platforms share the same weaknesses.

Detection and threat hunting

Cloud providers should review telemetry for combinations of events rather than searching for one signature. Useful investigation areas include:

• Creation of privileged Kubernetes pods, use of host namespaces, and workloads that violate the provider’s normal pod-security baseline.
• Unexpected access to worker-node files, Kubernetes service-account tokens, Konnectivity credentials, or control-plane addresses.
• Unusual connections involving the Konnectivity listener, control-plane hosts, D-Bus sockets, or user-level systemd services.
• Cross-tenant traffic on overlay interfaces, especially connections from one managed-service class to another.
• Unauthorized queries to metrics and log APIs, access to target-discovery data, and requests that expose labels or configuration metadata.
• Root private keys, database passwords, Redis credentials, or other secrets appearing in logs.
• Unexpected access to Kafka JMX or RMI services, Redis exporter scrape endpoints, etcd, Patroni APIs, and database administration interfaces.
• Changes to PostgreSQL, MySQL, or service-manager configuration followed by new processes, dynamic-library loads, or database restarts.

Defensive teams should preserve control-plane, node, network-flow, service, and audit logs together. The chain described by Securelist crosses several layers; investigating each layer in isolation could miss the relationship between the initial Kubernetes event and later cross-tenant activity.

What organizations should do now

1. Enforce workload isolation: Prevent tenant workloads from creating privileged pods or using host namespaces unless there is a documented, tightly controlled exception. Apply admission policies consistently across every managed cluster.
2. Review control-plane tunnels: Validate Konnectivity or equivalent proxy behavior, authenticate and authorize every agent request, restrict destination protocols and addresses, and prevent access to local sockets or administrative interfaces.
3. Segment the overlay network: Replace flat reachability with service- and tenant-specific network policies. Managed Kafka, Redis, PostgreSQL, MySQL, monitoring, and administration systems should not be mutually reachable by default.
4. Protect observability platforms: Require authentication and authorization for metrics and log APIs. Remove secrets from logs, rotate any credentials that may have been exposed, and treat target-discovery metadata as sensitive.
5. Harden managed-service interfaces: Bind JMX and RMI components to intended interfaces, restrict exporter target selection, authenticate etcd and administrative APIs, and validate configuration values before they reach service files.
6. Reduce host privilege: Use mandatory access controls such as AppArmor where appropriate, disable unnecessary user namespaces, minimize service capabilities, and isolate provider management agents from tenant workloads.
7. Test the trust boundary: Conduct recurring internal penetration tests and carefully scoped bug bounty exercises that begin with ordinary tenant permissions. The objective should be to test not only individual services but also the transitions between them.

Conclusion

The Securelist case demonstrates how cloud isolation can fail through composition. A permissive Kubernetes control, a trusted control-plane tunnel, an overlay network with excessive visibility, and exposed management services each contributed to the final impact. Providers should therefore validate isolation as an end-to-end security property, while tenants should ask how their workloads, credentials, logs, and managed services are separated from those of their neighbors.

Sources

Securelist: “How your cloud could get hacked: an analysis of a real-world vulnerability chain”, by Kaspersky Security Services.