The error_message field sounds good to me Rajini. I agree that we should
file a separate JIRA for an authentication log.

Ismael

On Wed, Aug 30, 2017 at 3:53 PM, Rajini Sivaram <rajinisiva...@gmail.com>
wrote:

> Hi Roger,
>
> Thank you for the suggestions.
>
> I think we should have a separate JIRA to address logging improvements for
> authentication. That shouldn't need a KIP. The way the code is structured
> at the moment, SSL implementation is in the network package. And that makes
> it a bit messy to move authentication logs into a separate config.
>
> I have added an error_message field to SaslAuthenticate response.
>
> For those who have already voted, please let me know if you have any
> concerns about the new field.
>
> Thank you...
>
> Regards,
>
> Rajini
>
>
>
> On Tue, Aug 29, 2017 at 8:44 PM, Roger Hoover <roger.hoo...@gmail.com>
> wrote:
>
> > Hi Rajini,
> >
> > One more thought.  Maybe we should also add an error_message field in the
> > response like we do with CreateTopics response so that the server can
> > return an appropriate message that we can bubble up to the user.
> Examples
> > would be "Invalid username or password", "SASL Impersonation not
> allowed",
> > or "You account has been locked, please contact cluster admin".
> >
> > Thanks,
> >
> > Roger
> >
> > On Tue, Aug 29, 2017 at 12:41 PM, Roger Hoover <roger.hoo...@gmail.com>
> > wrote:
> >
> > > Hi Rajini,
> > >
> > > The metrics in KIP-188 will provide counts across all users but the log
> > > could potentially be used to audit individual authentication events.  I
> > > think these would be useful at INFO level but if it's inconsistent with
> > the
> > > rest of Kafka, DEBUG is ok too.  The default log4j config for Kafka
> > > separates authorization logs.  It seems like a good idea to treat
> > > authentication logs the same way whether or not we choose DEBUG or
> INFO.
> > >
> > > https://github.com/apache/kafka/blob/trunk/config/log4j.
> > properties#L54-L58
> > >
> > > Cheers,
> > >
> > > Roger
> > >
> > > On Tue, Aug 29, 2017 at 10:51 AM, Rajini Sivaram <
> > rajinisiva...@gmail.com>
> > > wrote:
> > >
> > >> Hi Roger,
> > >>
> > >> If we are changing logging level for successful SASL authentications
> in
> > >> the
> > >> broker, we should probably do the same for SSL too. Since KIP-188
> > proposes
> > >> to add new metrics for successful and failed authentications which may
> > be
> > >> more useful for monitoring, do we really need info-level logging for
> > >> authentication? At the moment, there don't seem to be any
> per-connection
> > >> informational messages at info-level, but if you think it is useful,
> we
> > >> could do this in a separate JIRA. Let me know what you think.
> > >>
> > >> On Tue, Aug 29, 2017 at 1:09 PM, Roger Hoover <roger.hoo...@gmail.com
> >
> > >> wrote:
> > >>
> > >> > Just re-read the KIP and was wondering if you think INFO would be ok
> > for
> > >> > logging successful authentications?  They should be relatively
> > >> infrequent.
> > >> >
> > >> > On Tue, Aug 29, 2017 at 9:54 AM, Roger Hoover <
> roger.hoo...@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> > > +1 (non-binding).  Thanks, Rajini
> > >> > >
> > >> > > On Tue, Aug 29, 2017 at 2:10 AM, Ismael Juma <ism...@juma.me.uk>
> > >> wrote:
> > >> > >
> > >> > >> Thanks for the KIP, +1 (binding) from me.
> > >> > >>
> > >> > >> Ismael
> > >> > >>
> > >> > >> On Thu, Aug 24, 2017 at 6:29 PM, Rajini Sivaram <
> > >> > rajinisiva...@gmail.com>
> > >> > >> wrote:
> > >> > >>
> > >> > >> > Hi all,
> > >> > >> >
> > >> > >> > I would like to start vote on KIP-152 to improve diagnostics of
> > >> > >> > authentication failures and to update clients to treat
> > >> authentication
> > >> > >> > failures as fatal exceptions rather than transient errors:
> > >> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > >> > >> > 152+-+Improve+diagnostics+for+SASL+authentication+failures
> > >> > >> >
> > >> > >> > Thank you...
> > >> > >> >
> > >> > >> > Rajini
> > >> > >> >
> > >> > >>
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Reply via email to