RBAC: Unclear required access level for the audit topic

[Ilyin-V-V]

Issue submitter TODO list

• I've looked up my issue in FAQ
• I've searched for an already existing issues here
• I've tried running main-labeled docker image and the issue still persists there
• I'm running a supported version of the application which is listed here

Describe the bug (actual behavior)

Lack of access to _kui_audit_log topic messages when configuring LDAP, RBAC.
If you disable RBAC, then access to messages is available, what could be the reason for this behavior?

Expected behavior

Reading messages in the _kui_audit_log topic using kui even if RBAC is enabled

Your installation details

auth:
type: LDAP

spring:
jmx:
enabled: true

ldap:
urls: ldap://ms.it.domain.com:389
base:
admin-user:
admin-password:
user-filter-search-base: DC=it,DC=domain,DC=com
user-filter-search-filter: (&(uid={0})(objectClass=inetOrgPerson))
group-filter-search-base: ou=Groups,DC=it,DC=domain,DC=com

kafka:
clusters:
-
name: Kafka-cluster-1
bootstrapServers: kafka1.com,kafka2.com,kafka3.com
ssl:
truststorelocation: /truststore.jks
truststorepassword:
properties:
security:
protocol: SASL_SSL
sasl:
mechanism: PLAIN
jaas:
config: org.apache.kafka.common.security.plain.PlainLoginModule required username="" password="";

  audit:
    topicAuditEnabled: true
    consoleAuditEnabled: true
    topic: "__kui-audit-log" # default name
    auditTopicProperties: # any kafka topic properties in format of a map
      retention.ms: 43200000
    auditTopicsPartitions: 1 # how many partitions, default is 1
    level: ALTER_ONLY # either ALL or ALTER_ONLY (default). ALL will log all read operations.**

rbac:
roles:
- name: "admins"
clusters:
- Kafka-cluster-1
subjects:
- provider: ldap
type: group
value: "MS"

  permissions:
    - resource: applicationconfig
      actions: all

    - resource: clusterconfig
      actions: all

    - resource: topic
      value: ".*"
      actions: all

    - resource: consumer
      value: ".*"
      actions: all

    - resource: acl
      value: ".*"
      actions: all

    - resource: schema
      value: ".*"
      actions: all

    - resource: connect
      value: ".*"
      actions: all

    - resource: ksql
      value: ".*"
      actions: all

Steps to reproduce

Enable LDAP, enable RBAC

Screenshots

No response

Logs

, String, String, Long, Long, String, String, String, ServerWebExchange)
2024-06-27 15:35:40,259 DEBUG [reactor-http-epoll-4] o.s.w.s.a.HttpWebHandlerAdapter: [ea53e5a8-59] Completed 403 FORBIDDEN
2024-06-27 15:35:41,638 DEBUG [reactor-http-epoll-4] o.s.w.s.a.HttpWebHandlerAdapter: [ea53e5a8-60] HTTP GET "/api/clusters/Kafka-cluster-1/topics/__kui-audit-log/messages/v2?limit=100&mode=LATEST"
2024-06-27 15:35:41,640 DEBUG [reactor-http-epoll-4] o.s.w.r.r.m.a.RequestMappingHandlerMapping: [ea53e5a8-60] Mapped to io.kafbat.ui.controller.MessagesController#getTopicMessagesV2(String, String, PollingModeDTO, List, Integer, String, String, Long, Long, String, String, String, ServerWebExchange)

Additional context

similar problem on https://github.com/provectus/kafka-ui, perhaps you need to explicitly set the access rules acl is disabled on kafka

[github-actions]

Hi Ilyin-V-V! 👋

Welcome, and thank you for opening your first issue in the repo!

Please wait for triaging by our maintainers.

As development is carried out in our spare time, you can support us by sponsoring our activities or even funding the development of specific issues.
Sponsorship link

If you plan to raise a PR for this issue, please take a look at our contributing guide.

[Haarolean]

_kui_audit_log is just a topic and has no special treatment from the perspective of RBAC. You have to add RBAC rules for that topic manually. Let me know if there's anything else we could help with.

[Ilyin-V-V]

And I think that _kui_audit_log is just a topic, but why then the rule:

• resource: topic
  value: ".*"
  actions: all
  results in Completed 403 FORBIDDEN. I also tried to write the rule explicitly:
• resource: topic
  value: ".*audit-log"
  actions: [view, messages_read]

but I still get 403 FORBIDDEN

[Haarolean]

Aah, sorry, there actually is a special treatment for the audit topic:
In order to be able to view its messages you have to add the following RBAC permission:

        - resource: audit
          actions: all

Please let me know if it works for you

[kapybro]

Further user feedback is requested. Please reply within 7 days or we might close the issue.

[Haarolean]

We'd need to update the docs:
https://github.com/kafbat/ui-docs/blob/main/configuration/audit-log.md
https://github.com/kafbat/ui-docs/blob/main/configuration/rbac-role-based-access-control/README.md

[Ilyin-V-V]

Ааа, извините, на самом деле для темы аудита существует особая обработка: чтобы иметь возможность просматривать ее сообщения, вам необходимо добавить следующее разрешение RBAC:

        - resource: audit
          actions: all

Пожалуйста, дайте мне знать, если это вам подходит.

It doesn't work for me, here is my RBAC:
rbac:
roles:

• name: "admins"
  clusters:
• Kafka-cluster-1
  subjects:
• provider: ldap
  type: group
  value: "MS"
  permissions:
• resource: topic
  value: ".*"
  actions: all
• resource: audit
  actions: all

And still, when reading from the UI topic __kui-audit-log in the logs - Completed 403 FORBIDDEN
Version kafbat-ui-v1.0.0.jar

[Haarolean]

This particular config works for me:

        - resource: topic
          value: "__kui-audit-log"
          actions: all

        - resource: audit
          actions: all

The question why we'd need both still remains, we'll take a look into this. For now, please add both the actions to your config, this should work.

[Ilyin-V-V]

Мне подходит вот эта конфигурация:

        - resource: topic
          value: "__kui-audit-log"
          actions: all

        - resource: audit
          actions: all

Вопрос, зачем нам оба нужны, все еще остается, мы разберемся в этом. А пока добавьте оба действия в свою конфигурацию, это должно работать.

thank you very much, it works

[Ansh7899]

is the issue resolved?

[Haarolean]

@Ansh7899 nope, feel free to tackle this! We should allow access to the audit topic via resource: audit permission without a need for resource: topic one.