From 999646fb40694730925b0eb5a24cd576a5e32179 Mon Sep 17 00:00:00 2001 From: Konstantin Renner Date: Fri, 10 Jul 2026 15:36:13 +0200 Subject: [PATCH] matter-server: bind the :5580 control WebSocket to the pod address MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Same class as the shelly-manager bypass (#142). matter-server is multi-homed — net1 is a macvlan on the IoT VLAN for Matter commissioning — and it binds the :5580 control WebSocket to 0.0.0.0. macvlan traffic bypasses Cilium policy, so the unauthenticated Matter control API was reachable from the whole IoT VLAN. Verified 2026-07-10 from edge-1 (on v30iot): GET http://10.2.30.117:5580/ -> 200 An unauthenticated IoT client could drive the Matter fabric (commission / remove / control devices, read fabric state) over that socket. python-matter-server has a dedicated `--listen-address` flag, independent of `--primary-interface`. Bind the WebSocket to the pod eth0 address (--listen-address=$(POD_IP), POD_IP=status.podIP) so :5580 is served only on the cluster pod CIDR. `--primary-interface=net1` is unchanged, so Matter commissioning/discovery still uses the IoT VLAN. HA reaches the WebSocket via the IPv4 ClusterIP Service (ws://matter-server...svc:5580/ws), which targets the pod IP. The Service is single-stack IPv4, so binding the IPv4 pod IP loses no consumer. matter-server has no probes, so there is no probe path to reconcile (that probe gap is a separate, deferred audit finding). Verified: kubectl kustomize builds; rendered args carry --listen-address=$(POD_IP) and the POD_IP downward-API env. Post-merge checks to run: GET net1:5580 from the IoT VLAN now fails; :5580 listens on the pod IP only; HA's Matter integration reconnects and all 13 nodes re-subscribe; commissioning still works (net1 unchanged). Co-Authored-By: Claude Opus 4.8 (1M context) --- kubernetes/apps/matter-server/deployment.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/kubernetes/apps/matter-server/deployment.yaml b/kubernetes/apps/matter-server/deployment.yaml index 3b49b408..794559e7 100644 --- a/kubernetes/apps/matter-server/deployment.yaml +++ b/kubernetes/apps/matter-server/deployment.yaml @@ -50,6 +50,19 @@ spec: args: - --storage-path=/data - --port=5580 + # Bind the :5580 control WebSocket to the pod's eth0 address, + # not 0.0.0.0. This pod is multi-homed — net1 is a macvlan on + # the IoT VLAN (below) — and macvlan traffic bypasses Cilium + # policy, so a 0.0.0.0 bind exposes the unauthenticated Matter + # control API to the whole IoT VLAN (verified 2026-07-10: GET + # http://:5580/ from the VLAN returned 200). An IoT + # client could then drive the Matter fabric. `--listen-address` + # is independent of `--primary-interface`: the WebSocket is the + # HA control channel (reached via the ClusterIP Service, IPv4), + # while Matter commissioning/discovery stays on net1. POD_IP is + # the eth0 IPv4 (status.podIP). This is the matter-server twin + # of the shelly-manager fix (PR #142). + - --listen-address=$(POD_IP) # Pin Matter SDK link-local discovery to the macvlan attachment # on the IoT VLAN. Without this, the SDK picks the kernel's # default route interface (eth0, Cilium pod CIDR) for Matter @@ -63,6 +76,11 @@ spec: - --vendorid=4939 - --fabricid=2 - --log-level=debug + env: + - name: POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP ports: - name: ws containerPort: 5580 -- 2.54.0