[
https://issues.apache.org/jira/browse/KAFKA-14340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bart Van Bos reassigned KAFKA-14340:
------------------------------------
Assignee: Bart Van Bos
> KIP-880: X509 SAN based SPIFFE URI ACL within mTLS Client Certificates
> -----------------------------------------------------------------------
>
> Key: KAFKA-14340
> URL: https://issues.apache.org/jira/browse/KAFKA-14340
> Project: Kafka
> Issue Type: Wish
> Components: security
> Affects Versions: 3.3.1
> Reporter: Bart Van Bos
> Assignee: Bart Van Bos
> Priority: Minor
>
> Istio and other *SPIFFE* based systems use X509 Client Certificates to
> provide workload ID. Kafka currently does support Client Cert based AuthN/Z
> and mapping to ACL, but only so be inspecting the CN field within a Client
> Certificate.
> There are several POC implementations out there implementing a bespoke
> _KafkaPrincipalBuilder_ implementation for this purpose. Two examples include
> * [https://github.com/traiana/kafka-spiffe-principal]
> * [https://github.com/boeboe/kafka-istio-principal-builder] (written by
> myself)
> The gist is to introspect X509 based client certificates, look for a URI
> based SPIFFE entry in the SAN extension and return that as a principle, that
> can be used to write ACL rules.
> This KIP request is to include this functionality into Kafka's main
> functionality so end-users don't need to load custom and non-vetted java
> classes/implementations.
> The main use case for me is having a lot of Istio customers that express the
> will to be able to leverage SPIFFE based IDs for their Kafka ACL
> Authorization. This eliminates the need for sidecars on the broker side or
> custom _EnvoyFilters_ and other less optimal implementations to integrate
> Kafka into an Istio secured Kubernetes environment.
> I believe this would make for a better integration between the Istio/SPIFFE
> and Kafka ecosystems.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
