-
Notifications
You must be signed in to change notification settings - Fork 6
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1 from Traiana/subject-spiffe-duality
Support regular Subject handling fallback when no SPIFFE ID can be determined
- Loading branch information
Showing
2 changed files
with
44 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,15 @@ | ||
## Kafka SPIFFE Principal Builder | ||
|
||
A custom `KafkaPrincipalBuilder` implementation for Apache Kafka. | ||
This class and documentation deals only with `SslAuthenticationContext`, we do not support any other context at the moment (Kerberos, SASL, Oauth) | ||
|
||
#### Default behavior | ||
The default `DefaultKafkaPrincipalBuilder` class that comes with Apache Kafka builds a principal | ||
name according to the x509 Subject in the SSL certificate. Since there is no logic that deals with *Subject Alternative Name*, | ||
this approach cannot handle a *SPIFFE ID*. | ||
|
||
#### New behavior | ||
The principal builder first looks for any valid *SPIFFE ID* in the certificate, if found, the *KafkaPrincipal* that will | ||
be returned would be seen by an *ACL Authorizer* as **SPIFFE:spiffe://some.spiffe.id.uri**. If that fails, a normal usage of the Subject will | ||
used with a normal **USER:CN=...** | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters