想象一下，你是一家初创公司的技术负责人。公司刚起步，团队只有五个人，大家挤在一个办公室里，共用一台服务器跑测试环境。这时候，谁想用什么资源，吼一声就行，没人管那么多。但很快，公司火了，团队扩张到了五十人，甚至一百人，业务线也分成了前端、后端、数据分析和运维几个小组。
如果这时候你还让所有人共用同一个Kubernetes集群的默认命名空间，或者简单地给每个人一个admin权限，那场面简直就是灾难现场：A组的开发不小心删了B组的生产数据库Pod，C组的实习生为了调试代码把整个节点的CPU占满导致服务宕机，更别提那些敏感的数据泄露风险了。
这就是为什么我们需要“多租户”架构。在Kubernetes的世界里，多租户不仅仅是把用户分开，它是一场关于边界、权限和资源配额的精密舞蹈。今天，我们不讲枯燥的理论，而是直接走进实战，看看如何像装修一套豪华公寓一样，把Kubernetes集群划分成一个个安全、独立且高效的“房间”。
第一层防御：Namespace——逻辑上的“隔间”
很多新手有个误区，认为创建了Namespace就等于完成了隔离。其实不然。Namespace更像是给资源贴标签，而不是装进保险箱。它解决了“谁拥有这个资源”的问题，但没有解决“谁能访问这个资源”以及“能占用多少资源”的问题。
1. 为不同团队创建专属Namespace
假设我们有三个团队：dev-team（开发）、qa-team（测试）和prod-team（生产）。我们首先要在集群中建立这些逻辑边界。
# 创建开发环境命名空间
kubectl create namespace dev-team
# 创建测试环境命名空间
kubectl create namespace qa-team
# 创建生产环境命名空间
kubectl create namespace prod-team
这一步很简单，但关键在于后续的配置。仅仅创建命名空间，默认情况下，集群管理员仍然可以访问所有Namespace里的资源。所以，我们必须引入第二层，也是最重要的一层：RBAC（基于角色的访问控制）。
2. Namespace不是防火墙
你需要清楚一点：在Kubernetes中，如果没有显式的网络策略（NetworkPolicy），Namespace之间的Pod是可以互相通信的。这意味着，如果dev-team里的一个恶意Pod（或者被入侵的Pod）知道prod-team里某个服务的内部IP，它可能发起攻击。因此，Namespace是身份隔离的基础，但不是网络隔离的终点。我们将在后面提到网络策略作为补充，但今天的重点先放在权限和资源上。
第二层防御：RBAC——精准的“门禁卡”
RBAC是Kubernetes安全的核心。它的理念非常直观：最小权限原则。每个用户或服务账户，只能获得完成工作所需的最小权限集合。
1. 理解RBAC的三个核心概念
在动手写YAML之前，我们要理清三个角色：
- User/Group: 真实的人或组织。
- Role/ClusterRole: 权限的定义。Role局限于特定Namespace，ClusterRole则作用于整个集群。
- RoleBinding/ClusterRoleBinding: 将User绑定到Role上。
2. 实战：限制开发团队的权限
假设dev-team的成员需要能够部署应用、查看日志，但绝对不能删除Namespace本身，也不能访问其他Namespace的资源。我们可以创建一个专门针对dev-team的Role。
# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev-team
name: dev-manager
rules:
- apiGroups: ["", "apps", "extensions"]
resources: ["pods", "deployments", "services", "configmaps", "secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["batch"]
resources: ["jobs", "cronjobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
注意看，这里我们没有授予namespaces的操作权限，也没有授予nodes或persistentvolumes的全局权限。这就是精细化的控制。
接下来，我们需要将这个Role绑定给dev-team的用户组。假设我们通过LDAP或OIDC集成，有一个名为group:dev-team的用户组。
# dev-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-team-binding
namespace: dev-team
subjects:
- kind: Group
name: group:dev-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: dev-manager
apiGroup: rbac.authorization.k8s.io
这样，dev-team的所有成员在dev-team这个Namespace内就是“经理”，但在qa-team或prod-team里，他们连看都看不到。
3. 生产环境的严格管控
对于prod-team，我们的策略要更加保守。通常，生产环境不建议开发人员直接操作，而是通过CI/CD管道（使用ServiceAccount）来部署。人类用户只拥有“查看”权限。
# prod-viewer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: prod-viewer
rules:
- apiGroups: ["", "apps", "extensions"]
resources: ["pods", "deployments", "services", "replicasets"]
verbs: ["get", "list", "watch"]
# 注意：这里没有create, update, delete, patch等写操作权限
绑定给生产环境的运维人员：
# prod-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prod-viewer-binding
subjects:
- kind: Group
name: group:ops-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: prod-viewer
apiGroup: rbac.authorization.k8s.io
这样，即使ops-team的成员误操作，他们也无法删除生产环境的关键服务，只能查看状态。这大大降低了人为事故的风险。
第三层防御：Resource Quotas & LimitRanges——防止“邻居噪音”
有了权限隔离，还有一个大问题：资源争抢。如果一个团队开发了内存泄漏的程序，或者运行了一个高负载的计算任务，它们可能会耗尽节点上的CPU或内存，导致其他团队的服务崩溃。这就是所谓的“吵闹的邻居”问题。
Kubernetes提供了两种机制来解决这个问题：ResourceQuota 和 LimitRange。
1. ResourceQuota：设定“房间”的大小上限
ResourceQuota限制的是整个Namespace级别的资源总和。比如，我们规定dev-team最多只能使用4个CPU核和8GB内存。
# dev-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev-team
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
pods: "20" # 最多同时运行20个Pod
services: "10"
当dev-team创建的Pod总请求资源超过8GB内存时，Kubernetes会拒绝创建新的Pod，并返回错误信息。这从源头上遏制了资源滥用。
2. LimitRange：设定单个“床位”的大小上下限
有时候，我们不仅要限制总量，还要防止某个用户创建一个超级大的Pod，即使总量没超，也可能导致调度不均。LimitRange可以设置单个Pod或Container的资源最小值和最大值。
# dev-limits.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: dev-limits
namespace: dev-team
spec:
limits:
- default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 200m
memory: 256Mi
max:
cpu: "2"
memory: 4Gi
min:
cpu: 100m
memory: 128Mi
type: Container
在这个配置下：
- 如果开发者没有指定资源请求，系统会自动分配200m CPU和256Mi内存。
- 单个容器的CPU不能超过2核，内存不能超过4Gi。
- 单个容器的CPU不能低于100m，内存不能低于128Mi。
这种双重限制确保了资源的公平分配和系统的稳定性。
第四层防御：NetworkPolicy——隐形的“墙壁”
前面提到过，Namespace不是防火墙。为了实现真正的隔离，特别是防止跨Namespace的网络访问，我们需要启用NetworkPolicy。
注意：你的集群必须安装支持NetworkPolicy的CNI插件（如Calico, Cilium, Romana等）。默认的Flannel通常不支持。
1. 默认拒绝所有流量
我们可以为每个Namespace创建一个默认策略，拒绝所有入站和出站流量，然后只允许必要的通信。
# default-deny-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: prod-team
spec:
podSelector: {}
policyTypes:
- Ingress
这段YAML的意思是：在prod-team命名空间中，选择所有的Pod（podSelector: {}为空表示全选），并且不开放任何入站流量。
2. 允许特定的访问
如果prod-team中的Web服务需要访问数据库服务，我们需要显式地允许这种通信。
# allow-web-to-db.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-web-to-db
namespace: prod-team
spec:
podSelector:
matchLabels:
app: database
ingress:
- from:
- podSelector:
matchLabels:
app: web-frontend
ports:
- protocol: TCP
port: 5432
这里我们允许带有app: web-frontend标签的Pod，通过TCP端口5432访问带有app: database标签的Pod。其他所有流量都被拒绝。
这种细粒度的网络控制，使得即使在同一集群中，不同租户之间的数据流动也是受控且可审计的。
高级技巧：使用Label进行动态管理
在实际操作中，手动编写大量的RBAC和Quota YAML文件是非常繁琐且容易出错的。现代Kubernetes管理往往结合GitOps工具（如ArgoCD或Flux）以及自定义控制器来实现自动化。
例如，你可以定义一个自定义资源（CRD）叫做Tenant，当你在集群中创建一个Tenant对象时，一个Operator会自动为你创建对应的Namespace、RBAC规则、ResourceQuota和NetworkPolicy。
# my-tenant.yaml
apiVersion: tenant.example.com/v1
kind: Tenant
metadata:
name: marketing-team
spec:
namespace: marketing-team
resourceLimits:
cpu: "4"
memory: "8Gi"
allowedNamespaces: []
readOnly: false
这种方式不仅提高了效率，还确保了配置的一致性，避免了因人工失误导致的安全漏洞。
常见问题与避坑指南
1. ServiceAccount的权限陷阱
很多应用需要在集群内调用API Server（比如监控组件、自动扩缩容组件）。默认情况下，Pod会使用其所在Namespace的default ServiceAccount。如果这个SA被绑定了过高的权限（比如ClusterAdmin），那将是一个巨大的安全隐患。
最佳实践：
- 为每个应用创建专用的ServiceAccount。
- 只赋予该SA执行其功能所需的最小权限。
- 永远不要直接使用
defaultSA用于关键业务。
# app-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-app-sa
namespace: prod-team
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: my-app-role
namespace: prod-team
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: my-app-binding
namespace: prod-team
subjects:
- kind: ServiceAccount
name: my-app-sa
namespace: prod-team
roleRef:
kind: Role
name: my-app-role
apiGroup: rbac.authorization.k8s.io
然后在Deployment中引用这个SA：
spec:
serviceAccountName: my-app-sa
containers:
- name: my-app
image: my-app:latest
2. Secret的管理
Secret用于存储密码、密钥等敏感信息。在RBAC中，确保只有必要的ServiceAccount或用户才能读取特定的Secret。不要将所有Secret都放在同一个Namespace里，也不要让所有人都能列出Secret。
3. 审计日志
无论你的RBAC配置多么完美，都要开启审计日志（Audit Log）。Kubernetes的审计日志记录了谁在什么时候做了什么操作。当发生安全事件时，这是追溯根源的唯一依据。
配置审计策略：
# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
resources:
- group: ""
resources: ["secrets"]
- level: Metadata
resources:
- group: ""
resources: ["pods", "services"]
结语：安全是一个过程，不是一个产品
构建Kubernetes多租户环境，不是一次性的任务，而是一个持续的过程。随着业务的发展，团队结构的变化，新的威胁不断出现，你的隔离策略也需要不断调整。
记住几个核心原则：
- 最小权限：只给必要的权限，不多给一个字节。
- 默认拒绝：在网络和访问控制上，先假设一切都是危险的，再逐一放行。
- 资源隔离：防止一个租户的行为影响其他租户的可用性。
- 可见性：通过日志和监控，让你能看到正在发生什么。
当你把这些层次叠加在一起——Namespace做逻辑划分，RBAC做权限控制，ResourceQuota做资源限制，NetworkPolicy做网络隔离——你就为你的团队打造了一个既灵活又安全的云原生家园。在这里，开发可以大胆创新，运维可以放心托管，而管理层则能看到清晰的账单和责任归属。
希望这篇实战指南能帮助你更好地驾驭Kubernetes的多租户能力。如果有具体的场景需要进一步探讨，欢迎随时交流。毕竟，在这个领域，没有人是一座孤岛，我们都在同一片海域航行。