[jira] [Created] (KAFKA-14356) Make it possible to detect changes to SCRAM-SHA credentials using the Admin API

["Jakub Scholz (Jira)" <ji...@apache.org>]

Jakub Scholz created KAFKA-14356:
------------------------------------

             Summary: Make it possible to detect changes to SCRAM-SHA credentials using the Admin API
                 Key: KAFKA-14356
                 URL: https://issues.apache.org/jira/browse/KAFKA-14356
             Project: Kafka
          Issue Type: Improvement
            Reporter: Jakub Scholz


When using the Kafka Admin API to manage SCRAM-SHA credentials, the API seems to offer only three options:
 * Find out if given user has any credentials
 * Set SCRAM-SHA credentials
 * Delete SCRAM-SHA credentials

There is now way how to find out what the current credentials are. That makes sense as that can lead to the credentials being leaked which would be a security issue. However, there is also no way how to find out if the credentials changed since last time.

So if you have an external tool which is managing the SCRAM-SHA credentials based on some desired state in a controller loop (such as for example a Kubernetes Operator would do), there is no way to know whether you need to update the password in Kafka or not. And as a result, you always have to update the credentials.

It would be great to have some mechanism to detect if the credentials changes since last time. E.g.:
 * Timestamp of the last change
 * Some random hash assigned during each change of the credentials which can be compared before updating the credentials
 * Or possibly some offset of the KRaft metadata log where the credentials are stored.

An application managing the passwords, would get the indicator as a response to the the call updating the password and can store it. And in the next loop, it could describe the credentials which would return the latest indicator, compare it with what it stored and if they would be equal, it would know that it does not need to update the credentials.
----
If providing such indicator as part of the describe request would not be considered secure, maybe at least there can be some kind of conditional update call. Where the tool managing the passwords would get the change indicator as response to the update call. And will pass it in the subsequent update calls and the broker will evaluate it server-side if it changed or not and if it should be updated or ignored.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)