jlab-cluster/helm-charts
3
0 Fork 0
Code Issues 15 Pull Requests 3 Actions Packages Wiki Activity

Security: NetworkPolicies für alle Charts #5

New Issue
Closed
opened 2026-09-16 16:03:17 +02:00 by jlab-bot · 2 comments
jlab-bot commented 2026-09-16 16:03:17 +02:00
Member
Copy link
Copy source

Migriert aus jk-cluster/helm-charts#20 — urspruenglich angelegt von MeepMr am 2026-08-21.

Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.

Kontext

Ausgelagert aus #8 (Security-Hardening der Container), Auslagerung vom Maintainer genehmigt. Kein einziges Chart bringt aktuell eine NetworkPolicy mit — alle Pods dürfen clusterweit frei kommunizieren, sofern der Cluster kein Default-Deny hat.

Ziel

Jedes Chart bekommt eine sinnvolle Default-NetworkPolicy, konfigurierbar über values.yaml:

  • Ingress: nur vom Ingress-Controller-Namespace (bei Web-Apps) bzw. den tatsächlich benötigten Quellen; bei NodePort-Diensten (samba, teamspeak-server, satisfactory) entsprechend offen für die Service-Ports.
  • Egress: DNS immer; darüber hinaus nur die tatsächlich benötigten Ziele (z. B. Datenbank/Redis bei paperless, outline, zipline; SMTP bei rallly; OIDC-Provider bei patchmon, rallly, urlaubsverwaltung, voucher-vault).
  • Referenz-Implementierung im template-chart, dann Rollout pro Chart.

Zu klären vor der Umsetzung

  • Namespace/Labels des Ingress-Controllers im Ziel-Cluster (für die Ingress-Selektoren).
  • Ob externe Abhängigkeiten (DBs, OIDC) im Cluster oder außerhalb liegen — beeinflusst Egress-Regeln (namespaceSelector vs. ipBlock/FQDN).
  • Ob der Cluster CNI-seitig NetworkPolicies überhaupt durchsetzt (k3s: ja, mit kube-router/Cilium je nach Setup).
