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 <stanis...@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 <rndg...@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 >
