Kafka 0.10.2.1 protects SCRAM metadata from broad reads

Metadata access rules need to distinguish public operational information from authentication material. Kafka 0.10.2.1 applies that distinction to SCRAM credentials in ZooKeeper. A path containing user configuration cannot safely receive the same broad read permissions as metadata intended for ordinary inspection, even though both are configuration data.

The 26 April release entry identifies this as a maintenance release. Its release notes include KAFKA-4943, improving protection of SCRAM secrets through ZooKeeper ACLs. The implementation shows the specific difference between sensitive paths and other metadata.

I value Kafka as a retained history shared by independent consumers. That sharing makes identity and access boundaries important. An application's permission to consume a topic should not imply broad access to the authentication material stored by the cluster's coordination infrastructure.

User configuration gets a sensitive-path classification

The ZooKeeper utility code at this release defines the user-configuration path under /config/users. It includes that path in a list of sensitive roots. The accompanying comment says paths containing sensitive information must not be world readable.

The ACL selection function now takes a path as well as a secure-mode flag. In secure mode it starts with creator access. It adds the broad read ACL only when the path is not sensitive. The path therefore determines whether the general read rule is appropriate.

This is more precise than treating every metadata read as equally harmless. Some coordination data needs to be visible to participants without granting them ownership of it. Credential-related data has different confidentiality requirements. The implementation makes that difference part of the ACL construction rule.

The code also retains a different branch for insecure mode, returning the open ACL. Installing the patch does not transform an intentionally unsecured ZooKeeper arrangement into a secured one. The new sensitive-path rule operates within the secure configuration path described by the implementation.

Derived credentials still require protection

The 0.10.2 security guide describes SCRAM identities stored in ZooKeeper as salt, iteration count, StoredKey and ServerKey. This is derived authentication material rather than a plaintext password. Its representation does not make public read access an appropriate default.

The guide explicitly ties the default SCRAM implementation to a secure ZooKeeper installation on a private network. It also requires TLS for the authentication exchange. These are separate boundaries, one around stored authentication material and another around communication with the broker.

April's ACL correction strengthens the stored-data boundary. The release note does not claim that it replaces TLS or changes the user's topic authorization. Authentication mechanism, metadata access and application permissions still have different jobs.

The utility code deprecates an older ACL helper that lacks the path argument. Its annotation directs callers to the path-aware function because the older form cannot distinguish sensitive data. That change matters for maintainers as well as administrators, since correct policy needs the relevant path at the point where permissions are chosen.

Secure migration also receives a repair

The maintenance notes include KAFKA-4864, stating that the secure migration tool did not secure all nodes. That is distinct from choosing the right ACL for a newly handled sensitive path. A migration tool has to apply the security model to existing coordination state as well.

Together, the issues illustrate two implementation requirements. The system needs a correct policy for the type of node, and the tool applying that policy needs to visit the relevant existing nodes. Fixing one does not by itself prove that the other was already correct.

The published release list does not establish the complete exposure history of a particular installation. That depends on its configuration and stored node permissions. The concrete released changes are the sensitive-path handling and the repair to migration coverage.

I prefer this explicit classification because it makes the confidentiality assumption inspectable in code. A caller supplies the path, and the utility decides whether ordinary read access applies. The policy no longer depends on treating every configuration node as if it contained the same kind of information.

Streams fixes concern local state ownership

Kafka 0.10.2.1 also repairs a stream-thread deadlock while obtaining a RocksDB lock and file contention when multiple Streams instances run. These failures affect local processing state. A broker retaining the input topic does not prevent a processing instance from being blocked by its own state-store coordination.

Other fixes address wildcard-source state stores and unexpected keys returned by a window-store query. Those descriptions concern how an application's processing topology and local stores relate to one another. They should not be interpreted as changes to the partition ordering guarantee of the underlying topic.

The release also corrects handling of the broker-level segment-size setting when no topic-specific override exists. That is another configuration precedence issue, but in log storage rather than credentials. Its inclusion reinforces that a maintenance version can change behavior under existing configuration without introducing a new application API.

The most consequential security change is narrow and concrete. In secure mode, user-configuration paths no longer receive the ordinary broad read ACL. Kafka 0.10.2.1 makes sensitive metadata a separate case in the utility that assigns ZooKeeper permissions, while retaining the distinction between that stored-data policy and authentication on broker connections.