禁止 Kubernetes RBAC 不适用于我的 Azure AKS 集群机密

问题描述 投票:0回答:1

我正在绕圈尝试验证 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 “视图”似乎不包含“秘密”。也许我需要绑定到另一个角色来添加秘密。

kubernetes kubectl rbac
1个回答
0
投票

我对“视图”集群角色的内容做了太多假设,而且也不知道如何应用它(即通过集群角色绑定)。我现在已经能够制定出一个应用我需要的场景的文件,即访问单个命名空间中的机密。看起来如下:

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/ 范围,然后下面的那些对象开始运行。

© www.soinside.com 2019 - 2024. All rights reserved.