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

【问题标题】：Namespace for User or Role in KubernetesKubernetes 中用户或角色的命名空间
【发布时间】：2020-02-26 09:56:12
【问题描述】：

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

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

【问题讨论】：

标签： kubernetes namespaces rbac

【解决方案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

可以看出权限不再应用了。

【讨论】：

是第二个创建角色绑定命令的错字吗？命名空间应该是默认的，比如 -n default？
谢谢，非常明确的答案。再问一个问题，如果不影响权限，为什么还要给服务账户添加命名空间？
它可以控制哪些人和谁可以访问服务帐户。例如，Pod 只能使用当前命名空间中的服务帐户来调用 Kubernetes API

【解决方案2】：

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

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

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

【讨论】：