我正在做一些安全研究的POC，试图直接从工作节点访问命名空间机密。我在GKE上有一个运行Kubernetes 1.20 的集群
我正在从工作(无主(节点运行以下命令：
curl -v $APISERVER/api/v1/namespaces/default/pods/
--cacert /etc/srv/kubernetes/pki/ca-certificates.crt
--cert /var/lib/kubelet/pki/kubelet-client.crt
--key /var/lib/kubelet/pki/kubelet-client.key
而且效果很好。
然而，试图获得秘密失败了：
curl -v $APISERVER/api/v1/namespaces/default/secrets/
--cacert /etc/srv/kubernetes/pki/ca-certificates.crt
--cert /var/lib/kubelet/pki/kubelet-client.crt
--key /var/lib/kubelet/pki/kubelet-client.key
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "secrets is forbidden: User "system:node:gke-XXX--YYY" cannot list resource "secrets" in API group "" in the namespace "pencil": No Object name found",
"reason": "Forbidden",
"details": {
"kind": "secrets"
},
"code": 403
查看文档，我发现运行在node上的kubelet应该能够访问机密：https://kubernetes.io/docs/reference/access-authn-authz/node/
根据我的理解，授权是由ClusterRolesystem:node支持的。看着它，我确实看到了它对get秘密的作用：
% kubectl get clusterrole system:node -o json
{
"apiVersion": "rbac.authorization.k8s.io/v1",
"kind": "ClusterRole",
...
{
"apiGroups": [
""
],
"resources": [
"configmaps",
"secrets"
],
"verbs": [
"get",
"list",
"watch"
]
},
...
]
}
以及一些关于kubelet和kube apiserver之间通信的更相关的文档：https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/#node-控制飞机
- 我认为您提供的证书位置不正确。我用以下证书在我的普通kubernetes集群上尝试过同样的方法，效果很好
curl --cacert /etc/kubernetes/pki/ca.crt --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt --key /etc/kubernetes/pki/apiserver-kubelet-client.key $APISERVER/api/v1/namespaces/default/secrets
在挖掘源代码后，我发现了No Object name found错误的含义——必须命名机密或配置映射才能检索。正如文档所建议的，如果某个pod将它们映射到有问题的节点，则可以检索它们。
因此，假设我的节点中的某个pod使用了一些秘密server-password，则以下命令按预期工作：
curl -v $APISERVER/api/v1/namespaces/default/secrets/server-password
--cacert /etc/srv/kubernetes/pki/ca-certificates.crt
--cert /var/lib/kubelet/pki/kubelet-client.crt
--key /var/lib/kubelet/pki/kubelet-client.key
显然，kubectl也可以简单地使用，它首先在/var/lib/kubelet/pki创建证书。
kubectl --kubeconfig /var/lib/kubelet/kubeconfig -n default get secret server-password -o json
这是意料之中的事。
因为访问机密(通常(是通过服务帐户允许的。您需要找到安装在节点上运行的pod上的服务帐户令牌。为此，您可以尝试挖掘"；神奇的"/节点上的proc文件夹。如果您可以访问pod上安装的服务帐户令牌，并且该服务帐户具有访问机密的权限，那么只能从节点访问机密。