Request to improve logging so that SASL Authentication Failure log entries make it easier to diagnose which SASL Authentication Resource the principal needs

Version & Environment

Redpanda version: (use rpk version): v22.2.6 (rev 6814dda)

Please also give versions of other components:

Operating System (e.g. from /etc/os-release): ubuntu 20.04 LTS focal (amd64)
Any Kafka client libraries in use (e.g. rdkafka, franz-go): None for this issue
Docker (use docker info): N/A
Kubernetes (use kubectl version): N/A Virtualized on a VM using VMWare ESXi

What went wrong?

The logs which are emitted when a SASL authorization fails do not indicate what resource was not being permitted by the ACL - Makes it very difficult to diagnose what resource the principal needs.

For example this is the log which was emitted when my redpanda broker receives a invalid authorization request from one of the principals being used inside the Materialized binary (https://materialized.io)

Feb 28 22:16:18 <REDACTED_HOSTNAME> rpk[1033]: INFO  2024-02-28 22:16:18,871 [shard 2] kafka - <REDACTED_IP>:<REDACTED_PORT> failed authorization - connection_context.h:163 - proto: kafka rpc protocol, sasl state: complete, acl op: describe, principal: {type user name materialize-consumer}, resource: {materialize-cc1c680a-434d-4bac-a33f-f8b1162e8c3b-kafka-u10/4507}

from the above log I understand there is some permission missing in my ACL (on the destination my service seems to be running fine, however, on the broker I am getting the message) based on the resource field what DESCRIBE is the principal looking for? Is it a topic, transactional.id, group? currently the materialize-consumer has permissions which are given by the following ACL command:

sudo rpk acl create --allow-principal 'User:materialize-consumer' \
--resource-pattern-type 'prefixed' \
--operation read,describe --topic schema \
--operation read,describe --topic dbzm \
--operation read,describe --topic dbhistory \
--operation read,describe,delete --group grp_materialize \
--operation read,describe,write --transactional-id txn-id_materialize \
--user <redpanda-admin-account> --password <redpanda-admin-password> \
--sasl-mechanism SCRAM-SHA-256 --brokers <redpanda-leader-broker> \
--tls-enabled

Now, In order to fix this issue I had to iteratively add different permissions on every different type of resource in the above prefixed version of the rpk acl create command. finally, adding the the following line to my above command stopped the generation of log entries

## --Rest of the sudo rpk acl create command
--operation all --group materialize

which indicated that the missing permission was on the Consumer-Group resource type. (Unfortunately, in the materialize docs there is precious little information on what permissions the kafka/redpanda user account needs - so an alternative is to iteratively add more permissions as and when these log entries arise)

What should have happened instead?

A little bit of more information about the missing resource type would be helpful - adding the resource type into the log would have helped (e.g. resource: {group materialize-cc[...]}) figure it a lot faster.

How to reproduce the issue?

Have a missing permission on a resource for a principal
access that resource using the principal - the log entry created does not have the missing resource name.

Additional information

N/A

JIRA Link: CORE-1847

redpanda-data / redpanda