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

User Permission to Create Views #130

Open
maximann opened this issue Feb 5, 2019 · 3 comments
Open

User Permission to Create Views #130

maximann opened this issue Feb 5, 2019 · 3 comments

Comments

@maximann
Copy link

maximann commented Feb 5, 2019

First of all, great project. I just deployed it with a custom Apache Avro deserializer and everything works like a charm.

For my setup, I would like a little more flexibility in terms of user permissions. I do not want users to be able to modify topic settings, but I do want to give the ability to create views. This in effectively means I can not share admin access (since that gives too much power over cluster/topic configuration), but giving user permissions is not enough (since admins would have to create views for users). Is this something that could be changed easily? Happy to help with a PR if you send me some pointers.

@Crim
Copy link
Collaborator

Crim commented Feb 7, 2019

Glad to hear its working! 👍

In regards to the user permissions, I definitely see the value in more granular user permissions. I think a couple high level decisions need to be made first:

  • Can a user belong to only one group? Or multiple groups?
  • Do you assign permissions to feature sets? or can you also assign permissions to specific assets?
    • Basically the difference between being able to access all created Views, vs only specific Views allowed by your user's Group?

I'd probably argue to keep it simple, and only allow assigning permissions to groups based on feature set.

Thoughts?

@maximann
Copy link
Author

maximann commented Feb 7, 2019

I think a big question to answer: Should the project strive to enable multi-tenant solutions? More precisely, should users be isolated from each other, and only admins be able to have a global view? This could get complicated quickly, as true multi-tenant solutions can have a hierarchy of permissions, i.e. a global admin, an admin for a group of user-groups, and finally a group member. If yes, then I think resource level permissions are required as well as multi group membership. If no, things are much simpler.

I agree with you that it's probably better to keep things simple and begin with the ability to map feature access to user groups. Possibly a new view to manage groups (CRUD) and assign feature access on a per-group basis.

@Crim
Copy link
Collaborator

Crim commented Feb 14, 2019

Hmm, I never really gave the thought of using it in a multi-tenant type situation, I wonder how common that use case would be, or if any other solutions exist that fill that need yet.

Even so, I think keeping it simple to start is good, and what you've outlined seems spot on.

If you're interested in contributing, I definitely welcome it! Let me know how I can help you get started :)

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

No branches or pull requests

2 participants