[
https://issues.apache.org/jira/browse/KAFKA-20526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18082715#comment-18082715
]
Mehari Beyene commented on KAFKA-20526:
---------------------------------------
Kip published and under discussion:
https://lists.apache.org/thread/b3n4888oy27rdh069yfnqgo93p2tsrkr
> Add ListClientConnections Admin API to list authenticated connections on
> brokers
> --------------------------------------------------------------------------------
>
> Key: KAFKA-20526
> URL: https://issues.apache.org/jira/browse/KAFKA-20526
> Project: Kafka
> Issue Type: New Feature
> Components: clients, core
> Reporter: Mehari Beyene
> Assignee: Mehari Beyene
> Priority: Major
> Labels: kip, observability, security
>
> h3. Motivation
> Kafka brokers authenticate every client connection and store the
> authenticated principal (KafkaPrincipal) in memory on each KafkaChannel.
> However, there is *no admin API, CLI command, or JMX MBean* that allows an
> operator to answer:
> {quote}Which user principals currently have active connections to this broker?
> {quote}
> This is a fundamental observability gap. Every comparable system provides
> this capability:
> ||System||Command / API||
> |MySQL|{{SHOW PROCESSLIST}}|
> |PostgreSQL|{{pg_stat_activity}}|
> |RabbitMQ|Management API {{/api/connections}}|
> |MongoDB|{{db.currentOp()}}|
> |Apache Kafka|*Nothing*|
> h3. Use Cases
> * {*}Security incident response{*}: When a credential is compromised,
> operators cannot determine if the compromised user has active connections
> without restarting brokers or using indirect workarounds.
> * {*}Credential rotation{*}: No way to verify old credentials are no longer
> in use on active connections.
> * {*}Audit and compliance{*}: Regulatory requirements mandate reporting who
> is connected at any point in time.
> * {*}Debugging{*}: Correlating connections with authenticated identities
> during troubleshooting.
> h3. Current State
> The broker already holds all the data in memory:
> {code:java}
> SocketServer
> └── NetworkProcessor (one per network thread)
> └── Selector
> └── channels: Map[String, KafkaChannel]
> └── KafkaChannel
> ├── principal(): KafkaPrincipal ← authenticated
> user
> ├── socketAddress: InetAddress ← client IP
> ├── channelMetadataRegistry
> │ └── clientInformation ← software
> name/version
> └── id: String ← connection ID
> {code}
> The data is simply not surfaced through any external interface.
> h3. Proposed Change
> Add a new {{ListClientConnections}} admin API (broker-level RPC) that returns
> information about all currently authenticated connections on the target
> broker.
> *Request fields:*
> * {{PrincipalFilter}} (optional string) — filter by principal name
> * {{ClientAddressFilter}} (optional string) — filter by client IP
> *Response fields per connection:*
> * {{ConnectionId}} — the connection ID string
> * {{Principal}} — authenticated principal (e.g. {{User:alice}})
> * {{ClientAddress}} — remote client IP
> * {{ClientPort}} — remote client port
> * {{ListenerName}} — the listener the client connected to
> * {{SecurityProtocol}} — PLAINTEXT, SSL, SASL_PLAINTEXT, or SASL_SSL
> * {{SoftwareName}} — client software name (from KIP-511)
> * {{SoftwareVersion}} — client software version
> A formal KIP will follow with complete request/response schemas and
> implementation details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
