这个问题最重要的方面是控制将在 Pod 中使用的服务帐户的访问权限以及限制命名空间内流量的网络策略。
因此我们得出了这个算法:
先决条件:
创建用户和命名空间
sudo useradd user-a
kubectl create ns ns-user-a
- 限制 user-a 对命名空间 ns-user-a 的访问权限。
kubectl create clusterrole permission-users --verb=* --resource=*
kubectl create rolebinding permission-users-a --clusterrole=permission-users --user=user-a --namespace=ns-user-a
- 限制命名空间ns-user-a的所有服务账户访问权限。
kubectl create clusterrole permission-serviceaccounts --verb=* --resource=*
kubectl create rolebinding permission-serviceaccounts --clusterrole=permission-serviceaccounts --namespace=ns-user-a --group=system:serviceaccounts:ns-user-a
kubectl auth can-i create pods --namespace=ns-user-a --as-group=system:serviceaccounts:ns-user-a --as sa
- 命名空间 ns-user-a 中的网络策略,用于限制来自其他命名空间的传入流量。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-from-other-namespaces
namespace: ns-user-a
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- podSelector: {}
编辑:允许来自选择性命名空间的流量
使用自定义标签为监控命名空间分配标签。
kubectl label ns monitoring nsname=monitoring
或者,使用以下 kubernetes 保留的标签,以确保没有人可以编辑或更新此标签。所以按照惯例,这个标签应该将“monitoring”作为“monitoring”命名空间的赋值。
https://kubernetes.io/docs/reference/labels-annotations-taints/#kubernetes-io-metadata-name
kubernetes.io/metadata.name
应用网络策略以允许来自内部和监控命名空间的流量。
注意:网络策略总是累加的。因此,您可以保留两者,也可以只保留新的。出于示例目的,我将两者都保留在这里。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-only-monitoring-and-inernal
namespace: ns-user-a
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- podSelector: {} # allows traffic from ns-user-a namespace (same as earlier)
- namespaceSelector: # allows traffic from monitoring namespace
matchLabels:
kubernetes.io/metadata.name: monitoring