Question

我正在尝试服务帐户。我相信以下内容会产生访问错误（但不会）：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa

---

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  serviceAccountName: test-sa
  containers:
  - image: alpine
    name: test-container
    command: [sh]
    args:
    - -ec
    - |
      apk add curl;
      KUBE_NAMESPACE="$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)";
      curl \
        --cacert "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt" \
        -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
        "https://kubernetes.default.svc/api/v1/namespaces/$KUBE_NAMESPACE/services";
      while true; do sleep 1; done;

kubectl apply -f test.yml
kubectl logs test-pod

我看到的是成功列出了服务，但是我会遇到权限错误，因为我从未为RoleBinding创建任何ClusterRoleBinding或test-sa s。

我正在努力寻找列出特定SA可用权限的方法，但是根据Kubernetes check serviceaccount permissions，应该可以通过以下方式实现：

kubectl auth can-i list services --as=system:serviceaccount:default:test-sa
> yes

尽管我对该命令是否确实有效表示怀疑，因为我可以用任何乱码替换test-sa，并且仍然显示“是”。

根据文档，服务帐户默认具有"discovery permissions given to all authenticated users"。它并没有说这实际上意味着什么，但是通过更多的阅读，我发现该资源可能就是它所指的：

kubectl get clusterroles system:discovery -o yaml
> [...]
> rules:
> - nonResourceURLs:
>   - /api
>   - /api/*
> [...]
>   verbs:
>   - get

这将暗示所有服务帐户在所有API端点上均具有get权限，尽管“ nonResourceURLs”位表示这不适用于服务等资源的API，即使这些API都位于该路径下… （???）

如果我完全删除Authorization标头，则会看到访问错误，这是预期的。但是我不明白为什么它能够使用此空服务帐户获取数据。我的误解是什么，如何正确限制权限？

Answer 1

事实证明，这是Docker Desktop for Mac的Kubernetes支持中的一个错误。

它会自动向{strong>所有服务帐户（！）添加一个ClusterRoleBinding，并赋予cluster-admin。仅打算将它们提供给kube-system名称空间内的服务帐户。

它最初是在docker/for-mac#3694中提出的，但修复不正确。我提出了一个新问题docker/for-mac#4774（由于年龄原因，原来的问题已被锁定）。

等待解决该错误的一种快速解决方案是运行：

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: docker-for-desktop-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:kube-system
EOF

我不知道这是否会在将来的Docker Desktop升级中引起问题，但目前为止它能完成工作。

在修复了该错误之后，上面的代码正确地显示了403错误，并且需要执行以下操作才能明确授予对服务资源的访问权限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: service-reader
rules:
- apiGroups: [""]
  resources: [services]
  verbs: [get, list]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-sa-service-reader-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: service-reader
subjects:
- kind: ServiceAccount
  name: test-sa

kubectl auth can-i --list --as system:serviceaccount是一个有用的调查命令，它表明恶意许可权已应用于所有服务帐户：

Resources                       Non-Resource URLs   Resource Names   Verbs
*.*                             []                  []               [*]
                                [*]                 []               [*]
[...]

Answer 2

Docker-Desktop for Windows 中存在同样的错误。

<块引用>

它会自动添加一个 ClusterRoleBinding，为所有服务帐户 (!) 提供 cluster-admin。它只是打算将其提供给 kube-system 命名空间内的服务帐户。

Answer 3

这是因为默认情况下，在Docker桌面中，群集绑定docker-for-desktop-binding为所有创建的服务帐户赋予cluster-admin角色。

有关更多详细信息，请查看问题here

Kubernetes服务帐户的默认权限

3 个答案: