There are several benefits in using Istio’s built-in security mechanism, including:

  • Full mTLS inside and outside the cluster.
  • Out of the box mTLS for all components: Apache Kafka, Zookeeper, Cruise Control, Mirror Maker, Minion, without the need to set up JKS truststores and keystores for each.
  • If you have a client application accessing Kafka, you only have to drop it into the mesh and you get instant mTLS.
  • You can use the existing Kafka ACLs and enforce them as Kubernetes RBAC, without having to rewrite the Kafka broker clients.

Other benefits are listed in the following sections.

Security benefits 🔗︎

Developers and operators do not have to worry about implementing security features, they can rely on the transparent security features provided by the service mesh:

  • Accessing brokers outside or inside the mesh happens through mTLS and is provided by Istio.
  • Issuing and renewing certificates for services running in the mesh is fully managed by Istio.
  • Relying on Istio’s mTLS can improve the performance by up to 20%.
  • Inside the mesh, no modification or reconfiguration is needed on the client side to make mTLS work.
  • Secure Zookeeper quorum communication and access is provided for Kafka clusters installed with Supertubes on Kubernetes.
  • Fine grained access, built on Kubernetes native building blocks.

Operational benefits 🔗︎

  • Operators are leveraging the power of Kubernetes and there is no need to rely on Kafka-specific security implementations.
  • Perimeter and access security relies on native Kubernetes concepts, managed by Istio.
  • Out of the box observability: Supertubes is using federated Prometheus-based monitoring and provides deep insights, dashboards, and alerts.
  • Based on observability, properly sizing a Kafka cluster on Kubernetes is easy and becomes a simple iterative process based on metrics.
  • There are fine-grained and multiple access gateways relying on the multi ingress gateway support of Istio.
  • Extended Kafka protocol level metrics without client or broker modification.
  • Span Kafka clusters across AZ, multiple datacenters or hybrid clouds with ease.
  • Locality based load balancing makes Kafka clusters spanning across multiple Kubernetes clusters operate efficiently in multiple clouds.

Additional benefits 🔗︎

  • RBAC integration can be entirely handled by Supertubes and the Envoy protocol filter. The solution maps users inside Kafka to a service account handled by Supertubes, while the protocol filter adds the required ACL information to the incoming messages. That way you can define ACLs more fine-grained than topics. You can push down ACLs to Kafka partition level.
  • The filter plugin can do major version protocol-level transformations. Even though clients might stay on older Kafka versions, the cluster itself can be upgraded, and version incompatibility handled at Kafka protocol filter level.
  • Observability and management UI highlight the complete flow.
  • Extended client throttling based not just on throughput (provided by Kafka already) but on other metrics as well.