[
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 clients 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 our 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 introspects X509 based client certificates, look for a URI based
SPIFFE entry in the SAN extension and returns that as a principle.
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.
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
micro-service ecosystem.
was:
Istio and other SPIFFE based systems use clients 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 our 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)
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.
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.
> 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
> Priority: Minor
>
> Istio and other *SPIFFE* based systems use clients 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 our 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 introspects X509 based client certificates, look for a URI
> based SPIFFE entry in the SAN extension and returns that as a principle.
> 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.
> 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 micro-service ecosystem.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
