Chapter 7. Hard Multitenancy
Sharing a Kubernetes cluster securely is hard. By default, Kubernetes is not configured to host multiple tenants, and work is needed to make it secure. “Secure” means it should be divided fairly between isolated tenants, who shouldn’t be able to see each other and shouldn’t be able to break shared resources for anybody else.
Each tenant may run their own choice of workloads, confined to their own set of namespaces. The combination of security settings in the namespace configuration and the cluster’s access to external and cloud services defines how securely tenants are separated.
Each tenant in a cluster can be considered friendly or hostile, and cluster admins deploy appropriate controls to keep other tenants and the cluster components free from harm. The level of these controls is set for the type of tenants expected by the system’s threat model.
Note
A tenant is the cluster’s customer. They may be a team, test or production environment, a hosted tool, or any logical grouping of resources.
In this chapter you will sail the shark-infested waters of Kubernetes multitenancy and their namespaced “security boundaries.” The control plane’s lockdown techniques are inspected for signs of fraying, we compare the data classification of workloads and their cargo, and look at how to monitor our resources.
Defaults
Namespaces exist to group resources, and Kubernetes doesn’t have an inherent namespace tenancy model. The namespaced tenancy concept only works ...
Get Hacking Kubernetes now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
