0

私はセキュリティ研究のために POC を行っており、ワーカー ノードから名前空間のシークレットに直接アクセスしようとしています。Kubernetes 1.20 を実行している GKE 上のクラスタがあります

ワーカー (非マスター) ノードから次のコマンドを実行しています。

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

ドキュメントを見ると、ノードで実行されている kubelet がシークレットにアクセスできるはずであることがわかります: https://kubernetes.io/docs/reference/access-authn-authz/node/

私の理解では、承認はClusterRole system: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-to-control-plane

4

3 に答える 3