This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.
Status
Current state: Draft
Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]
JIRA: here [Change the link from KAFKA-1 to your own ticket]
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
With the adoption of JEP 411: Deprecate the SecurityManager for Removal in Java 17, the SecurityManager is now deprecated, and will be removed in an unknown future version.
As Kafka supports multiple versions of Java (8, 11, 17, 21 for 3.x, 11, 17, 21 for 4.x), we should decide how to handle this deprecation and removal, and what replacements or mitigations we can provide for users of Kafka.
Kafka has a compile-time dependency on the AccessController
class in clients
, core
, and connect:runtime
, and the removal of SecurityManager and it's accompanying classes would make these modules un-buildable with their current implementation.
Public Interfaces
There are multiple strategies for when to remove SecurityManager support. The following are listed from shortest to longest support period, but may overlap with one-another.
Below, "Java R" refers to the first Java version which has Removed the SecurityManager, and "Java R-1" is the last Java version which has the SecurityManager.
Option A: Remove SecurityManager support in the next major Kafka version (4.0), before support for Java 11 is dropped
Pros:
- Removes SecurityManager the earliest, allowing users with Kafka 4.x to upgrade to Java R as soon as it is released
Cons:
- Users on Java 11 (where SecurityManager was never deprecated) will experience a removal with this KIP as a prior deprecation notice
Option B: Remove SecurityManager support in the first major Kafka version which drops support for Java 11 (5.0+)
Pros:
- Users on Java 11 will not see a Kafka release without SecurityManager support
Cons:
- This may delay adoption of Java R if it is released before the Java 11 support is intended to be removed
- We will need to commit to removing support for Java 11 at some future version, like we did in KIP-750 for Java 8
Option C: Remove SecurityManager support in a major Kafka version that adds support for a Java R (5.0+)
Pros:
- This allows the project to keep a single source tree/artifacts for all Java versions
Cons:
- It will inconvenience users which do not use the SecurityManager when they try to upgrade to Java R without it being officially supported
- It may also force a major version bump when it is inconvenient for the project, and other efforts requiring a major version bump may not be ready for it
- This may force dropping support for Java 11 earlier than expected
Option D: Remove SecurityManager support in a major Kafka version which drops support for Java R-1 (6.0+)
Pros:
- This is the longest window for SecurityManager support, and would give users the most opportunity to find an alternative.
Cons:
- Requires concurrent support for SecurityManager on versions before and after the removal
- More complicated implementation, build process, or artifact distribution
- Additional maintenance burden for dual-version support
Proposed Changes
The SaslClientCallbackHandler and OAuthBearerSaslClientCallbackHandler in clients
will no longer call Subject.getSubject
, and instead will use the JDK 18+ Subject.current
API: https://bugs.openjdk.org/browse/JDK-8267108 . TODO: this isn't good enough, because it means that JDK 17 has no way to provide a Subject to the handlers... Does this functionality need to be removed?
The calls to AccessController.doPriviliged
in core
and connect:runtime:
will be removed, and the privileged operations will be done in the original context.
Compatibility, Deprecation, and Migration Plan
Users upgrading to a version of Java or Kafka without SecurityManager support will need to disable their security manager implementations/configurations.
Users upgrading to Java 17+ (in which SecurityManager was deprecated) already receive a warning message on startup. We can additionally include a warning log in the next minor release that SecurityManager will be removed in a future Kafka version, and inform users of the removal schedule specified in this KIP.
Test Plan
There are currently no tests exercising the SecurityManager interface in Kafka, and no new tests for the end-to-end behavior will be added for this project.
Rejected Alternatives
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.