Cilium Network Policies
Cilium Network Policies bieten eine deutlich mächtigere Steuerung des Netzwerkverkehrs als Standard Kubernetes Network Policies. Durch den Einsatz von eBPF können Regeln nicht nur auf IP-Ebene, sondern auch auf Applikationsebene (Layer 7) und basierend auf Service-Identitäten durchgesetzt werden.
Vorteile gegenüber Standard-Policies
- Layer 7 Kontrolle: Filtern Sie Traffic basierend auf HTTP-Methoden (GET, POST), URLs oder Kafka Topics.
- Identitätsbasierte Sicherheit: Regeln beziehen sich auf logische Identitäten (Labels), nicht auf IP-Adressen. Das macht sie in dynamischen Cloud-Umgebungen wesentlich robuster.
- Egress-Kontrolle: Präzise Steuerung, welche externen Ziele (FQDNs) ein Pod erreichen darf.
- Clusterweite Policies:
CiliumClusterwideNetworkPolicyerlaubt Regeln, die Namespace-übergreifend gelten – ideal für Basissicherheitsregeln.
Richtlinien erstellen
Cilium Policies werden als CRDs (Custom Resource Definitions) definiert.
Beispiel: Eine Policy, die nur HTTP GET Requests auf Port 80 zu einer App erlaubt:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-http-get-only
namespace: default
spec:
endpointSelector:
matchLabels:
app: my-app
ingress:
- fromEndpoints:
- matchLabels:
app: allowed-client
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: GETTipp: Nutzen Sie den Cilium Network Policy Editor, um Policies visuell zu erstellen und syntaxkonform zu generieren.
Anwendung
Speichern Sie die Definition als YAML-Datei und wenden Sie sie wie gewohnt an:
kubectl apply -f cilium-network-policy.yamlTroubleshooting mit Hubble
In Kombination mit Hubble wird das Debugging von Policies sehr einfach. Sie sehen in Echtzeit, welche Pakete DROPPED oder FORWARDED werden.
Zugriff
Hubble ist über Teleport Connect oder die Teleport Web UI sowie via CLI erreichbar.
Nutzen Sie Hubble, um zu verifizieren, ob Ihre "Deny-by-default"-Strategie wie gewünscht funktioniert oder ob legitimer Traffic blockiert wird.