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 在这件事上很有用。
这个答案是错误的。
ClusterRole
和Role
定义了你可以操作哪些资源。如果你的角色需要管理多个命名空间中的资源,你需要使用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
正在尝试编写我的第一套 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 在这件事上很有用。
这个答案
ClusterRole
和Role
定义了你可以操作哪些资源。如果你的角色需要管理多个命名空间中的资源,你需要使用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