我正在绕圈尝试验证 AKS 群集中的 ServiceAccount 配置。我的目标是仅应用我需要的动词、资源和 API 组,但我现在又回到原来的示例,但它不起作用。
我有一个名为“vnd-dev”的命名空间,我将向其中添加一个服务帐户,如下所示:
kubectl create serviceaccount -n vnd-dev testaccess-user
然后,我使用与演示 kubernetes 指令类似的指令来允许视图访问:
kubectl create rolebinding testaccess-rolebinding --clusterrole=view --serviceaccount=vnd-dev:testaccess-user --namespace=vnd-dev
我正在使用 Postman 进行测试(尽管我最初使用的是注入到 pod 中的令牌)。为了获取与 Postman 一起使用的令牌,我执行“kubectl create token -n vnd-dev testaccess-user”。我正在使用本地 kubectl 上下文中的 HTTPS 地址。
当我尝试自己的命名空间时,我得到了正确的结果:
GET {{KUBEAPI}}/api/v1/namespaces/vnd-dev
但是当我尝试列出它的秘密时,我收到错误:
GET {{KUBEAPI}}/api/v1/namespaces/vnd-dev/secrets
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "secrets is forbidden: User \"system:serviceaccount:vnd-dev:testaccess-user\" cannot list resource \"secrets\" in API group \"\" in the namespace \"vnd-dev\"",
"reason": "Forbidden",
"details": {
"kind": "secrets"
},
"code": 403
}
我似乎无法解决这个问题 - 而且它似乎应该有效。事实上,如果我尝试:
kubectl auth can-i list namespaces/vnd-dev/secrets -n vnd-dev --as system:serviceaccount:vnd-dev:testaccess-user
我得到:
Warning: resource 'namespaces' is not namespace scoped
yes
安装到kubernetes中的两个对象如下:
kubectl get serviceaccount -n vnd-dev testaccess-user -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: "2024-01-03T11:48:38Z"
name: testaccess-user
namespace: vnd-dev
resourceVersion: "23639989"
uid: e1bc8d5a-c67d-4031-a9ee-091c116fd959
kubectl get rolebinding -n vnd-dev testaccess-rolebinding -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
creationTimestamp: "2024-01-03T12:32:21Z"
name: testaccess-rolebinding
namespace: vnd-dev
resourceVersion: "23651007"
uid: 9e7d0813-2418-4f15-bfe6-068e8ca22a57
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: view
subjects:
- kind: ServiceAccount
name: testaccess-user
namespace: vnd-dev
我很确定 ClusterRole“view”绝对应该允许我查询 /api/v1/namespaces 和 /api/v1/namespaces/vnd-dev/secrets 等等,“view”的内容似乎包含所有只读动词的所有资源。
我只能想象 AKS 需要一些额外的设置,或者需要以某种方式启用“查看”集群角色。
有人知道为什么这对我不起作用吗?
我的 Pod 列表正常工作,然后我注意到 ClusterRole “视图”似乎不包含“秘密”。也许我需要绑定到另一个角色来添加秘密。
我对“视图”集群角色的内容做了太多假设,而且也不知道如何应用它(即通过集群角色绑定)。我现在已经能够制定出一个应用我需要的场景的文件,即访问单个命名空间中的机密。看起来如下:
apiVersion: v1
kind: ServiceAccount
metadata:
name: testaccess-user
namespace: vnd-dev
---
#Allow access to cluster layer structures that are required
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: testaccess-clusterrole
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs: ["get", "list", "watch"]
---
#Allow access to items in our own namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: testaccess-role
namespace: vnd-dev
rules:
- apiGroups:
- ""
resources:
- secrets
verbs: ["get", "list", "watch"]
---
#Cluster Roles such as 'list namespaces' must be clusterrolebindings or there is not enough permission to complete the operation
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: testaccess-clusterrolebinding
namespace: vnd-dev
subjects:
- kind: User
name: system:serviceaccount:vnd-dev:testaccess-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: testaccess-clusterrole
apiGroup: rbac.authorization.k8s.io
---
#Role permissions within a single target namespace can be added via a non-cluster role-binding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: testaccess-rolebinding
namespace: vnd-dev
subjects:
- kind: User
name: system:serviceaccount:vnd-dev:testaccess-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: testaccess-role
apiGroup: rbac.authorization.k8s.io
实际上,Kubernetes 的问题在于,如果您有权访问单个命名空间,则路径 /api/v1/namespaces 根本不起作用,因此您甚至无法深入到您自己的命名空间,或者该命名空间内的对象,上面的脚本有效地允许使用 /namespaces/ 范围,然后下面的那些对象开始运行。