RBAC:具有多个命名空间的角色

RBAC: roles with multiple namespaces

正在尝试编写我的第一套 RBAC 角色。因此,试图找出为多个命名空间组件分配 2 个角色的最佳方法。

管理员角色(3 个命名空间的 RW 表示默认,ns1 和 ns2) 用户角色(只读 3 个命名空间,默认为 ns1 和 ns2)

认为 admin/user

需要一个具有 2 个 clusterRoles 的服务帐户
apiVersion: rbac.authorization.k8s.io/v1
kind: ServiceAccount
metadata:
  name: sa
  namespace: default

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin-master
rules:
- apiGroups:
    - batch
  resources:
    - pods
  verbs:
    - create
    - delete
    - deletecollection
    - get
    - list
    - patch
    - update
    - watch

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user-master
rules:
- apiGroups:
    - batch
  resources:
    - pods
  verbs:
    - get
    - list
    - watch

然后使用roleBindings:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: admin-rw
  namespace: ns1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin-master
subjects:
  - kind: ServiceAccount
    name: sa
    namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: user-readonly
  namespace: ns1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: user-master
subjects:
  - kind: ServiceAccount
    name: sa
    namespace: default

但不确定将角色 admin-rw/user-readonly 与命名空间 2 (ns2) 绑定的最佳方式是什么?

角色是有范围的,绑定到特定的命名空间或集群范围。对于命名空间作用域的角色,you can just simply deploy the same role in multiple namespaces.

这背后的想法是在集群中拥有分区权限,虽然 it implies more administrative effort 但这是一种更安全的做法。

此外,在您的定义中,您试图将权限绑定到特定的命名空间,但是,您使用的是 ClusterRole,即 cluster-scoped resource。如果您想要命名空间范围内的权限,您可能需要将其更改为 Role

您可能会发现此 CNCF article 在这件事上很有用。

这个答案是错误的。

ClusterRoleRole定义了你可以操作哪些资源。如果你的角色需要管理多个命名空间中的资源,你需要使用ClusterRole

RoleBinding 定义您的帐户将被授予哪个命名空间。

官方文档中的示例:https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-example

A RoleBinding can also reference a ClusterRole to grant the permissions defined in that ClusterRole to resources inside the RoleBinding's namespace. This kind of reference lets you define a set of common roles across your cluster, then reuse them within multiple namespaces.

For instance, even though the following RoleBinding refers to a ClusterRole, "dave" (the subject, case sensitive) will only be able to read Secrets in the "development" namespace, because the RoleBinding's namespace (in its metadata) is "development".

apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
# You need to already have a ClusterRole named "secret-reader".
kind: RoleBinding
metadata:
  name: read-secrets
  #
  # The namespace of the RoleBinding determines where the permissions are granted.
  # This only grants permissions within the "development" namespace.
  namespace: development
subjects:
- kind: User
  name: dave # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io