The apiserver's plain-HTTP debug port is reachable from any pod in the cluster, and it serves the full REST API with no authentication. The listener gets the same handler as the mTLS one (pkg/rest/server.go:222). It binds all pod interfaces by default (--rest-bind-address=:3370, cmd/apiserver/main.go:89). The deploy manifest comments say it "stays reachable only via kubectl port-forward" (stand/blockstor-apiserver-deploy.yaml:94-96), but nothing enforces that. The port is only absent from the Service, and the repo's single NetworkPolicy (config/network-policy/allow-metrics-traffic.yaml) selects the controller-manager, not the apiserver pods.
Any pod that can reach the apiserver pod IP gets full read-write access to the LINSTOR-compatible API without a client certificate.
I checked this by reading code and manifests, not by sending traffic from another pod. Only the stand/ manifests in this repo deploy the apiserver, so downstream packaging may differ; if a real deployment puts its own NetworkPolicy around the apiserver, the exposure shrinks accordingly. The controller binary has the same flag, but its REST API is off by default there. Found while reviewing #190; not caused by it.
Any of these closes it:
- bind the plain listener to 127.0.0.1 (port-forward keeps working);
- add a NetworkPolicy selecting the apiserver pods;
- start the plain listener only behind an explicit debug flag.
The apiserver's plain-HTTP debug port is reachable from any pod in the cluster, and it serves the full REST API with no authentication. The listener gets the same handler as the mTLS one (
pkg/rest/server.go:222). It binds all pod interfaces by default (--rest-bind-address=:3370,cmd/apiserver/main.go:89). The deploy manifest comments say it "stays reachable only viakubectl port-forward" (stand/blockstor-apiserver-deploy.yaml:94-96), but nothing enforces that. The port is only absent from the Service, and the repo's single NetworkPolicy (config/network-policy/allow-metrics-traffic.yaml) selects the controller-manager, not the apiserver pods.Any pod that can reach the apiserver pod IP gets full read-write access to the LINSTOR-compatible API without a client certificate.
I checked this by reading code and manifests, not by sending traffic from another pod. Only the
stand/manifests in this repo deploy the apiserver, so downstream packaging may differ; if a real deployment puts its own NetworkPolicy around the apiserver, the exposure shrinks accordingly. The controller binary has the same flag, but its REST API is off by default there. Found while reviewing #190; not caused by it.Any of these closes it: