Hello and welcome to this edition of Ctrl+Alt+Deploy! I’m Lauro Müller, and I’m super happy to have you here with me 😄 Let’s dedicate the next few minutes to sharpening our skills and learning something new and relevant for running production systems 💪 Today we're going to spend some time on multi-tenancy, and on the objects that have to exist in a team's namespace before that team is separated from the others.
🚀 New Content! EKS Access Entries
I just added a new section on access management to my new Amazon EKS with Terraform 🎉 It covers how AWS identities reach a cluster and what they may do once they are in. The section’s 4 labs work through the two objects that resolve this, an access entry and an access policy association, and use them to give a developer role and a platform administrator role the access each one needs, cluster-wide in one case and scoped to a single namespace in the other. The last lab declares the same kind of grant through the community EKS module instead, so you can compare both routes on one cluster.
So if you still haven’t grabbed the course, make sure to check it out and use the link below for a huge discount! 🙂
I hope to see you in the course, and now on to our multi-tenant isolation discussion!
A Kubernetes cluster shared between several teams is usually described in terms of namespaces: each team gets one, and the namespace is what keeps them apart. In reality, a namespace on its own keeps very little apart. What people have in mind when they say "tenant isolation for teams" comes from a handful of other objects created inside that namespace, each covering a different dimension of the problem.
This edition discusses multi-tenancy from the perspective of multiple teams within one organization sharing the same Kubernetes cluster. Teams hold credentials and create objects, so every control discussed here is something a team can see, use, and in some situations edit. There is usually some level of trust between teams in that arrangement, which is what makes namespace-based isolation a reasonable starting point, though trust between colleagues is not the same thing as a well-defined and enforced boundary. Where tenants genuinely do not trust each other, the controls described here are not sufficient, and we briefly explore what needs to change towards the end of the article.
When conceptualizing multi-tenance, four main questions come to the table for each team: who can act inside the namespace, how much they can consume, what they can reach over the network, and what their workloads are allowed to do on the nodes they land on. Each one maps to Kubernetes objects you create.
10x the context. Half the time.
Speak your prompts into ChatGPT or Claude and get detailed, paste-ready input that actually gives you useful output. Wispr Flow captures what you'd cut when typing. Free on Mac, Windows, and iPhone.
What a namespace scopes, and what it leaves open
A namespace scopes names. Resource names have to be unique within a namespace but not across namespaces, so two teams can both run a Deployment called api and a Service called db without coordinating, which removes a category of friction that has nothing to do with security. This scoping applies only to namespaced objects: cluster-wide objects such as Nodes, PersistentVolumes and StorageClasses do not belong to any namespace, and you can see the full split on any cluster with kubectl api-resources --namespaced=false.