---
id: be40ba6e-b6d5-488a-9271-f741e60263af
---
# Kafka Unauthorized Access
---

This incident type refers to a situation where an unauthorized user gains access to a Kafka cluster due to misconfigured Access Control Lists (ACLs) in Kafka. This can result in potential data breaches or other security issues, as the unauthorized user may be able to read, write or modify data within the Kafka cluster. The incident typically requires immediate attention and remediation to prevent further unauthorized access.

### Parameters
```shell
export ZOOKEEPER_PORT="PLACEHOLDER"

export ZOOKEEPER_HOST="PLACEHOLDER"

export TOPIC_NAME="PLACEHOLDER"

export USER_NAME="PLACEHOLDER"

export AUTHORIZED_USERS="PLACEHOLDER"

export KAFKA_CONFIG_FILE="PLACEHOLDER"
```

## Debug

### Check if Kafka is running
```shell
systemctl status kafka
```

### Check if the Kafka ACLs are configured correctly
```shell
kafka-acls.sh --list --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```

### Check Kafka's logs for any errors
```shell
journalctl -u kafka | tail
```

### Check if the proper Kafka ACLs are set up for the user's role
```shell
kafka-acls.sh --describe --topic ${TOPIC_NAME} --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```

### Check if the user has the correct Kafka ACLs to access the topic
```shell
kafka-acls.sh --list --topic ${TOPIC_NAME} --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```

### Check if the user's Kafka credentials are set up correctly
```shell
kafka-configs.sh --describe --entity-type users --entity-name ${USER_NAME} --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```

## Repair

### Check and review the Kafka ACL configuration to ensure that permissions are set up correctly for the intended users and groups. You may need to update the configuration to limit access to only authorized users and groups.
```shell


#!/bin/bash



# Set the Kafka configuration file path

KAFKA_CONFIG_FILE=${KAFKA_CONFIG_FILE}



# Set the authorized user list

AUTHORIZED_USERS=${AUTHORIZED_USERS}



# Backup the existing Kafka configuration file

cp $KAFKA_CONFIG_FILE $KAFKA_CONFIG_FILE.bak



# Update the Kafka ACL configuration to limit access to only authorized users

sed -i 's/^.*allow.*$/allow='$AUTHORIZED_USERS'/' $KAFKA_CONFIG_FILE



# Restart the Kafka service

systemctl restart kafka.service



# Verify that the configuration changes are effective

kafka-acls --list --authorizer-properties zookeeper.connect=localhost:2181 --topic test-topic


```


This incident type refers to a situation where an unauthorized user gains access to a Kafka cluster due to misconfigured Access Control Lists (ACLs) in Kafka. This can result in potential data breaches or other security issues, as the unauthorized user may be able to read, write or modify data within the Kafka cluster. The incident typically requires immediate attention and remediation to prevent further unauthorized access.


This incident type is characterized by the detection of unauthorized access to the Kubernetes API server. This unauthorized access potentially enables attackers to manipulate cluster resources. Such incidents can lead to serious consequences, as unauthorized access allows attackers to make changes to the Kubernetes cluster, which may compromise the security and integrity of the entire system. Therefore, it is crucial to promptly detect and address such incidents to ensure the security and proper functioning of the Kubernetes cluster.


Unauthorized Access to Kubernetes API Server Detected

This incident type refers to a situation where there is an issue with the communication between Kafka brokers due to network partitioning. A network partition is a situation where a network is split into two or more parts, and communication between them is disrupted. This issue can lead to data inconsistency, loss of messages, delayed message delivery, and other related problems. As a result, it is important to quickly detect and resolve these incidents to prevent any downstream impact on the system.


Network Partitioning Between Kafka Brokers.

This type of incident occurs when the offset of a Kafka topic decreases unexpectedly. In Kafka, an offset is a unique identifier that represents the position of a message within a partition. When the offset decreases, it means that some messages have been lost or deleted, which can cause data inconsistencies or other issues within the system. This incident type is critical for Kafka-based systems as it affects data integrity and can lead to data loss.


Kafka topic offset decreased incident.

This type of incident occurs when a node in the Kafka cluster is not being fully utilized. Kafka is a distributed streaming platform, and each node in the cluster is responsible for processing and storing a portion of the data. If a node is underutilized, it means that it is not processing as much data as it should be, which can lead to performance issues and potential data loss. Therefore, it is important to identify and address underutilized nodes in a Kafka cluster to ensure optimal performance and data reliability.


Kafka node underutilization check incident.

This incident type refers to an issue where the network bandwidth on one or more Kafka nodes becomes fully saturated, causing the node(s) to experience performance degradation or even failure. This can result in message delivery delays or loss, and can also impact other nodes that rely on the affected node(s) for message replication. The saturation can be caused by a variety of factors, such as increased message traffic, misconfiguration, or hardware issues.


### Check if Kafka is running

```shell
systemctl status kafka
```

### Check if the Kafka ACLs are configured correctly

```shell
kafka-acls.sh --list --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```

### Check Kafka's logs for any errors

```shell
journalctl -u kafka | tail
```

### Check if the proper Kafka ACLs are set up for the user's role

```shell
kafka-acls.sh --describe --topic ${TOPIC_NAME} --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```

### Check if the user has the correct Kafka ACLs to access the topic

```shell
kafka-acls.sh --list --topic ${TOPIC_NAME} --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```

### Check if the user's Kafka credentials are set up correctly

```shell
kafka-configs.sh --describe --entity-type users --entity-name ${USER_NAME} --authorizer-properties zookeeper.connect=${ZOOKEEPER_HOST}:${ZOOKEEPER_PORT}
```


### Check and review the Kafka ACL configuration to ensure that permissions are set up correctly for the intended users and groups. You may need to update the configuration to limit access to only authorized users and groups.

```shell


#!/bin/bash



# Set the Kafka configuration file path

KAFKA_CONFIG_FILE=${KAFKA_CONFIG_FILE}



# Set the authorized user list

AUTHORIZED_USERS=${AUTHORIZED_USERS}



# Backup the existing Kafka configuration file

cp $KAFKA_CONFIG_FILE $KAFKA_CONFIG_FILE.bak



# Update the Kafka ACL configuration to limit access to only authorized users

sed -i 's/^.*allow.*$/allow='$AUTHORIZED_USERS'/' $KAFKA_CONFIG_FILE



# Restart the Kafka service

systemctl restart kafka.service



# Verify that the configuration changes are effective

kafka-acls --list --authorizer-properties zookeeper.connect=localhost:2181 --topic test-topic


```


Kafka Unauthorized Access

Overview

Parameters

Debug

Check if Kafka is running

Check if the Kafka ACLs are configured correctly

Check Kafka's logs for any errors

Check if the proper Kafka ACLs are set up for the user's role

Check if the user has the correct Kafka ACLs to access the topic

Check if the user's Kafka credentials are set up correctly

Repair

Check and review the Kafka ACL configuration to ensure that permissions are set up correctly for the intended users and groups. You may need to update the configuration to limit access to only authorized users and groups.

Learn more

Related Runbooks

Unauthorized Access to Kubernetes API Server Detected

Network Partitioning Between Kafka Brokers.

Kafka topic offset decreased incident.

Kafka node underutilization check incident.

Support