我正在试用服务帐户。我认为以下应该会产生访问错误(但事实并非如此(：
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
我看到的是一个成功的服务列表，但我预计会出现权限错误，因为我从未为test-sa创建过任何RoleBinding或ClusterRoleBinding。
我很难找到列出特定SA可用权限的方法，但根据Kubernetes检查服务帐户权限，这应该可以通过以下方式实现：
kubectl auth can-i list services --as=system:serviceaccount:default:test-sa
> yes
尽管我怀疑这个命令是否真的有效，因为我可以用任何胡言乱语替换test-sa，它仍然说"；是的"；。
根据文件，服务帐户默认具有"；给予所有已认证用户的发现权限"；。它没有说明这实际上意味着什么，但通过更多的阅读，我发现了这个资源，这可能就是它所指的：
kubectl get clusterroles system:discovery -o yaml
> [...]
> rules:
> - nonResourceURLs:
> - /api
> - /api/*
> [...]
> verbs:
> - get
这意味着所有服务帐户在所有API端点上都具有get权限；nonResourceURL"；bit意味着这不适用于服务等资源的API，即使这些API位于该路径下…(？？(
如果我完全删除Authorization标头，我会看到预期的访问错误。但我不明白为什么它可以使用这个空的服务帐户获取数据。我的误解是什么？如何正确限制权限？
事实证明，这是Mac Kubernetes支持的Docker Desktop中的一个错误。
它会自动添加一个ClusterRoleBinding，将cluster-admin提供给所有服务帐户(！(。只有打算将其提供给kube-system命名空间内的服务帐户。
它最初是在docker/中为mac#3694提出的，但修复错误。我为mac#4774提出了一个新的问题docker/(原来的问题由于年龄而被锁定(。
在等待bug得到解决时，一个快速修复方法是运行：
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 *.* [] [] [*] [*] [] [*] [...]
Docker Desktop for Windows中也存在相同的错误。
它自动添加一个ClusterRoleBinding，为所有服务帐户提供集群管理(！(。它只打算将其提供给kube系统名称空间内的服务帐户。
这是因为在Docker Desktop中，集群角色绑定docker-for-desktop-binding默认为所有创建的服务帐户赋予cluster-admin角色。
有关更多详细信息，请查看此处的问题