Thanks for your comments. Have updated the KIP. I agree SSL and SASL_SSL will face similar issues and should behave the same. Thinking about this further, I'm wondering whether setting bootstrap.reverse.dns.lookup to true whilst using any of those protocols should throw a critical error and stop, or at least log a warning stating that the lookup won't be performed. This sounds better than silently ignoring and leave users with the impression they can use SSL and bootstrap server aliases. Abruptly stopping the client sounds a bit extreme so I'm leaning towards a warning.
Thoughts ? I'm not sure about checking whether the list has IP addresses. There could be cases where the list has a mix of FQDNs and IPs, so I would rather perform the lookup regardless of the case when the parameter is enabled. On the security aspects, I am by no means a security or SASL expert so commented the KIP with what I believe to be the case. Jonathan Skrzypek -----Original Message----- From: Rajini Sivaram [mailto:rajinisiva...@gmail.com] Sent: 29 April 2018 15:38 To: dev Subject: Re: [VOTE] KIP-235 Add DNS alias support for secured connection Hi Jonathan, Thanks for the KIP. +1 (binding) with a couple comments below to add more detail to the KIP. 1. Make it clearer when the new option `bootstrap.reverse.dns.lookup` should or shouldn't be used. Document security considerations as well as other system configurations that may have an impact. 2. The PR currently disables the new code path for security protocol SSL. But this doesn't address SASL_SSL which could also do hostname verification. Do we even want to do reverse lookup if bootstrap list contains IP addresses? If we do, we should handle SSL and SASL_SSL in the same way (which basically means handling all protocols in the same way). On Thu, Apr 26, 2018 at 2:16 PM, Stephane Maarek < steph...@simplemachines.com.au> wrote: > +1 as a user > BUT > > I am no security expert. I have experienced that issue while setting up a > cluster and while I would have liked a feature like that (I opened a JIRA > at the time), I always guessed that the reason was because of some security > protection. > > Now from a setup point of view this helps a ton, but I really want to make > sure this doesn't introduce any security risk by relaxing a constraint. > > Is there a security assessment possible by someone accredited ? > > Sorry for raising these questions just want to make sure it's addressed > > On Thu., 26 Apr. 2018, 5:32 pm Gwen Shapira, <g...@confluent.io> wrote: > > > +1 (binding) > > > > This KIP is quite vital to running secured clusters in cloud/container > > environment. Would love to see more support from the community to this > (or > > feedback...) > > > > Gwen > > > > On Mon, Apr 16, 2018 at 4:52 PM, Skrzypek, Jonathan < > > jonathan.skrzy...@gs.com> wrote: > > > > > Hi, > > > > > > Could anyone take a look ? > > > Does the proposal sound reasonable ? > > > > > > Jonathan Skrzypek > > > > > > > > > From: Skrzypek, Jonathan [Tech] > > > Sent: 23 March 2018 19:05 > > > To: dev@kafka.apache.org > > > Subject: [VOTE] KIP-235 Add DNS alias support for secured connection > > > > > > Hi, > > > > > > I would like to start a vote for KIP-235 > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_KAFKA_KIP-2D&d=DwIBaQ&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=nNmJlu1rR_QFAPdxGlafmDu9_r6eaCbPOM0NM1EHo-E&m=2JuW6J_xPCRzueIjC4B6j1v6T9aXMR5k9Nh8oMBVLd0&s=SJsuC6ROGH5VTVxQktBbB7xKK4zFDVRkQSUtZbLMfZ4&e= > > > > > > 235%3A+Add+DNS+alias+support+for+secured+connection > > > > > > This is a proposition to add an option for reverse dns lookup of > > > bootstrap.servers hosts, allowing the use of dns aliases on clusters > > using > > > SASL authentication. > > > > > > > > > > > > > > > > > > -- > > *Gwen Shapira* > > Product Manager | Confluent > > 650.450.2760 | @gwenshap > > Follow us: Twitter > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ConfluentInc&d=DwIBaQ&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=nNmJlu1rR_QFAPdxGlafmDu9_r6eaCbPOM0NM1EHo-E&m=2JuW6J_xPCRzueIjC4B6j1v6T9aXMR5k9Nh8oMBVLd0&s=hWdKCJsOe7LyDCcoJqmjOkgepGk7762xXxOZgQwHAm0&e= > > > | blog > > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.confluent.io_blog&d=DwIBaQ&c=7563p3e2zaQw0AB1wrFVgyagb2IE5rTZOYPxLxfZlX4&r=nNmJlu1rR_QFAPdxGlafmDu9_r6eaCbPOM0NM1EHo-E&m=2JuW6J_xPCRzueIjC4B6j1v6T9aXMR5k9Nh8oMBVLd0&s=Y_WMfuQJKoXlE3I25NKs8d4TefgB8OlvO8lDGAhEr7Q&e= > > > > > >