Summary
Kamaji's Hosted Control Plane Manager for Kubernetes previously derived datastore schemas, database users, and etcd key prefixes from a lossy normalization of tenant identifiers.
When distinct tenants collided after normalization, they could unintentionally share control-plane state and gain the ability to read, modify, or destroy another tenant's Kubernetes data under certain multi-tenant deployment conditions.
Kamaji's Hosted Control Plane Manager for Kubernetes previously derived datastore schemas, database users, and etcd key prefixes from a lossy normalization of tenant identifiers.
When distinct tenants collided after normalization, they could unintentionally share control-plane state and gain the ability to read, modify, or destroy another tenant's Kubernetes data under certain multi-tenant deployment conditions.
Affected context
This vulnerability affects Kamaji deployments that host multiple Kubernetes tenant control planes on shared infrastructure.
It becomes relevant where tenant datastore schemas, usernames, and etcd prefixes are automatically derived from namespace-and-name identifiers using normalization that can produce collisions.
In such environments, different tenants whose identifiers normalize to the same value may end up sharing backing storage and control-plane state, weakening logical isolation between their clusters.
This vulnerability affects Kamaji deployments that host multiple Kubernetes tenant control planes on shared infrastructure.
It becomes relevant where tenant datastore schemas, usernames, and etcd prefixes are automatically derived from namespace-and-name identifiers using normalization that can produce collisions.
In such environments, different tenants whose identifiers normalize to the same value may end up sharing backing storage and control-plane state, weakening logical isolation between their clusters.
Exploit preconditions
- Attack surface: Tenant Kubernetes control planes managed by Kamaji on shared datastore and etcd infrastructure.
- Required access: Valid tenant-level access to one of the affected control planes (e.g., ability to interact with its Kubernetes API or datastore).
- Trigger point: Creation or operation of tenant control planes whose normalized namespace-and-name identifiers collide, causing shared datastore schema, database user, or etcd key prefix.
- Why exploitation is possible: The normalization logic is lossy, meaning different raw identifiers can map to the same normalized value. Kamaji then uses this normalized value to derive datastore and etcd isolation boundaries, enabling one tenant to access or interfere with another tenant's control-plane data when collisions occur.
- Attack surface: Tenant Kubernetes control planes managed by Kamaji on shared datastore and etcd infrastructure.
- Required access: Valid tenant-level access to one of the affected control planes (e.g., ability to interact with its Kubernetes API or datastore).
- Trigger point: Creation or operation of tenant control planes whose normalized namespace-and-name identifiers collide, causing shared datastore schema, database user, or etcd key prefix.
- Why exploitation is possible: The normalization logic is lossy, meaning different raw identifiers can map to the same normalized value. Kamaji then uses this normalized value to derive datastore and etcd isolation boundaries, enabling one tenant to access or interfere with another tenant's control-plane data when collisions occur.
Why this happens
The underlying issue stems from weak privilege separation and isolation boundaries tied to an unsafe identifier normalization process.
Kamaji's GetDefaultDatastoreSchema() and GetDefaultDatastoreUsername() functions used a lossy normalization of tenant namespace-and-name values to generate datastore schema names, usernames, and etcd prefixes.
Because this mapping is not injective, distinct tenant identifiers can collide and produce identical derived values, causing multiple tenant control planes to share the same logical backing resources.
This maps to CWE-284: Improper Access Control and CWE-653: Improper Isolation or Segmentation, where tenants are not rigorously segregated and access control relies on ambiguous identifiers rather than robust, unique boundaries.
The underlying issue stems from weak privilege separation and isolation boundaries tied to an unsafe identifier normalization process.
Kamaji's GetDefaultDatastoreSchema() and GetDefaultDatastoreUsername() functions used a lossy normalization of tenant namespace-and-name values to generate datastore schema names, usernames, and etcd prefixes.
Because this mapping is not injective, distinct tenant identifiers can collide and produce identical derived values, causing multiple tenant control planes to share the same logical backing resources.
This maps to CWE-284: Improper Access Control and CWE-653: Improper Isolation or Segmentation, where tenants are not rigorously segregated and access control relies on ambiguous identifiers rather than robust, unique boundaries.
Potential impact
- A tenant may read Kubernetes control-plane data belonging to another tenant.
- A tenant could modify or delete another tenant's resources, impacting cluster availability.
- Cross-tenant configuration tampering could lead to service outages or data corruption.
- Multi-tenant security guarantees can be undermined, potentially enabling lateral movement between clusters.
- A tenant may read Kubernetes control-plane data belonging to another tenant.
- A tenant could modify or delete another tenant's resources, impacting cluster availability.
- Cross-tenant configuration tampering could lead to service outages or data corruption.
- Multi-tenant security guarantees can be undermined, potentially enabling lateral movement between clusters.
General mitigation guidance
Effective mitigation focuses on strengthening multi-tenant isolation and eliminating identifier collisions in resource derivation.
Common defensive patterns include:
- Deriving datastore schemas, usernames, and etcd prefixes from cryptographically strong or globally unique identifiers rather than normalized names.
- Ensuring that tenant isolation boundaries (schemas, databases, keyspaces) are unique by construction and cannot collide due to formatting or truncation.
- Applying explicit authorization checks and ownership validation when accessing control-plane state or shared infrastructure components.
- Designing multi-tenant systems with strict segmentation, such as per-tenant namespaces, databases, or keyspaces, and treating identifier normalization as purely cosmetic rather than a source of isolation keys.
- Minimizing reliance on human-readable names for access control decisions and instead using stable, immutable IDs.
Effective mitigation focuses on strengthening multi-tenant isolation and eliminating identifier collisions in resource derivation.
Common defensive patterns include:
- Deriving datastore schemas, usernames, and etcd prefixes from cryptographically strong or globally unique identifiers rather than normalized names.
- Ensuring that tenant isolation boundaries (schemas, databases, keyspaces) are unique by construction and cannot collide due to formatting or truncation.
- Applying explicit authorization checks and ownership validation when accessing control-plane state or shared infrastructure components.
- Designing multi-tenant systems with strict segmentation, such as per-tenant namespaces, databases, or keyspaces, and treating identifier normalization as purely cosmetic rather than a source of isolation keys.
- Minimizing reliance on human-readable names for access control decisions and instead using stable, immutable IDs.
How teams detect issues like this
Detection strategies typically focus on identifying ambiguous isolation boundaries and verifying that tenant resources are truly segregated:
- Static analysis or configuration review of code paths that derive datastore schemas, database usernames, and etcd prefixes from tenant identifiers, looking for lossy normalization, truncation, or character stripping.
- Policy-based checks that assert one-to-one mappings between tenant objects and backing datastore resources, flagging any reuse or collision.
- Runtime monitoring for unexpected cross-tenant access patterns, such as a single database schema or etcd prefix serving multiple tenants.
- Automated code review tools and CI pipelines that enforce secure multi-tenancy design patterns, including unique keyspace derivation and robust access control boundaries.
Detection strategies typically focus on identifying ambiguous isolation boundaries and verifying that tenant resources are truly segregated:
- Static analysis or configuration review of code paths that derive datastore schemas, database usernames, and etcd prefixes from tenant identifiers, looking for lossy normalization, truncation, or character stripping.
- Policy-based checks that assert one-to-one mappings between tenant objects and backing datastore resources, flagging any reuse or collision.
- Runtime monitoring for unexpected cross-tenant access patterns, such as a single database schema or etcd prefix serving multiple tenants.
- Automated code review tools and CI pipelines that enforce secure multi-tenancy design patterns, including unique keyspace derivation and robust access control boundaries.
