
projectcapsule/capsule
CVE History
| CVE | Published | CVSS v3 | CVSS v2 |
|---|---|---|---|
| 3.9 LOW | — | ||
Capsule is a multi-tenancy and policy-based framework for Kubernetes. To defend against namespace hijacking achieved through update/patch operations on namespaces, Capsule uses a webhook to validate update requests targeting namespaces. However, in Kubernetes, the namespace/finalize and namespace/status subresource APIs can also modify various fields of a namespace, including the metadata field. Prior to version 0.13.0, the webhook does not define interception rules for these subresources. As a result, if a tenant administrator has permission to modify namespace/status or namespace/finalize, they can successfully perform namespace hijacking. Version 0.13.0 fixes the issue. Another mitigation is to add two subresources (namespaces and snamespaces/status with namespace/finalize within it) to the resources list in the ValidatingWebhookConfiguration rules. | |||
| 9.1 CRITICAL | — | ||
Capsule is a multi-tenancy and policy-based framework for Kubernetes. The Capsule Controller runs with cluster-admin privileges. Although the TenantResource RawItems processing logic forcibly sets the namespace, this is ineffective for cluster-scoped resources. Prior to version 0.13.0, tenant administrators can leverage the Controller's elevated privileges to create cluster-scoped resources (such as ClusterRole and ValidatingWebhookConfiguration) that they cannot create directly, achieving cross-tenant privilege escalation and cluster-level attacks. The attack vector has a few limiting factors. This attack requires Tenant Owner privileges and requires Capsule Controller running with cluster-admin privileges (default configuration). Additionally, some clusters may have additional admission controllers blocking malicious resources. Version 0.13.0 patches this issue. | |||
| 9 CRITICAL | — | ||
Capsule is a multi-tenancy and policy-based framework for Kubernetes. A namespace label injection vulnerability in Capsule v0.10.3 and earlier allows authenticated tenant users to inject arbitrary labels into system namespaces (kube-system, default, capsule-system), bypassing multi-tenant isolation and potentially accessing cross-tenant resources through TenantResource selectors. This vulnerability enables privilege escalation and violates the fundamental security boundaries that Capsule is designed to enforce. This vulnerability is fixed in 0.10.4. | |||
| 8.4 HIGH | — | ||
Capsule is a multi-tenancy and policy-based framework for Kubernetes. In Capsule v0.7.0 and earlier, the tenant-owner can patch any arbitrary namespace that has not been taken over by a tenant (i.e., namespaces without the ownerReference field), thereby gaining control of that namespace. Version 0.7.1 contains a patch. | |||
| 8.8 HIGH | — | ||
Capsule is a multi-tenancy and policy-based framework for Kubernetes. Prior to version 0.1.3, a ServiceAccount deployed in a Tenant Namespace, when granted with `PATCH` capabilities on its own Namespace, is able to edit it and remove the Owner Reference, breaking the reconciliation of the Capsule Operator and removing all the enforcement like Pod Security annotations, Network Policies, Limit Range and Resource Quota items. An attacker could detach the Namespace from a Tenant that is forbidding starting privileged Pods using the Pod Security labels by removing the OwnerReference, removing the enforcement labels, and being able to start privileged containers that would be able to start a generic Kubernetes privilege escalation. Patches have been released for version 0.1.3. No known workarounds are available. | |||