Kubernetes 中用户或角色的命名空间

Question

我知道角色用于授予用户或服务帐户在特定命名空间中执行操作的权限。
一个典型的角色定义可能是这样的

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: mynamespace
  name: my-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

但是在service account的定义中，我们也可以看到namespace字段

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceac
  namespace: mynamespace

我的问题是：
1.命名空间范围是否应用于user/service帐户或角色？
2. 如果service account和role中的namespace不一样怎么办

角色绑定定义供参考

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: my-rolingbinding
  namespace: mynamespace
subjects:
- kind: ServiceAccount
  name: my-serviceac
  namespace: mynamespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: my-role

Answer 1

命名空间应用于角色、服务帐户和角色绑定这三者。
命名空间的角色和服务帐户是否不同并不重要。您仍然可以创建角色绑定，但服务帐户将只能在角色中定义的命名空间中访问对资源执行动词，并且需要在与角色相同的命名空间中创建角色绑定。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: mynamespace
  name: my-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-serviceac
  namespace: default

kubectl create rolebinding my-role-binding --role=my-role --serviceaccount=default:myserviceac -n mynamespace

然后查看服务账号的权限

kubectl auth can-i get pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes
kubectl auth can-i watch pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes

kubectl auth can-i list pods -n mynamespace --as=system:serviceaccount:default:myserviceac
yes

kubectl auth can-i get pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n default --as=system:serviceaccount:default:myserviceac
no

正如我们所见，服务帐户在 mynamespace 中获得了 get,watch,list pods 的权限，但在 default 命名空间中没有相同的权限，尽管服务帐户位于 default 命名空间中。

现在，如果我删除角色绑定并在默认命名空间而不是我的命名空间中创建它。

kubectl create rolebinding my-role-binding --role=my-role --serviceaccount=default:myserviceac -n default

kubectl auth can-i get pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n default --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n default --as=system:serviceaccount:default:myserviceac
no

kubectl auth can-i get pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i list pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no
kubectl auth can-i watch pods -n mynamespace --as=system:serviceaccount:default:myserviceac
no

可以看出权限已经没有申请了

Answer 2

Service Account as Role 资源是命名空间范围的：这允许将特定操作限制为给定的经过身份验证的用户（在本例中, 服务帐户) 根据角色.

既然我们在谈论 RBAC，您需要第三个资源来将特定的角色资源绑定到给定的 服务帐户：角色绑定，另一个命名空间范围的资源，将这些策略映射到一组给定的用户。

由于所有这三个组件都是严格命名空间，因此它们都必须位于同一命名空间中：否则，引用服务帐户将不起作用。

Kubernetes 中用户或角色的命名空间

Namespace for User or Role in Kubernetes

namespaces

rbac

kubernetes