-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defining ACL's for Kafka tools #300
Comments
We could also add specific configuration for each tool, like it is done for schema-registry, control-center, etc, but having a more flexible sounds good to me since it does not block to use/try any new OSS tool that may appear |
BTW, I am also available to work on that in case this is someone you agree with |
Hi @leosilvadev , sorry for the long delay of answering here. Doing my best between family, work and pandemic ;-) I kinda see this feature, something like a possibility to plug-in new components in the topology descriptor. One of the core features of JulieOps is the possibility to give abstractions so users of the tool does not have to worry about low level details. So in summary, yes I like this idea. I would kinda see something in this direction:
does this makes sense to you? |
Hello @purbon thanks for the answer! That is fine, I understand, also trying to manage everything here (with two kids) + this never-ending-pandemic. It sounds good to me! In fact, for the time being, I have worked on some temporary things on my fork, adding some topic validation for retention period to help us here with GDPR + added a simple (but very specific way) to configure a tool we use here, AKHQ. But anyway, I prefer this more generic approach and would be happy to work on that. |
please, feel free. I might (if I ever get time to get time) as well give it a try. I am nowadays thinking on having something like: ---
roles:
rules:
- name: "security"
acls:
- resourceType: "Topic"
resourceName: "{{topic}}"
patternType: ""
host: ""
operation: ""
permissionType: ""
- resourceType: "Group"
resourceName: "{{group}}"
patternType: ""
host: ""
operation: ""
permissionType: ""
- name: "other"
acls:
- resourceType: "Topic"
resourceName: ""
patternType: ""
host: ""
operation: ""
permissionType: ""
- resourceType: "Group"
resourceName: ""
patternType: ""
host: ""
operation: ""
permissionType: "" note to be completed. In order to create a definition of the roles, this could include as well the ones that are "hard wired" these days in java. Load this file, allow for extension via configs and use it when the topology detects one of these definitions. We could use as well variables in this system as per jinja notation and pass each of the values, so we could define templates end of the day. What do you think? |
@leosilvadev I spend some time and add #336, happy if you take a look and give your feedback. |
Is your feature request related to a problem? Please describe.
Currently ACL's may just be defined for producers, consumers, connectors and streams, but we ideally want to give permissions to tools like AKHQ, where it need access to many topics, consumer groups, etc, from what I saw now this cannot be easily set (I am defining it as streams since I can define explicitly the topics I want to give permission to.
Describe the solution you'd like
Have the possibility to have more flexible way to define acl's, being inside or outside a project, simply defining the user + the topics it can access
The text was updated successfully, but these errors were encountered: