Thanks for the reviews.
Makes sense. I don't see any downsides. Updated the KIP, to go with Option
2.
I will be starting the vote thread soon.
Thanks,
On Wed, Sep 19, 2018 at 2:17 PM Rajini Sivaram
wrote:
> Hi Manikumar,
>
> Unless there is a downside to option 2 (e.g will it impose character
Hi Manikumar,
Unless there is a downside to option 2 (e.g will it impose character limits
in the DN), it may be better to go with option 2 for consistency and
flexibility.
On Wed, Sep 19, 2018 at 5:11 AM, Harsha wrote:
> Thanks. I am also leaning towards option 2, as it will help the
> consiste
Thanks. I am also leaning towards option 2, as it will help the consistency of
expressing such mapping between sasl and ssl.
-Harsha
On Tue, Sep 18, 2018, at 8:27 PM, Manikumar wrote:
> Hi Harsha,
>
> Thanks for the review. Yes, As mentioned on the motivation section, this is
> to simply extract
Hi Harsha,
Thanks for the review. Yes, As mentioned on the motivation section, this is
to simply extracting fields from the certificates
for the common use cases. Yes, we are not supporting extracting
SubjectAltName using this KIP.
Thanks,
On Wed, Sep 19, 2018 at 8:29 AM Harsha wrote:
> Hi Ma
Hi Manikumar,
I am interested to know the reason for exposing this config, given a
user has access to PrincipalBuilder interface to build their interpretation of
an identity from the X509 certificates. Is this to simplify extraction of
identity? and also there are other use cases where u
Hi Rajini,
I don't have strong reasons for rejecting Option 2. I just felt Option 1 is
sufficient for
the common use-cases (extracting single field, like CN etc..).
We are open to go with Option 2, for more flexible mapping mechanism.
Let us know, your preference.
Thanks,
On Tue, Sep 18, 2018
Hi Manikumar,
It wasn't entirely clear to me why Option 2 was rejected.
On Tue, Sep 18, 2018 at 7:47 AM, Manikumar
wrote:
> Hi All,
>
> We would like to go with Option 1, which adds a new configuration parameter
> pair of the form:
> ssl.principal.mapping.pattern, ssl.principal.mapping.value. T
Hi All,
We would like to go with Option 1, which adds a new configuration parameter
pair of the form:
ssl.principal.mapping.pattern, ssl.principal.mapping.value. This will
fulfill the requirement for most of the common use cases.
We would like to include the KIP in the upcoming release. If there
Definitely a helpful change. +1 for Option 2.
On 9/14/18, 10:52 AM, "Manikumar" wrote:
Hi Eno,
Thanks for the review.
Most often users want to extract one of the field (eg. CN). CN is the
commonly used field.
For this simple change, users need to build and maintain
Hi Eno,
Thanks for the review.
Most often users want to extract one of the field (eg. CN). CN is the
commonly used field.
For this simple change, users need to build and maintain the custom
principal builder class
and also package and deploy to the all brokers. Having configurable rules
will be u
Manikumar, thanks. If I understand the KIP motivation right, this is
currently already possible, but you want to have an easier way of doing it,
right? The motivation would be stronger if we had 2-3 common cases (from
experience) where the suggested pattern would solve them, and perhaps 1-2
cases w
Hi All,
We'd appreciate any thoughts / comments on the proposed options for
customizing SSL principal names.
We are happy to discuss any alternative approaches/suggestions.
Thanks,
On Sat, Sep 8, 2018 at 12:45 AM Manikumar wrote:
> Hi all,
>
> I have created a KIP that proposes couple of optio
Hi all,
I have created a KIP that proposes couple of options for building custom
SSL principal names.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-371%3A+Add+a+configuration+to+build+custom+SSL+principal+name
Please take a look.
Thanks,
Manikumar
13 matches
Mail list logo
