feat!: NetworkPolicy in the NodePort and game-server charts, on by default

garage, minecraft-router, minecraft-server, samba, teamspeak-server,
satisfactory. One major each. These are the charts the plan said to leave for
last, and they earned it - three of them changed the convention rather than
just consuming it.

GARAGE is the clearest illustration after keycloak. Its four ports split three
ways: s3 and web are RESTRICTED by source (no probe touches them), admin is the
probe path and stays open inside the cluster - which is uncomfortable, because
admin is also the admin API, and that is said out loud instead of glossed - and
rpc gets the narrowest rule the object can express, a podSelector with no
namespaceSelector. All four numbers come from garage.settings.

MINECRAFT-SERVER is the tightest policy in the repository, and the reason is
worth knowing: all three of its probes are EXEC probes, which put no packet on
the network, so no port has to stay open for the kubelet and no probeSources
value is needed at all. RCON and metrics are restricted outright. The game port
has two branches rendered from the same value the Service reads -
server.service.type NodePort means players arrive from the internet and the
rule must be open; anything else means the only path is in-cluster, so the rule
is restricted and the router's namespace has to be in allowedNamespaces.

MINECRAFT-ROUTER derives its egress from the routing table instead of guessing:
server.backendPort plus the "port" override of every mapping that sets one. Add
a backend on a non-standard port and the policy follows. What it cannot express
is the destination - mappings name hosts, and this object matches no hostname -
so the rule is wider than the routing table, and that is written down.

SATISFACTORY gets policyTypes: [Ingress] and no egress section, and the second
half of the reason is the deciding one. Steam's content delivery is not a
pinnable port set (SteamCMD over TCP 80/443/27015-27050, master servers over
UDP 27000-27100 and 4380, changed by Valve, re-downloaded on every update) -
and this is the ONE chart with no install-test at all, because the image is
multiple GB and the first start pulls over 10GB. An egress cap here would be
the only one in the sweep with no empirical check behind it, on the chart whose
correct port set is least knowable.

SAMBA and TEAMSPEAK-SERVER carry the NodePort lesson explicitly: the rules name
445/139 and the pod's voice and file-transfer ports, never the NodePorts, and
teamspeak's file is explicit that its pod port and NodePort happening to share a
number is a coincidence of its values rather than a pattern to copy. Teamspeak's
voice rule is UDP, and the file says why that matters: a TCP rule on the same
number is accepted, looks complete, and drops every voice packet.

THREE THINGS THE CHECKS CAUGHT WHILE THIS BATCH WAS WRITTEN, all of them real:

  - minecraft-server's RCON rule named a port the pod does not declare. The
    containerPort is gated on server.rcon.enabled and the rule was not, so
    assertion 2 rejected it. The rule now carries the same gate.
  - samba and satisfactory would have shipped allowedNamespaces and
    probeSources values that reach NO rule - every one of their inbound rules
    is open to any source. A value that silently does nothing is worse than one
    that is absent, because it reads as a control, so both are gone from those
    two charts and from their schemas, with the reason in values.yaml.
    teamspeak-server loses probeSources for the same reason and keeps
    allowedNamespaces, which its web-query rule uses.
  - the policy templates no longer declare template variables they do not use.
    samba keeps one, satisfactory none.

Part of #5

satisfactory/Chart.yaml

@@ -3,7 +3,7 @@ name: satisfactory
 description: A Helm chart to deploy a Satisfactory Gameserver on Kubernetes
 icon: https://raw.githubusercontent.com/wolveix/satisfactory-server/main/.github/logo.png
 type: application
-version: 7.0.2+upv1.9.10
+version: 8.0.0+upv1.9.10
 appVersion: "v1.9.10"
 maintainers:
   - name: jklein

satisfactory/templates/NOTES.txt

@@ -323,3 +323,60 @@ env IS APPENDED, NOT MERGED
   stored in the pod spec and readable by everyone who can read pods in
   {{ .Release.Namespace }}.
 {{- end }}
+{{- if .Values.networkPolicy.enabled }}
+
+NETWORKPOLICY IS ACTIVE — WHAT IT CAPS, AND WHAT IT DOES NOT
+  {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy selects this workload's pods.
+  Inbound: the three declared game ports only — TCP and UDP {{ include "satisfactory.formatNumber" .Values.server.gamePort }} and TCP
+  {{ include "satisfactory.formatNumber" .Values.server.messagingPort }} — open to any source, because they are NodePorts and the clients
+  are players on the internet. Anything else the image binds is NOT reachable.
+
+  THERE IS NO EGRESS RESTRICTION AT ALL, deliberately. What this server needs
+  outbound is Steam's content delivery, which is not a pinnable port list
+  (SteamCMD over TCP 80, 443 and 27015-27050; master servers over UDP
+  27000-27100 and 4380; Valve changes it; the server re-downloads on every
+  update). And this is the one chart in the repository with NO install-test —
+  the image is multiple GB and the first start pulls over 10GB of game files —
+  so an egress cap here would be the only one in the sweep with no empirical
+  check behind it. If you want one, write it at release level where Steam's
+  behaviour can be observed.
+
+  Three limits belong in the same breath, because none of them is visible in
+  the object itself:
+
+  - EGRESS IS BY PORT, NEVER BY DESTINATION. A NetworkPolicy matches CIDRs and
+    selectors and cannot express a hostname, so every egress rule permits its
+    port to ANY address. That is a limit of the object, not a shortcut — this
+    cluster's CNI (Canal: Flannel plus Calico) has no FQDN rule either. An
+    outbound port the chart does not know about is BLOCKED: add it to
+    networkPolicy.egress.extraPorts, and expect to find out through an
+    application-level connection error rather than through this object.
+{{- if .Values.networkPolicy.probeSources }}
+  - THE PROBE PATH IS RESTRICTED in this release, because
+    networkPolicy.probeSources is set to
+      {{ join ", " .Values.networkPolicy.probeSources }}
+    Probes come from the IP of the WORKER NODE running the pod. If none of those
+    CIDRs covers the node this pod lands on, the kubelet's probes are dropped
+    and THE POD NEVER BECOMES READY — the rollout then times out and the symptom
+    looks like a broken application. Compare
+
+      kubectl -n {{ .Release.Namespace }} describe pod -l app={{ .Release.Name }}-{{ .Chart.Name }}-sfs
+
+    against `kubectl get node -o wide`.
+{{- else }}
+  - THE PROBED PORT IS OPEN INSIDE THE CLUSTER. networkPolicy.probeSources is
+    empty, so that rule carries no source selector at all and any pod the CNI
+    routes to can reach it. Not from the internet — but this is NOT pod-level
+    isolation. Narrowing it means listing the worker node IPs in
+    networkPolicy.probeSources, because the kubelet probes from the node's own
+    address and the chart cannot know it; a wrong guess there leaves the pod
+    permanently un-Ready.
+{{- end }}
+  - IT IS ONLY A BOUNDARY WHERE THE CNI ENFORCES POLICIES. Where it does not,
+    this object is accepted and filters nothing, so everything reads as
+    configured while nothing is filtered. `kubectl -n {{ .Release.Namespace }} get networkpolicy`
+    shows the object exists; only a connection attempt from an unrelated
+    namespace shows that it bites.
+
+  Switch it off with networkPolicy.enabled: false.
+{{- end }}

satisfactory/templates/satisfactory.networkpolicy.yaml

@@ -0,0 +1,101 @@
+{{- /*
+NetworkPolicy for satisfactory (Gitea #5).
+
+INGRESS ONLY, AND THE MISSING EGRESS SECTION IS THE DECISION IN THIS FILE.
+
+Two reasons, and they compound.
+
+First, what this server needs outbound is Steam's content delivery, and that is
+not a port list anyone can pin down: the dedicated server downloads and UPDATES
+the game through SteamCMD over TCP 80 and 443 plus the 27015-27050 range, and
+talks to the Steam master servers over UDP 27000-27100 and 4380. Valve changes
+that set, the server re-downloads on every update, and a cap that is wrong
+leaves a server that cannot start - or worse, one that starts and never appears
+in the server browser.
+
+Second, AND THIS IS WHY THE DECISION GOES THIS WAY RATHER THAN THE OTHER:
+satisfactory is the ONE chart in this repository with no install-test at all.
+It is in ci/excluded-charts.txt, because the image is multiple GB and the first
+start pulls over 10GB of game files - impractical on a runner. So an egress cap
+here would be the only policy in the sweep with no empirical check whatsoever
+behind it, on the chart whose correct port set is least knowable. Review is the
+only net this chart has, and a review cannot verify a Steam port range.
+
+So valkey's rule applies: policyTypes names only what there is something to
+restrict. A deployment that wants an egress cap should write one at release
+level, where the Steam behaviour can actually be observed.
+
+What the Ingress half still buys is real: only the three declared game ports
+are reachable, so anything else the image binds is not.
+
+WHAT THIS OBJECT IS: a ceiling on reachability, not an authentication layer.
+Only the ports declared below are reachable at all - whatever else the process
+binds, now or after the next app update, is blocked without anyone having to
+notice it exists.
+
+WHAT IT IS NOT:
+  - EGRESS IS COARSE. A NetworkPolicy matches CIDRs and selectors and NEVER
+    hostnames, so "only to the database host" cannot be expressed at all. This
+    cluster's CNI is Canal (Flannel plus Calico for policy) and has no FQDN
+    rule; Calico's GlobalNetworkSet could express one but would bind this chart
+    to Calico, the same argument that kept implementation-specific objects out
+    of the Gateway-API sweep (#114). Each egress rule therefore permits its
+    PORT to any destination.
+  - NOT A BOUNDARY WHERE THE CNI DOES NOT ENFORCE ONE. An unenforced policy is
+    accepted by the API server and filters nothing, so everything reads as
+    configured while nothing is filtered.
+  - THE REASONING IS IN TEMPLATE COMMENTS, not in "#" comments: those are part
+    of the rendered object, travel into the cluster and appear in every release
+    diff. ci/run-networkpolicy-test.sh fails on a rendered "#".
+
+THE PORT NUMBERS BELOW ARE POD PORTS, NEVER NODEPORTS. A NetworkPolicy is
+evaluated at the pod's network interface, after kube-proxy has already
+translated a NodePort to the targetPort, so a NodePort number here would match
+nothing while looking strict - and, being the only rule for that port, would
+block every inbound connection instead. ci/run-networkpolicy-test.sh asserts
+every port here against the containerPorts of the pod spec this policy
+selects.
+*/ -}}
+{{- if .Values.networkPolicy.enabled }}
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
+  labels:
+    app: {{ .Release.Name }}-{{ .Chart.Name }}-networkpolicy
+spec:
+  {{- /*
+  Selects the StatefulSet's pods. ci/run-networkpolicy-test.sh fails if
+  this matches no pod spec of the same render - which is the mistake that
+  would otherwise leave a policy in the namespace filtering nothing, and
+  its usual cause is a label renamed in the workload template.
+  */}}
+  podSelector:
+    matchLabels:
+      app: {{ .Release.Name }}-{{ .Chart.Name }}-sfs
+  policyTypes:
+    - Ingress
+  ingress:
+    {{- /*
+    THE GAME PORTS, all three published as NodePorts and all deliberately open: the
+    clients are players on the internet and, after NodePort masquerading, the source
+    address is a cluster node anyway.
+
+    The game port appears TWICE, once for each protocol, because the server binds
+    it as both - and a policy that named only TCP would be accepted, would look
+    complete, and would drop the UDP half of the game traffic. The TCP side is
+    additionally what the readiness probe opens a socket against.
+
+    The numbers go through satisfactory.formatNumber for the same reason they do in
+    the Service and the StatefulSet: a port read from values as a float64 renders
+    in exponential notation above a certain size, and a NetworkPolicy with "3.0777e
+    +04" in it is not valid.
+    */}}
+    - ports:
+        - protocol: TCP
+          port: {{ include "satisfactory.formatNumber" .Values.server.gamePort }}
+        - protocol: UDP
+          port: {{ include "satisfactory.formatNumber" .Values.server.gamePort }}
+        - protocol: TCP
+          port: {{ include "satisfactory.formatNumber" .Values.server.messagingPort }}
+{{- end }}

satisfactory/values.schema.json

@@ -9,6 +9,16 @@
       "description": "Helm's conventional cross-chart values. Unused by this chart, kept open so an umbrella install cannot break on it.",
       "type": "object"
     },
