Skip to content
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

Closed
leosilvadev opened this issue Jul 7, 2021 · 6 comments · Fixed by #336
Closed

Defining ACL's for Kafka tools #300

leosilvadev opened this issue Jul 7, 2021 · 6 comments · Fixed by #336
Labels
enhancement New feature or request

Comments

@leosilvadev
Copy link

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

@leosilvadev leosilvadev added the enhancement New feature or request label Jul 7, 2021
@leosilvadev
Copy link
Author

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

@leosilvadev
Copy link
Author

BTW, I am also available to work on that in case this is someone you agree with

@purbon
Copy link
Collaborator

purbon commented Sep 11, 2021

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:

  • A kind of plugin mechanism where people can register new "roles"
  • these roles would then be available for users within the topology descriptor, same like consumers, connectors, etc...

does this makes sense to you?

@leosilvadev
Copy link
Author

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.
I will think about it during this week and will write here again so we can detail that better, wdyt?

@purbon
Copy link
Collaborator

purbon commented Sep 19, 2021

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?

@purbon
Copy link
Collaborator

purbon commented Sep 24, 2021

@leosilvadev I spend some time and add #336, happy if you take a look and give your feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants