kafka-ui
kafka-ui copied to clipboard
RBAC: Can't edit topic while having inherited edit permissions
Issue submitter TODO list
- [X] I've looked up my issue in FAQ
- [X] I've searched for an already existing issues here
- [X] I've tried running
main-labeled docker image and the issue still persists there - [X] I'm running a supported version of the application which is listed here
Describe the bug (actual behavior)
permissions:
- resource: applicationconfig
actions: [ "view" ]
- resource: clusterconfig
actions: [ "view" ]
- resource: topic
value: ".*"
actions: [ "view", "messages_read", "messages_delete" ]
don't block "edit" in UI (ghcr.io/kafbat/kafka-ui:v1.0.0) same config in provectuslabs/kafka-ui:v0.7.1 works properly
Expected behavior
No response
Your installation details
v1.0.0
Steps to reproduce
enable rbac and use such config:
roles.yml: |
rbac:
roles:
- name: "role-name-ro"
clusters:
- cluster-name
subjects:
- provider: oauth
type: role
value: "rolename-ro"
permissions:
- resource: applicationconfig
actions: [ "view" ]
- resource: clusterconfig
actions: [ "view" ]
- resource: topic
value: ".*"
actions: [ "view", "messages_read", "messages_delete" ]
Screenshots
Logs
No response
Additional context
No response
Hello there fallen-up! 👋
Thank you and congratulations 🎉 for opening your very first issue in this project! 💖
In case you want to claim this issue, please comment down below! We will try to get back to you as soon as we can. 👀
Might be a UI issue, can you confirm that editing the topic actually succeeds?
Further user feedback is requested. Please reply within 7 days or we might close the issue.
Thanks for the additional feedback! We'll get back to your issue soon.
@Haarolean edit menu opens, but yes, can't save - error 501
https://github.com/provectus/kafka-ui/blob/master/kafka-ui-react-app/src/components/Topics/Topic/Topic.tsx#L100 is similar to https://github.com/kafbat/kafka-ui/blob/main/frontend/src/components/Topics/Topic/Topic.tsx#L93
Not a frontend bug, permissions' inheritance implies that having edit permission virtually implies having 'delete messages' permission as well (as you can always do this some other way, like setting retention to 0, or sth else). The problem here, however, is that the backend doesn't treat this well despite basically having edit permission available. Need to investigate.