+    "networkPolicy": {
+      "description": "The chart's NetworkPolicy (Gitea #5), on by default. A ceiling on reachability and not an authentication layer: only the declared container ports are reachable at all, egress is capped by PORT (a NetworkPolicy matches CIDRs and selectors, never hostnames, so a destination host cannot be expressed), and ingress is capped by source for every port no network probe touches. Only a boundary where the cluster's CNI enforces policies - an unenforced policy is accepted by the API server and filters nothing. The template's header carries the full list of what it does not do.",
+      "type": "object",
+      "additionalProperties": false,
+      "properties": {
+        "enabled": {
+          "type": "boolean"
+        }
+      }
+    },
     "scaleDown": {
       "type": "boolean"
     },

satisfactory/values.yaml

@@ -148,3 +148,40 @@ securityContext:
       drop:
         - ALL
       add: []
+
+# ---------------------------------------------------------------------------
+# NetworkPolicy (Gitea #5). On by default. The reference implementation with
+# the full reasoning is template-chart; the convention is in README, "Chart
+# style guidelines", and the operator's view on this chart's wiki page.
+# ---------------------------------------------------------------------------
+networkPolicy:
+  # enabled IS THE ONLY VALUE HERE, and that is deliberate. The single inbound
+  # rule is open to any source and there is no egress section at all (see
+  # below), so allowedNamespaces and probeSources would both reach no rule -
+  # and a value that silently does nothing is worse than one that is absent,
+  # because it reads as a control.
+  #
+  # WHAT THIS POLICY ALLOWS: inbound the three declared game ports only, open
+  # to any source - they are NodePorts and the clients are players on the
+  # internet. THERE IS NO EGRESS SECTION, and that is the decision in this
+  # chart rather than an omission.
+  #
+  # TWO REASONS, AND THEY COMPOUND. First, the outbound requirement is Steam's
+  # content delivery, which is not a pinnable port list: SteamCMD uses TCP 80,
+  # 443 and 27015-27050, the master servers UDP 27000-27100 and 4380, Valve
+  # changes the set, and the server re-downloads on every update. Second, and
+  # decisively: satisfactory is the ONE chart here with no install-test at all
+  # (ci/excluded-charts.txt - the image is multiple GB and the first start
+  # pulls over 10GB). An egress cap here would be the only one in the sweep
+  # with no empirical check behind it, on the chart whose correct port set is
+  # least knowable, and a review cannot verify a Steam port range.
+  #
+  # So policyTypes names Ingress only, for the same reason valkey does: a rule
+  # that has to be widened until it permits everything makes the object look
+  # stricter than it is. A deployment that wants an egress cap should write one
+  # at release level, where Steam's behaviour can be observed.
+  #
+  # The game port is allowed as BOTH TCP and UDP, because the server binds it
+  # as both - a TCP-only rule would be accepted and would drop half the game
+  # traffic.
+  enabled: true