Tenant Isolation

Tenant isolation on OSC is implemented through several independent boundaries rather than through a single control.

Customer worker nodes run on customer-specific compute pools. This prevents workloads from different customers from sharing the same physical compute pool. Each Shoot also receives its own Kubernetes cluster and its own logical network domain.

The network layer separates tenant traffic through isolated virtual networks. A workload in one network cannot simply address resources in another tenant network. Connections between environments must be created deliberately through services such as peering, load balancing or VPN.

Storage is provided as a shared regional service, but access is controlled through separate volumes, buckets, credentials and platform authorization. Customers receive access to their own storage resources, not to the storage control plane or physical disks.

The managed Kubernetes architecture adds another boundary. Shoot control planes run in isolated namespaces on provider-managed Seed clusters, while customer workloads run on the dedicated worker layer. Access between the management and workload environments is restricted to the communication required for cluster operation.

Note

Strong isolation still depends on correct customer configuration inside the Shoot. Namespace design, Kubernetes RBAC, NetworkPolicies and application credentials remain important because users with broad cluster-admin rights can affect all workloads in their own cluster.