Question

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

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: mynamespace

我的问题是：
1.名称空间范围是否适用于用户/服务帐户或角色？
2.如果服务帐户中的名称空间和角色不同

角色绑定定义以供参考

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中获取，监视，列出pod的权限，但是尽管该服务帐户位于默认名称空间中，但在默认名称空间中没有相同的权限。

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

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

服务帐户作为角色资源是命名空间范围的：这允许将特定操作限制为给定的经过身份验证的用户（在本示例中，服务帐户< / em>）根据角色。

由于我们在谈论 RBAC ，因此您需要第三种资源将特定的 Role 资源绑定到给定的 Service帐户： 角色绑定，这是将这些策略映射到给定的一组用户的另一个命名空间范围的资源。

由于这三个组件都是严格的名称空间，因此它们必须都位于同一名称空间中：否则，引用服务帐户将无效。

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

2 个答案: