Replies: 2 comments
-
Example how its done: Restrict Kafka Topic Access to the Following Pods Typically, we’re forced to write networking policies like: "Allow any application with the label kafka-consumer" to speak to Kafka. This casts a rather wide net, when with L7 policies we can limit the access to individual topics depending on the labels.
https://deploy.equinix.com/developers/guides/choosing-a-cni-for-kubernetes |
Beta Was this translation helpful? Give feedback.
-
looks like the topic |
Beta Was this translation helpful? Give feedback.
-
For Kafka it's easy to level up security by using Cilium.
Cilium is a networking, observability, and security solution with an eBPF-based dataplane.
How it works to secure Kafka with Cilium:
Traditional firewalls operate at Layer 3 and 4. A protocol running on a particular port is either completely trusted or blocked entirely. Cilium provides the ability to filter on individual application protocol requests:
e.g. for Kafka:
Allow service1 to produce on Kafka topic topic1 and service2 to consume on topic1. Reject all other Kafka messages.
from readme
https://github.com/cilium/cilium
Details in Doc:
https://docs.cilium.io/en/stable/security/kafka/
=> Are there already any ideas/efforts/POCs know to bring these possibilities to the combination of Pulsar and Cilium?
Cilium seems to become the standard replacement for kube proxy plus IP tables these days,
so missing Pulsar support should not be the gatekeeper for enterprises...
Beta Was this translation helpful? Give feedback.
All reactions