A significant security flaw has been discovered in Kubernetes Capsule versions up to v0.10.3, enabling authenticated tenant users to inject arbitrary labels into system namespaces. This vulnerability compromises multi-tenant isolation controls, posing a substantial risk to organizations utilizing Capsule for Kubernetes multi-tenancy.
Key Points:
1. Vulnerability Identification: Capsule v0.10.3 permits tenant users to inject labels into system namespaces.
2. Security Implications: Such label injection can lead to unauthorized cross-tenant resource access via TenantResource selectors.
3. Recommended Action: Immediate upgrade to version 0.10.4 is advised to prevent potential privilege escalation.
Understanding the Namespace Injection Vulnerability
The core issue lies within the namespace validation webhook logic, specifically in the file `pkg/webhook/namespace/validation/patch.go` between lines 60 and 77. Here, the conditional check validates tenant ownership only when a namespace already possesses a tenant label. This oversight allows authenticated tenant users to inject labels into system namespaces that lack the `capsule.clastix.io/tenant` label by default, such as `kube-system`, `default`, and `capsule-system`.
This vulnerability is reminiscent of CVE-2024-39690, which involved ownerReference manipulation. However, in this case, the attack vector is label injection. By exploiting this flaw, attackers can inject malicious labels into unprotected system namespaces using standard `kubectl patch` commands. Subsequently, they can create malicious TenantResource objects that utilize namespace selectors to target these injected labels, effectively gaining access to system namespace resources.
The attack sequence can be outlined as follows:
1. Label Injection: The attacker injects a label into a system namespace.
2. Namespace Selector Exploitation: The attacker uses a namespace selector to match the injected label.
3. TenantResource/Quota Check Bypass: The attacker circumvents authentication policies.
4. Cross-Tenant Resource Access: The attacker gains unauthorized access to resources across tenants.
This progression effectively bypasses Capsule’s intended security boundaries, leading to potential privilege escalation and unauthorized access.
Mitigation Strategies
Organizations operating multi-tenant Kubernetes clusters with Capsule v0.10.3 or earlier are at significant risk. The security implications include:
– Multi-Tenant Isolation Bypass: Attackers can access resources across different tenants.
– Privilege Escalation: Unauthorized users may gain elevated privileges.
– Data Exfiltration: Sensitive information from system namespaces could be extracted.
– Resource Quota Circumvention: Attackers might bypass resource limitations.
– Policy Violations: Established security policies could be undermined.
Exploitation of this vulnerability could allow attackers to access sensitive secrets within the `kube-system` namespace, including cluster certificates and service account tokens. They might also modify critical system configurations, potentially leading to a cluster-wide compromise.
To address this critical security flaw, it is imperative for organizations using affected Capsule versions to upgrade immediately to version 0.10.4. The updated version implements robust validation mechanisms to prevent unauthorized label injection into system namespaces, thereby restoring the intended multi-tenant isolation boundaries essential for secure Kubernetes operations.
