Ron Dagostino created KAFKA-7960:
------------------------------------
Summary: KIP-432: Additional Broker-Side Opt-In for Default,
Unsecure SASL/OAUTHBEARER Implementation
Key: KAFKA-7960
URL: https://issues.apache.org/jira/browse/KAFKA-7960
Project: Kafka
Issue Type: Improvement
Components: clients
Affects Versions: 2.1.1, 2.1.0, 2.0.1, 2.0.0, 2.2.0, 2.1.2
Reporter: Ron Dagostino
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.
KIP-432
(https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091238)
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).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
