NetworkPolicy in OpenShift

Voraussetzung: ein Cluster mit oc login, Namespace library mit mindestens zwei laufenden Pods (z. B. catalog-service und api-gateway). Alles hier wirkt sofort, ohne Pod-Neustart – OVN (F1) erzwingt die Regeln direkt.

Ab Werk darf jeder Pod jeden Pod erreichen, clusterweit. Eine NetworkPolicy, die eine Pod-Menge auswählt, schaltet genau diese Pods auf default-deny für die genannte Richtung – danach erlaubst du gezielt einzelne Verbindungen wieder. Zeichnung aus dem OpenShift-Atlas F2, auf den library-Namespace bezogen.

Auswahl macht zu, Regeln machen auf. Ohne NetworkPolicy erreicht jeder Pod jeden – ein Namespace ist keine Netz-Grenze (ein Namespace). Eine Policy, die per podSelector eine Pod-Menge auswählt, schaltet genau diese Pods für die in policyTypes genannte Richtung auf default-deny; die ingress/egress-Regeln erlauben dann gezielt wieder. Es gibt kein Deny – mehrere Policies summieren ihre Erlaubnisse. Klassische Falle: die DNS-Egress-Regel vergessen, dann bricht die Namensauflösung.

ab Werk gilt default-allow: jeder Pod erreicht jeden Pod clusterweit – ein frischer Namespace ist offen
ein Namespace ist eine RBAC- und Quota-Grenze, aber keine Netz-Grenze – die kommt separat mit NetworkPolicy
eine Policy, die per podSelector eine Pod-Menge auswählt, schaltet genau diese Pods auf default-deny für die Richtungen in policyTypes (Ingress, Egress)
danach fügt man ingress/egress-Regeln hinzu, die bestimmten Verkehr wieder erlauben
Selektoren: podSelector, namespaceSelector, ipBlock (CIDR + except), ports
es gibt kein Deny in einer NetworkPolicy – nur Auswahl und Allow, und mehrere Policies auf denselben Pods summieren ihre Erlaubnisse (wie bei RBAC)
OVN (F1) erzwingt die Regeln – sie wirken sofort, ohne Pod-Neustart
AdminNetworkPolicy / BaselineAdminNetworkPolicy: clusterweit, admin-owned, werden vor den Namespace-Policies ausgewertet und können hart verbieten
Falle DNS: eine Egress-Policy ohne Regel für openshift-dns (Port 53) → die Namensauflösung bricht, alles läuft in Timeouts
Falle Probes: Health-Probes (Probes) kommen vom kubelet, nicht von einem Pod – separat erlauben
Bibliothek: eine deny-all-ingress-Basis in library, dann Ingress für api-gateway und library-frontend nur aus openshift-ingress, für die 6 internen Dienste nur aus api-gateway, Postgres und Kafka nur aus ihren Konsumenten
nachsehen: oc get netpol -n library, oc describe netpol deny-all-ingress -n library, testen mit oc rsh deploy/api-gateway -n library plus curl
OCP-Unterschied: NetworkPolicy ist reines Kubernetes – EgressFirewall und AdminNetworkPolicy sind die OVN-Erweiterungen

1 Default-allow, live

Ab Werk gilt default-allow: jeder Pod erreicht jeden Pod, clusterweit. Ein Namespace ist eine RBAC- und Quota-Grenze (A2), aber keine Netz-Grenze.

Laptop · Bash

# von einem Pod aus einen anderen Pod erreichen - geht ab Werk:
oc rsh -n library deploy/api-gateway curl -s -o /dev/null -w '%{http_code}\n' \
  http://catalog-service:8080/actuator/health

# es gibt noch keine einzige Policy:
oc get netpol -n library

Eine NetworkPolicy, die per podSelector eine Pod-Menge auswählt, schaltet genau diese Pods auf default-deny – aber nur für die Richtungen (ingress/egress), die sie überhaupt nennt. Eine Policy ohne egress-Block ändert am Egress nichts.

2 `deny-all-ingress` anlegen

Jetzt brechen wir den Traffic wirklich – und sehen es.

Laptop · Bash

cat <<'YAML' | oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: library
spec:
  podSelector: {}
  policyTypes: [Ingress]
YAML

# derselbe Aufruf wie eben - jetzt bricht er:
oc rsh -n library deploy/api-gateway curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 \
  http://catalog-service:8080/actuator/health
# Timeout oder Connection refused - sofort, kein Pod-Neustart noetig

podSelector: {} (leer) wählt alle Pods im Namespace. policyTypes: [Ingress] begrenzt die Wirkung auf eingehenden Verkehr – Egress bleibt unangetastet.

3 Gezielt wieder erlauben

Laptop · Bash

cat <<'YAML' | oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-api-gateway
  namespace: library
spec:
  podSelector:
    matchLabels: { app: catalog-service }
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector:
        matchLabels: { app: api-gateway }
    ports:
    - port: 8080
YAML

oc rsh -n library deploy/api-gateway curl -s -o /dev/null -w '%{http_code}\n' \
  http://catalog-service:8080/actuator/health
# 200 - api-gateway darf wieder rein. Jeder ANDERE Pod bleibt draussen

Zwei Policies auf demselben Pod (deny-all-ingress wählt ihn per podSelector: {} mit) – sie summieren sich, dazu mehr in Schritt 5.

4 Die Selektoren

Selektor	wählt
`podSelector`	Pods per Label, im eigenen Namespace
`namespaceSelector`	alle Pods in Namespaces mit passendem Label – für Verkehr zwischen Namespaces
`podSelector` + `namespaceSelector` zusammen	nur Pods mit beiden Labels (UND-Verknüpfung), im genannten Namespace
`ipBlock`	ein CIDR-Bereich, optional mit `except` – für Verkehr von/zu außerhalb des Clusters
`ports`	schränkt zusätzlich auf bestimmte Ports/Protokolle ein

Beispiel: aus jedem Namespace mit Label

  ingress:
  - from:
    - namespaceSelector:
        matchLabels: { network.openshift.io/policy-group: ingress }   # der Router-Namespace

5 Mehrere Policies summieren

Es gibt kein deny in einer NetworkPolicy – nur Auswahl und Allow.

1 Policywählt sie einen Pod aus, schaltet er für die genannte Richtung auf default-deny

mehrere Policiestreffen mehrere Policies denselben Pod, gilt die Vereinigung aller ingress/egress-Regeln – nie eine schränkt eine andere ein

AdminNetworkPolicyclusterweit, admin-owned, OVN-Erweiterung – wird vor den Namespace-Policies ausgewertet und kann explizit verbieten (Deny-Aktion), anders als die normale NetworkPolicy

Praktisch: eine breite deny-all-ingress plus mehrere kleine, gezielte allow-from-<dienst>-Policies ist der übliche Aufbau – nie eine einzige riesige Policy pflegen.

6 Zwei Fallen: DNS und Probes

Falle	Symptom	Fix
DNS	eine Egress-Policy ohne Regel für `openshift-dns` (Port 53) – die Namensauflösung bricht, alles läuft in Timeouts, nicht nur der gemeinte Verkehr	Egress-Policies bekommen immer eine Ausnahme für DNS mit
Probes	Health-Probes (B5) kommen vom kubelet, nicht von einem Pod – ein zu enges `podSelector` in der `from`-Liste blockt sie, der Pod geht auf `NotReady`	Probes brauchen keine extra Regel (sie laufen node-lokal), aber prüfen: kommt der Traffic wirklich von einem „Pod“ oder vom Node selbst

Laptop · Bash · DNS-Ausnahme

cat <<'YAML' | oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: library
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - { protocol: UDP, port: 53 }
    - { protocol: TCP, port: 53 }
YAML

7 Egress-Policy

Genau umgekehrt: nur den Traffic raus einschränken, Ingress bleibt offen.

Laptop · Bash

# testen: kann catalog-service gerade irgendwohin raus?
oc rsh -n library deploy/catalog-service curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 \
  http://api-gateway:8080/actuator/health

# Egress auf nur Postgres + DNS begrenzen (DNS-Ausnahme aus Schritt 6 vorausgesetzt):
cat <<'YAML' | oc apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: catalog-egress-db-only
  namespace: library
spec:
  podSelector:
    matchLabels: { app: catalog-service }
  policyTypes: [Egress]
  egress:
  - to:
    - podSelector:
        matchLabels: { app.kubernetes.io/name: postgresql }
    ports:
    - { port: 5432 }
YAML
# jetzt bricht der Aufruf zu api-gateway - Egress ist jetzt auf Postgres beschraenkt

Egress-Policies sind seltener als Ingress-Policies (das Risiko liegt meist im Reinkommen), aber genau richtig für einen Dienst, der nur zu seiner eigenen DB darf und sonst nirgendwohin – ein kompromittierter Pod kann dann nicht querschlagen.

8 Wie die Bibliothek es macht

Policy	Wirkung
`deny-all-ingress`	Basis im Namespace `library` – ab hier ist alles zu
`allow-from-router`	Ingress für `api-gateway` und `library-frontend` nur aus `openshift-ingress` (der Router-Namespace, B4) – die einzigen zwei Dienste mit einer Route
`allow-internal`	die 8 Spring-Dienste + Bitnami-Infra reden untereinander über `podSelector` auf gemeinsame Labels – kein Dienst ist von außen direkt erreichbar

Ergebnis: nur zwei Dienste haben überhaupt einen Weg von außen (plus Keycloak über seine eigene Route, B4) – die sechs restlichen Fachdienste sind nur clusterintern erreichbar, selbst wenn ihre Route aus Versehen angelegt würde, würde die NetworkPolicy den Zugriff trotzdem blocken.

9 Nachschauen

Befehl	zeigt
`oc get netpol -n library`	welche Policies existieren
`oc describe netpol deny-all-ingress -n library`	Selektor + Regeln im Klartext
`oc rsh deploy/<dienst> -n library` + `curl`	der einzige verlässliche Test – von einem echten Pod aus prüfen, nicht vom Laptop

Web-Konsole: Networking → NetworkPolicies zeigt eine Liste, aber keine Simulation – ob eine Verbindung wirklich durchkommt, testet man immer live aus einem Pod.

+ Die Kurzfassung

Vorgabedefault-allow, clusterweit – ein Namespace ist keine Netz-Grenze

eine Policywählt Pods per podSelector, schaltet sie für die genannte Richtung auf default-deny

mehrere Policiessummieren sich – nie deny, nur Vereinigung von Allow

zwei FallenDNS-Egress vergessen (alles bricht) · Probes kommen vom kubelet, nicht von einem Pod

1 Default-allow, live

2 deny-all-ingress anlegen

3 Gezielt wieder erlauben

4 Die Selektoren

5 Mehrere Policies summieren

6 Zwei Fallen: DNS und Probes

7 Egress-Policy

8 Wie die Bibliothek es macht

9 Nachschauen

+ Die Kurzfassung

2 `deny-all-ingress` anlegen