Protocol calls are usually performing some operations on certain resources in Kafka. It is required to know the + operations and resources to set up effective protection. In this section we'll list these operations and + resources, then list the combination of these with the protocols to see the valid scenarios.
+There are a few operation primitives that can be used to build up privileges. These can be matched up with + certain resources to allow specific protocol calls for a given user. These are:
+The operations above can be applied on certain resources which are described below.
+In the below table we'll list the valid operations on resources that are executed by the Kafka API protocols.
+| Protocol (API key) | +Operation | +Resource | +Note | +
|---|---|---|---|
| PRODUCE (0) | +Write | +TransactionalId | +An transactional producer which has its transactional.id set requires this privilege. | +
| PRODUCE (0) | +IdempotentWrite | +Cluster | +An idempotent produce action requires this privilege. | +
| PRODUCE (0) | +Write | +Topic | +This applies to a normal produce action. | +
| FETCH (1) | +ClusterAction | +Cluster | +A follower must have ClusterAction on the Cluster resource in order to fetch partition data. | +
| FETCH (1) | +Read | +Topic | +Regular Kafka consumers need READ permission on each partition they are fetching. | +
| LIST_OFFSETS (2) | +Describe | +Topic | ++ |
| METADATA (3) | +Describe | +Topic | ++ |
| METADATA (3) | +Create | +Cluster | +If topic auto-creation is enabled, then the broker-side API will check for the existence of a Cluster + level privilege. If it's found then it'll allow creating the topic, otherwise it'll iterate through the + Topic level privileges (see the next one). | +
| METADATA (3) | +Create | +Topic | +This authorizes auto topic creation if enabled but the given user doesn't have a cluster level + permission (above). | +
| LEADER_AND_ISR (4) | +ClusterAction | +Cluster | ++ |
| STOP_REPLICA (5) | +ClusterAction | +Cluster | ++ |
| UPDATE_METADATA (6) | +ClusterAction | +Cluster | ++ |
| CONTROLLED_SHUTDOWN (7) | +ClusterAction | +Cluster | ++ |
| OFFSET_COMMIT (8) | +Read | +Group | +An offset can only be committed if it's authorized to the given group and the topic too (see below). + Group access is checked first, then Topic access. | +
| OFFSET_COMMIT (8) | +Read | +Topic | +Since offset commit is part of the consuming process, it needs privileges for the read action. | +
| OFFSET_FETCH (9) | +Describe | +Group | +Similarly to OFFSET_COMMIT, the application must have privileges on group and topic level too to be able + to fetch. However in this case it requires describe access instead of read. Group access is checked first, + then Topic access. | +
| OFFSET_FETCH (9) | +Describe | +Topic | ++ |
| FIND_COORDINATOR (10) | +Describe | +Group | +The FIND_COORDINATOR request can be of "Group" type in which case it is looking for consumergroup + coordinators. This privilege would represent the Group mode. | +
| FIND_COORDINATOR (10) | +Describe | +TransactionalId | +This applies only on transactional producers and checked when a producer tries to find the transaction + coordinator. | +
| JOIN_GROUP (11) | +Read | +Group | ++ |
| HEARTBEAT (12) | +Read | +Group | ++ |
| LEAVE_GROUP (13) | +Read | +Group | ++ |
| SYNC_GROUP (14) | +Read | +Group | ++ |
| DESCRIBE_GROUPS (15) | +Describe | +Group | ++ |
| LIST_GROUPS (16) | +Describe | +Cluster | +When the broker checks to authorize a list_groups request it first checks for this cluster + level authorization. If none found then it proceeds to check the groups individually. This operation + doesn't return CLUSTER_AUTHORIZATION_FAILED. | +
| LIST_GROUPS (16) | +Describe | +Group | +If none of the groups are authorized, then just an empty response will be sent back instead + of an error. This operation doesn't return CLUSTER_AUTHORIZATION_FAILED. This is applicable from the + 2.1 release. | +
| SASL_HANDSHAKE (17) | ++ | + | The SASL handshake is part of the authentication process and therefore it's not possible to + apply any kind of authorization here. | +
| API_VERSIONS (18) | ++ | + | The API_VERSIONS request is part of the Kafka protocol handshake and happens on connection + and before any authentication. Therefore it's not possible to control this with authorization. | +
| CREATE_TOPICS (19) | +Create | +Cluster | +If there is no cluster level authorization then it won't return CLUSTER_AUTHORIZATION_FAILED but + fall back to use topic level, which is just below. That'll throw error if there is a problem. | +
| CREATE_TOPICS (19) | +Create | +Topic | +This is applicable from the 2.0 release. | +
| DELETE_TOPICS (20) | +Delete | +Topic | ++ |
| DELETE_RECORDS (21) | +Delete | +Topic | ++ |
| INIT_PRODUCER_ID (22) | +Write | +TransactionalId | ++ |
| INIT_PRODUCER_ID (22) | +IdempotentWrite | +Cluster | ++ |
| OFFSET_FOR_LEADER_EPOCH (23) | +ClusterAction | +Cluster | +If there is no cluster level privilege for this operation, then it'll check for topic level one. | +
| OFFSET_FOR_LEADER_EPOCH (23) | +Describe | +Topic | +This is applicable from the 2.1 release. | +
| ADD_PARTITIONS_TO_TXN (24) | +Write | +TransactionalId | +This API is only applicable to transactional requests. It first checks for the Write action on the + TransactionalId resource, then it checks the Topic in subject (below). | +
| ADD_PARTITIONS_TO_TXN (24) | +Write | +Topic | ++ |
| ADD_OFFSETS_TO_TXN (25) | +Write | +TransactionalId | +Similarly to ADD_PARTITIONS_TO_TXN this is only applicable to transactional request. It first checks + for Write action on the TransactionalId resource, then it checks whether it can Read on the given group + (below). | +
| ADD_OFFSETS_TO_TXN (25) | +Read | +Group | ++ |
| END_TXN (26) | +Write | +TransactionalId | ++ |
| WRITE_TXN_MARKERS (27) | +ClusterAction | +Cluster | ++ |
| TXN_OFFSET_COMMIT (28) | +Write | +TransactionalId | ++ |
| TXN_OFFSET_COMMIT (28) | +Read | +Group | ++ |
| TXN_OFFSET_COMMIT (28) | +Read | +Topic | ++ |
| DESCRIBE_ACLS (29) | +Describe | +Cluster | ++ |
| CREATE_ACLS (30) | +Alter | +Cluster | ++ |
| DELETE_ACLS (31) | +Alter | +Cluster | ++ |
| DESCRIBE_CONFIGS (32) | +DescribeConfigs | +Cluster | +If broker configs are requested, then the broker will check cluster level privileges. | +
| DESCRIBE_CONFIGS (32) | +DescribeConfigs | +Topic | +If topic configs are requested, then the broker will check topic level privileges. | +
| ALTER_CONFIGS (33) | +AlterConfigs | +Cluster | +If broker configs are altered, then the broker will check cluster level privileges. | +
| ALTER_CONFIGS (33) | +AlterConfigs | +Topic | +If topic configs are altered, then the broker will check topic level privileges. | +
| ALTER_REPLICA_LOG_DIRS (34) | +Alter | +Cluster | ++ |
| DESCRIBE_LOG_DIRS (35) | +Describe | +Cluster | +An empty response will be returned on authorization failure. | +
| SASL_AUTHENTICATE (36) | ++ | + | SASL_AUTHENTICATE is part of the authentication process and therefore it's not possible to + apply any kind of authorization here. | +
| CREATE_PARTITIONS (37) | +Alter | +Topic | ++ |
| CREATE_DELEGATION_TOKEN (38) | ++ | + | Creating delegation tokens has special rules, for this please see the + Authentication using Delegation Tokens section. | +
| RENEW_DELEGATION_TOKEN (39) | ++ | + | Renewing delegation tokens has special rules, for this please see the + Authentication using Delegation Tokens section. | +
| EXPIRE_DELEGATION_TOKEN (40) | ++ | + | Expiring delegation tokens has special rules, for this please see the + Authentication using Delegation Tokens section. | +
| DESCRIBE_DELEGATION_TOKEN (41) | +Describe | +DelegationToken | +Describing delegation tokens has special rules, for this please see the + Authentication using Delegation Tokens section. | +
| DELETE_GROUPS (42) | +Delete | +Group | ++ |