kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Dagostino <rndg...@gmail.com>
Subject Re: [DISCUSS] KIP-432: Additional Broker-Side Opt-In for Default, Unsecure SASL/OAUTHBEARER Implementation
Date Thu, 21 Feb 2019 13:49:28 GMT
HI Rajini and Stan.  Thanks for the feedback.

Stan, regarding the proposed config name, I couldn't think of anything so I
just threw in something outrageous in the hopes that it would give a sense
of what I was talking about while perhaps making folks chuckle a bit.

Rajini, I definitely see your point.  It probably doesn't make sense to
address this one particular issue (if we can even consider it an issue)
when in fact it is part of a pattern that has been explicitly agreed upon
as being appropriate.

Maybe a security sanity check tool that scans the config and flags any of
these items you mentioned, plus the OAUTHBEARER one and any others we can
think of, would be useful?  That way the out-of-the-box experience can
remain straightforward while some of the security risk that comes as a
byproduct can be mitigated.

Ron

Ron

On Thu, Feb 21, 2019 at 8:02 AM Rajini Sivaram <rajinisivaram@gmail.com>
wrote:

> Hi Ron,
>
> Thanks for the KIP. How is this different from other scenarios:
>
>    1. Our default is to use a PLAINTEXT listener. If you forget to change
>    that, anyone has access to your cluster
>    2. You may add a PLAINTEXT listener to the list of listeners in
>    production. May be you intended it for an interface that was protected
>    using network segmentation, but entered the wrong address.
>    3. You are very security conscious and add an SSL listener. You must be
>    secure now right? Our default is `ssl.client.auth=none`, which means any
>    one can connect.
>    4. You use the built-in insecure PLAIN callback that stores cleartext
>    passwords on the file system. Or enable SASL/PLAIN without SSL.
>
> At the moment, our defaults are intended to make it easy to get started
> quickly. If we want to make brokers secure by default, we need an approach
> that works across the board. I am not sure we have a specific issue with
> OAUTHBEARER apart from the fact that we don't provide a secure alternative.
>
>
>
> On Thu, Feb 21, 2019 at 12:05 PM Stanislav Kozlovski <
> stanislav@confluent.io>
> wrote:
>
> > Hey Ron, thanks for the KIP.
> >
> > I believe the proposed configuration setting
> > `yes.virginia.i.really.do
> >
> .want.to.allow.unsecured.oauthbearer.tokens.because.this.is.not.a.production.cluster`
> > might be too verbose. I acknowledge that we do not want to enable this in
> > production but we could maybe compromise on a more normal name.
> >
> > I am wondering whether it would be more worth it to replace the default
> > implementation with a secure one. Disabling it by default can be seen as
> > just kicking the can down the road
> >
> > Best,
> > Stanislav
> >
> >
> >
> > On Wed, Feb 20, 2019 at 5:31 PM Ron Dagostino <rndgstn@gmail.com> wrote:
> >
> > > Hi everyone. I created KIP-432: Additional Broker-Side Opt-In for
> > Default,
> > > Unsecure SASL/OAUTHBEARER Implementation
> > > <
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091238
> > > >
> > >  (
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091238
> > > ).
> > > The motivation for this KIPis as follows:
> > >
> > > The default implementation of SASL/OAUTHBEARER, as per KIP-255
> > > <
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75968876
> > > >,
> > > is unsecured.  This is useful for development and testing purposes, and
> > it
> > > provides a great out-of-the-box experience, but it must not be used in
> > > production because it allows the client to authenticate with any
> > principal
> > > name it wishes.  To enable the default unsecured SASL/OAUTHBEARER
> > > implementation on the broker side simply requires the addition of
> > > OAUTHBEARER to the sasl.enabled.mechanisms configuration value (for
> > > example:
> > >  sasl.enabled.mechanisms=GSSAPI,OAUTHBEARER instead of simply
> > > sasl.enabled.mechanisms=GSSAPI). To secure the implementation requires
> > the
> > > explicit setting of the
> > >
> > >
> >
> listener.name.{sasl_plaintext|sasl_ssl}.oauthbearer.sasl.{login,server}.callback.handler.class
> > >  properties on the broker.  The question then arises: what if someone
> > > either accidentally or maliciously appended OAUTHBEARER to the
> > > sasl.enabled.mechanisms configuration value?  Doing so would enable the
> > > unsecured implementation on the broker, and clients could then
> > authenticate
> > > with any principal name they desired.
> > >
> > > This KIP proposes to add an additional opt-in configuration property on
> > the
> > > broker side for the default, unsecured SASL/OAUTHBEARER implementation
> > such
> > > that simply adding OAUTHBEARER to the sasl.enabled.mechanisms
> > configuration
> > > value would be insufficient to enable the feature.  This additional
> > opt-in
> > > broker configuration property would have to be explicitly set to true
> > > before the default unsecured implementation would successfully
> > authenticate
> > > users, and the name of this configuration property would explicitly
> > > indicate that the feature is not secure and must not be used in
> > > production.  Adding this explicit opt-in is a breaking change; existing
> > > uses of the unsecured implementation would have to update their
> > > configuration to include this explicit opt-in property before their
> > cluster
> > > would accept unsecure tokens again.  Note that this would only result
> in
> > a
> > > breaking change in production if the unsecured feature is either
> > > accidentally or maliciously enabled there; it is assumed that 1) this
> > will
> > > probably not happen to anyone; and 2) if it does happen to someone it
> > > almost certainly would not impact sanctioned clients but would instead
> > > impact malicious clients only (if there were any).
> > >
> > >
> > > Ron
> > >
> >
> >
> > --
> > Best,
> > Stanislav
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message