我定义了以下 ClusterRole:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: deployer-system
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- list
- nonResourceURLs:
- '*'
verbs:
- list
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: deployer-nonsystem
rules:
- apiGroups:
- '*'
resources:
- secrets
- PersistentVolumes
- Role
- RoleBinding
verbs:
- list
- apiGroups:
- '*'
resources:
- deployments
- pods
verbs:
- get
- list
- watch
- create
- update
- patch
- nonResourceURLs:
- '*'
verbs:
- list
我使用以下 RoleBindings 为用户分配上述 ClusterRole:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: theuser-nonsystem-role-binding
namespace: nonsystem-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: deployer-nonsystem
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: theuser
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: theuser-kube-system-role-binding
namespace: system-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: deployer-system
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: theuser
但是,他们可以运行kubectl -n [NAMESPACE] get secrets -o yaml
并查看所有机密。根据上面的 ClusterRole 规范,我预计此调用将被禁止。
我是不是遗漏了什么或者误解了什么?为什么用户可以“获取”机密?
更新:请注意:我的问题不是他们可以列出秘密。我的问题是用户可以“获取”秘密(不同的动词!)
因为
list
动词的意思是“get
应用于多个资源”。当您执行kubectl get secret
操作而不指定单个机密时,您正在执行list
操作。鉴于您问题中的 RBAC,我可以询问命名空间中的所有秘密
system-namespace
:但我不能要求一个具体的秘密:
您应该将 视为
list
的更强大版本get
,因为它允许某人枚举和检索所有机密。仅凭get
权限,实体必须知道特定机密的名称才能访问它,并且您实际上可以get
通过设置resourceNames
规则的组件来限制对特定资源的访问。假设
system-namespace
有秘密secret1
和secret2
,如果我有一个绑定到以下角色的帐户:然后我只能检索秘密
secret1
: