kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Kozlovski <stanis...@confluent.io>
Subject Re: [DISCUSS] KIP-432: Additional Broker-Side Opt-In for Default, Unsecure SASL/OAUTHBEARER Implementation
Date Thu, 21 Feb 2019 12:05:17 GMT
Hey Ron, thanks for the KIP.

I believe the proposed configuration setting
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


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


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