[
https://issues.apache.org/jira/browse/KAFKA-14340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bart Van Bos updated KAFKA-14340:
---------------------------------
Description:
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.
* [https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/#spiffe-id]
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.
was:
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.
> 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.
> * [https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/#spiffe-id]
> 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)