> Migriert aus [`jk-cluster/helm-charts#20`](https://github.com/jk-cluster/helm-charts/issues/20) — urspruenglich angelegt von **MeepMr** am 2026-08-21. > > Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar. --- ## Kontext Ausgelagert aus #8 (Security-Hardening der Container), Auslagerung vom Maintainer genehmigt. Kein einziges Chart bringt aktuell eine NetworkPolicy mit — alle Pods dürfen clusterweit frei kommunizieren, sofern der Cluster kein Default-Deny hat. ## Ziel Jedes Chart bekommt eine sinnvolle Default-NetworkPolicy, konfigurierbar über `values.yaml`: - **Ingress**: nur vom Ingress-Controller-Namespace (bei Web-Apps) bzw. den tatsächlich benötigten Quellen; bei NodePort-Diensten (samba, teamspeak-server, satisfactory) entsprechend offen für die Service-Ports. - **Egress**: DNS immer; darüber hinaus nur die tatsächlich benötigten Ziele (z. B. Datenbank/Redis bei paperless, outline, zipline; SMTP bei rallly; OIDC-Provider bei patchmon, rallly, urlaubsverwaltung, voucher-vault). - Referenz-Implementierung im `template-chart`, dann Rollout pro Chart. ## Zu klären vor der Umsetzung - Namespace/Labels des Ingress-Controllers im Ziel-Cluster (für die Ingress-Selektoren). - Ob externe Abhängigkeiten (DBs, OIDC) im Cluster oder außerhalb liegen — beeinflusst Egress-Regeln (namespaceSelector vs. ipBlock/FQDN). - Ob der Cluster CNI-seitig NetworkPolicies überhaupt durchsetzt (k3s: ja, mit kube-router/Cilium je nach Setup).
jlab-bot commented 2026-10-04 21:26:35 +02:00
Author
Member
Copy link
Copy source

Nachgeprüft am 2026-10-04: unverändert offen, mit Zahl

2 von 28 Chart-Verzeichnissen rendern eine NetworkPolicy:

  • valkey/templates/valkey.networkpolicy.yaml
  • stalwart/templates/stalwart.networkpolicy.yaml

Alle übrigen 26 haben keine. Bemerkenswert dabei: garage (#81) und keycloak (#83) sind nach diesem Issue entstanden und haben trotzdem keine — bei keycloak ist das besonders sichtbar, weil dort der Management-Port 9000 die Health- und Metrics-Oberfläche unauthentifiziert trägt und allein durch „kein Ingress" geschützt ist, nicht durch eine Policy.

Die Durchsetzung ist bestätigt: die CNI des Clusters setzt NetworkPolicies durch (für stalwart so erhoben und dort als Vorgabe networkPolicy.enabled: true gesetzt). Es fehlt also nicht die Voraussetzung, sondern die Umsetzung in den übrigen Charts.

## Nachgeprüft am 2026-10-04: unverändert offen, mit Zahl **2 von 28** Chart-Verzeichnissen rendern eine NetworkPolicy: - `valkey/templates/valkey.networkpolicy.yaml` - `stalwart/templates/stalwart.networkpolicy.yaml` Alle übrigen 26 haben keine. Bemerkenswert dabei: `garage` (#81) und `keycloak` (#83) sind nach diesem Issue entstanden und haben trotzdem keine — bei `keycloak` ist das besonders sichtbar, weil dort der Management-Port 9000 die Health- und Metrics-Oberfläche **unauthentifiziert** trägt und allein durch „kein Ingress" geschützt ist, nicht durch eine Policy. Die Durchsetzung ist bestätigt: die CNI des Clusters setzt NetworkPolicies durch (für `stalwart` so erhoben und dort als Vorgabe `networkPolicy.enabled: true` gesetzt). Es fehlt also nicht die Voraussetzung, sondern die Umsetzung in den übrigen Charts.
jlab-bot commented 2026-10-14 15:36:44 +02:00
Author
Member
Copy link
Copy source

Genehmigter Plan — und der Rumpf beschreibt einen Cluster, der seit heute nicht mehr existiert

Alles unten gemessen am 14.10.2026 am laufenden Cluster und an origin/main.

Die drei Fragen aus „Zu klären vor der Umsetzung" sind beantwortet

1. Namespace und Labels des Ingress-Controllers — aber nicht mit der Antwort, die der Rumpf annimmt.
ingress-nginx weg — kein DaemonSet, null Pods
IngressClass nur noch traefik (traefik.io/ingress-controller), als Vorgabe; keine nginx-Klasse
Ingress-Objekte im ganzen Cluster null
Traefik kube-system, DaemonSet rke2-traefik, 6/6, Ports web=8000, websecure=8443

Die Quelle für die Ingress-Richtung ist damit:

- namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: kube-system
  podSelector:
    matchLabels:
      app.kubernetes.io/name: rke2-traefik

Beides in einem from-Eintrag ist ein UND. Eine gegen ingress-nginx geschriebene Policy würde still allen Web-Verkehr blockieren. Stichproben, dass der Weg wirklich über Traefik läuft: id.klein.pub → 302 → /realms/klein-family/account/, MTA-STS-Policy → 200.

2. Liegen die Abhängigkeiten im Cluster? Für die Hauptfälle ja: postgres-18, maria-db und keycloak (OIDC) laufen im Cluster, stalwart liefert SMTP. namespaceSelector genügt also; ipBlock braucht nur, was wirklich außerhalb liegt.

3. Setzt die CNI durch? Ja — und sie ist Canal: Flannel fürs Netz, Calico für die Policies, 6/6. Daraus folgt eine harte Grenze: kein FQDN-Egress. Nur podSelector, namespaceSelector, ipBlock. Calicos GlobalNetworkSet-CRD liegt vor, aber es zu benutzen würde die Charts an Calico binden — dasselbe Argument, das implementierungsspezifische Policy-Objekte aus dem Gateway-Sweep (#114) herausgehalten hat.

Kein clusterweites Default-Deny — das schadet nicht: ein von einer Policy selektierter Pod wird für die genannten Richtungen von selbst dicht. Ein Rollout Chart für Chart wirkt also auch ohne.

Entscheidungen des Maintainers

Vorgabe networkPolicy.enabled: true, wie bei stalwart. Also Major je Chart. Die Alternative (aus, pro Release eingeschaltet) wurde mit der Begründung abgelehnt, dass #5 sonst erst erreicht ist, wenn jemand es in jk-cluster-config einschaltet.

Alle Charts in einer Runde, nicht nach Gestalt gruppiert.

Der Preis ist benannt und bewusst: eine falsche Quelle macht einen Dienst stumm oder einen Pod nie Ready, und das erreicht die laufenden Releases beim nächsten Upgrade.

Was das Risiko trägt: der Install-Test setzt Policies durch

Und das ist der Grund, warum „alles auf einmal mit Vorgabe an" vertretbar ist.

k3d cluster create in .github/workflows/install-test.yml:304 und :314 läuft ohne --disable-network-policy und ohne --k3s-arg, der daran rührt — k3s bringt seinen Policy-Controller also mit. Eine Policy, die den Probe-Pfad blockiert, macht den Pod nie Ready und den Install-Test rot, in CI statt in Produktion.

Und die Abdeckung ist fast vollständig: von 30 Chart-Verzeichnissen haben nur satisfactory und template-chart keine Install-Test-Fixture — genau die zwei in ci/excluded-charts.txt. 29 Charts bekommen die Prüfung automatisch.

Das ist zu belegen, nicht anzunehmen: eine absichtlich falsche Policy in eine Fixture, Install-Test muss rot werden, danach zurücknehmen. Hält das nicht, ist das Netz nicht da und der Umfang gehört neu besprochen.

Die beiden Präzedenzfälle sind der Entwurf

valkey und stalwart sind die zwei Charts, die schon eine Policy haben, und sie tragen die teuren Lehren. Sie gehören übernommen, nicht neu erfunden:

  • policyTypes nur, wo es etwas einzuschränken gibt. valkey liefert bewusst nur Ingress — „an egress rule here would constrain nothing while making the object look stricter than it is".
  • Ein leeres from erlaubt ALLES. Steht so im valkey-Kommentar; die Namensräume werden deshalb immer ausgeschrieben.
  • kubernetes.io/metadata.name wird von Kubernetes selbst gesetzt (≥ 1.21) — keine Label-Arbeit an fremden Namensräumen.
  • Pod-Ports, nicht NodePorts. Eine Policy wirkt an der Pod-Schnittstelle, nachdem kube-proxy übersetzt hat. 30025 trifft nichts, sieht streng aus und blockiert alles.
  • Egress nach Port, nicht nach Ziel — Policies matchen CIDRs und Selektoren, niemals Hostnamen.
  • Probes kommen von der IP des Knotens, auf dem der Pod läuft. Fehlt sie, wird der Pod nie Ready — „and a pod that is never Ready reads as a broken application rather than as a policy".

Vier CI-Zusicherungen — der Teil, der den Rollout trägt

Nach dem Vorbild von ci/run-selector-match-test.sh, das diese Gattung Prüfung schon macht und mit #131 um podAffinity erweitert wurde. Alle vier sind render-seitig entscheidbar:

  1. Der podSelector trifft eine Pod-Spezifikation desselben Renders. Sonst ist die Policy ein Objekt ohne Wirkung — oder, schlimmer, sie trifft nach einem Label-Umbau nichts mehr und niemand merkt es.
  2. Jeder Port einer NetworkPolicy kommt als containerPort in der selektierten Pod-Spezifikation vor. Das fängt die NodePort-Falle mechanisch — genau den Fehler, vor dem stalwarts Template in Großbuchstaben warnt.
  3. Keine Ingress-Regel mit fehlendem oder leerem from, wenn policyTypes Ingress enthält. Fängt „erlaubt alles" im Gewand von Strenge.
  4. Der Probe-Pfad. Für jeden Port, den eine Liveness-, Readiness- oder Startup-Probe anspricht, muss die Policy ihn entweder nicht nach Quelle einschränken, oder der Chart muss einen Wert wie probeSources anbieten und in NOTES.txt sagen, dass ohne die Knoten-IP der Pod nie Ready wird. Das ist die gefährlichste Falle über 29 Charts und die einzige, die der Install-Test erst nach Minuten zeigt.

Umfang

  • template-chart: die Referenz-Implementierung, plus values.yaml, values.schema.json, NOTES.txt.
  • Alle übrigen Charts, Vorgabe an, je Chart ein Major. valkey und stalwart werden auf die Konvention gezogen, wo sie abweichen, ohne ihre begründeten Besonderheiten einzuebnen (Egress nach Port bei stalwart, Ingress-only bei valkey).
  • Die vier Zusicherungen als neuer Test plus Pipeline-Job.
  • README.md („Chart style guidelines") und Wiki Chart-Style-Guide, CI-CD, jede berührte Chart-Seite, und Lessons-Learned für die übertragbaren Fallen.
  • Ein Commit je Chart, mit Zwischenpushes. Bei dieser Größe ist das keine Form, sondern Haltbarkeit.

Was unbeweisbar bleibt

  • Dass Verkehr nach dem Merge noch fließt, lässt sich für die Produktion nicht zeigen: der Install-Test belegt den Probe-Pfad und die Annahme durch den API-Server, nicht den Weg von Traefik zum Pod — in k3d läuft kein Traefik.
  • satisfactory hat keine Install-Test-Abdeckung. Für diesen einen Chart gibt es kein Netz außer dem Review.
  • Egress bleibt grobkörnig. Ohne FQDN kann eine Policy nur Ports begrenzen, nicht Ziele — das ist eine echte Grenze und keine Nachlässigkeit, und sie gehört je Chart hingeschrieben statt stillschweigend in Kauf genommen.
# Genehmigter Plan — und der Rumpf beschreibt einen Cluster, der seit heute nicht mehr existiert Alles unten gemessen am 14.10.2026 am laufenden Cluster und an `origin/main`. ## Die drei Fragen aus „Zu klären vor der Umsetzung" sind beantwortet **1. Namespace und Labels des Ingress-Controllers — aber nicht mit der Antwort, die der Rumpf annimmt.** | | | | --- | --- | | ingress-nginx | **weg** — kein DaemonSet, null Pods | | IngressClass | nur noch **`traefik`** (`traefik.io/ingress-controller`), als Vorgabe; **keine `nginx`-Klasse** | | Ingress-Objekte im ganzen Cluster | **null** | | Traefik | `kube-system`, DaemonSet `rke2-traefik`, 6/6, Ports `web=8000`, `websecure=8443` | Die Quelle für die Ingress-Richtung ist damit: ```yaml - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: app.kubernetes.io/name: rke2-traefik ``` Beides in **einem** `from`-Eintrag ist ein UND. Eine gegen ingress-nginx geschriebene Policy würde still **allen** Web-Verkehr blockieren. Stichproben, dass der Weg wirklich über Traefik läuft: `id.klein.pub` → `302 → /realms/klein-family/account/`, MTA-STS-Policy → 200. **2. Liegen die Abhängigkeiten im Cluster?** Für die Hauptfälle ja: `postgres-18`, `maria-db` und `keycloak` (OIDC) laufen im Cluster, `stalwart` liefert SMTP. `namespaceSelector` genügt also; `ipBlock` braucht nur, was wirklich außerhalb liegt. **3. Setzt die CNI durch?** Ja — und sie ist **Canal**: Flannel fürs Netz, **Calico** für die Policies, 6/6. Daraus folgt eine harte Grenze: **kein FQDN-Egress.** Nur `podSelector`, `namespaceSelector`, `ipBlock`. Calicos `GlobalNetworkSet`-CRD liegt vor, aber es zu benutzen würde die Charts an Calico binden — dasselbe Argument, das implementierungsspezifische Policy-Objekte aus dem Gateway-Sweep (#114) herausgehalten hat. **Kein clusterweites Default-Deny** — das schadet nicht: ein von einer Policy selektierter Pod wird für die genannten Richtungen von selbst dicht. Ein Rollout Chart für Chart wirkt also auch ohne. ## Entscheidungen des Maintainers **Vorgabe `networkPolicy.enabled: true`**, wie bei `stalwart`. Also **Major je Chart**. Die Alternative (aus, pro Release eingeschaltet) wurde mit der Begründung abgelehnt, dass #5 sonst erst erreicht ist, wenn jemand es in `jk-cluster-config` einschaltet. **Alle Charts in einer Runde**, nicht nach Gestalt gruppiert. **Der Preis ist benannt und bewusst:** eine falsche Quelle macht einen Dienst stumm oder einen Pod nie `Ready`, und das erreicht die laufenden Releases beim nächsten Upgrade. ## Was das Risiko trägt: der Install-Test setzt Policies durch Und das ist der Grund, warum „alles auf einmal mit Vorgabe an" vertretbar ist. `k3d cluster create` in `.github/workflows/install-test.yml:304` und `:314` läuft **ohne `--disable-network-policy`** und ohne `--k3s-arg`, der daran rührt — k3s bringt seinen Policy-Controller also mit. **Eine Policy, die den Probe-Pfad blockiert, macht den Pod nie `Ready` und den Install-Test rot**, in CI statt in Produktion. Und die Abdeckung ist fast vollständig: von 30 Chart-Verzeichnissen haben **nur `satisfactory` und `template-chart`** keine Install-Test-Fixture — genau die zwei in `ci/excluded-charts.txt`. **29 Charts bekommen die Prüfung automatisch.** **Das ist zu belegen, nicht anzunehmen:** eine absichtlich falsche Policy in eine Fixture, Install-Test muss rot werden, danach zurücknehmen. Hält das nicht, ist das Netz nicht da und der Umfang gehört neu besprochen. ## Die beiden Präzedenzfälle sind der Entwurf `valkey` und `stalwart` sind die zwei Charts, die schon eine Policy haben, und sie tragen die teuren Lehren. Sie gehören übernommen, nicht neu erfunden: - **`policyTypes` nur, wo es etwas einzuschränken gibt.** `valkey` liefert bewusst nur `Ingress` — *„an egress rule here would constrain nothing while making the object look stricter than it is"*. - **Ein leeres `from` erlaubt ALLES.** Steht so im `valkey`-Kommentar; die Namensräume werden deshalb immer ausgeschrieben. - **`kubernetes.io/metadata.name`** wird von Kubernetes selbst gesetzt (≥ 1.21) — **keine Label-Arbeit an fremden Namensräumen**. - **Pod-Ports, nicht NodePorts.** Eine Policy wirkt an der Pod-Schnittstelle, nachdem kube-proxy übersetzt hat. `30025` trifft nichts, sieht streng aus und blockiert alles. - **Egress nach Port, nicht nach Ziel** — Policies matchen CIDRs und Selektoren, niemals Hostnamen. - **Probes kommen von der IP des Knotens**, auf dem der Pod läuft. Fehlt sie, wird der Pod nie `Ready` — *„and a pod that is never Ready reads as a broken application rather than as a policy"*. ## Vier CI-Zusicherungen — der Teil, der den Rollout trägt Nach dem Vorbild von `ci/run-selector-match-test.sh`, das diese Gattung Prüfung schon macht und mit #131 um `podAffinity` erweitert wurde. Alle vier sind **render-seitig entscheidbar**: 1. **Der `podSelector` trifft eine Pod-Spezifikation desselben Renders.** Sonst ist die Policy ein Objekt ohne Wirkung — oder, schlimmer, sie trifft nach einem Label-Umbau nichts mehr und niemand merkt es. 2. **Jeder Port einer NetworkPolicy kommt als `containerPort` in der selektierten Pod-Spezifikation vor.** Das fängt die NodePort-Falle **mechanisch** — genau den Fehler, vor dem `stalwart`s Template in Großbuchstaben warnt. 3. **Keine Ingress-Regel mit fehlendem oder leerem `from`**, wenn `policyTypes` `Ingress` enthält. Fängt „erlaubt alles" im Gewand von Strenge. 4. **Der Probe-Pfad.** Für jeden Port, den eine Liveness-, Readiness- oder Startup-Probe anspricht, muss die Policy ihn entweder **nicht** nach Quelle einschränken, oder der Chart muss einen Wert wie `probeSources` anbieten **und** in `NOTES.txt` sagen, dass ohne die Knoten-IP der Pod nie `Ready` wird. Das ist die gefährlichste Falle über 29 Charts und die einzige, die der Install-Test erst nach Minuten zeigt. ## Umfang - `template-chart`: die Referenz-Implementierung, plus `values.yaml`, `values.schema.json`, `NOTES.txt`. - **Alle übrigen Charts**, Vorgabe an, je Chart ein **Major**. `valkey` und `stalwart` werden auf die Konvention gezogen, wo sie abweichen, **ohne** ihre begründeten Besonderheiten einzuebnen (Egress nach Port bei `stalwart`, Ingress-only bei `valkey`). - Die vier Zusicherungen als neuer Test plus Pipeline-Job. - `README.md` („Chart style guidelines") und Wiki `Chart-Style-Guide`, `CI-CD`, jede berührte Chart-Seite, und `Lessons-Learned` für die übertragbaren Fallen. - **Ein Commit je Chart, mit Zwischenpushes.** Bei dieser Größe ist das keine Form, sondern Haltbarkeit. ## Was unbeweisbar bleibt - **Dass Verkehr nach dem Merge noch fließt**, lässt sich für die Produktion nicht zeigen: der Install-Test belegt den **Probe-Pfad** und die Annahme durch den API-Server, nicht den Weg von Traefik zum Pod — in k3d läuft kein Traefik. - **`satisfactory`** hat keine Install-Test-Abdeckung. Für diesen einen Chart gibt es kein Netz außer dem Review. - **Egress bleibt grobkörnig.** Ohne FQDN kann eine Policy nur Ports begrenzen, nicht Ziele — das ist eine echte Grenze und keine Nachlässigkeit, und sie gehört je Chart hingeschrieben statt stillschweigend in Kauf genommen.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
inhouse-chart
Inhouse-Chart aus der JLab-Git-Paketregistry
 renovate
Von Renovate angelegt
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jklein (Justin Klein) jlab-bot (jlab-git-bot) jlab-renovate-bot (jlab-renovate-bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#5