Self-service user provisioning and permission grants

[arov00]

Correct me if I'm wrong, but it seems that currently the only way to grant ACLs to a user, is by specifying the ACLs in the relevant KafkaUser resource. This seems a bit problematic, as this essentially means that if I am allowed to create a KafkaUser, then I am also allowed to give my user all kinds of permissions. If my team "owns" a topic, I wouldn't want other teams to grant themselves permissions to read/write from it without our approval. So I was curious how this is handled in Organizations with more than one team? The way I see it, there are 3 options:

1. Do not allow developers to create kafka users. All user and ACLs creations must be requested from the platform team. This would make the process unnecessarily bureaucratic even for applications that do not require any of the other teams' topics.
2. Allow developers to create kafka users. This would eliminate all bureaucracy around permission requests, but also turn our Kafka platform into a bit of a Wild West 🤠
3. Do not allow developers to create kafka users. The platform team must provide some kind of self-service tool for user provisioning and ACL requesting that creates/modifies KafkaUser objects as new permissions are approved.

I don't really have a solution for this, but it seems like option 3. could be made easier if KafkaUser and ACL definitions were kept separately (e.g. something akin to K8s service accounts which are granted permissions using RoleBinding objects).

[scholzj]

Correct me if I'm wrong, but it seems that currently the only way to grant ACLs to a user, is by specifying the ACLs in the relevant KafkaUser resource. This seems a bit problematic, as this essentially means that if I am allowed to create a KafkaUser, then I am also allowed to give my user all kinds of permissions. If my team "owns" a topic, I wouldn't want other teams to grant themselves permissions to read/write from it without our approval.

This is basically a correct observation. That said, you can also disable the User Operator completely and manage your users and their rights anyway you want using the Kafka Admin API.

So I was curious how this is handled in Organizations with more than one team?

I think all the 3 options you mentioned are used very often. In the 1st and 3rd options, GitOps pattern and GitHub are often used as the approval mechanism.

I guess I agree that the idea to couple the ACLs and the users is not always the best and often requires additional tooling to control how they are configured. That said, separate resources for ACLs or managing ACLs as part of the topic have their own challenges as well. For example, they are quite fragile as they rely on the username being defined separately from the ACLs etc. I spent a lot of time thinking about how to improve what you describe here. But so far I did not really come up with anything that I would not seem to just trade one set of problems for another. 😞

[arov00]

Thanks for your reply. I've spend some time thinking about a solution that would work for us and feel like it would be natural to tie permissions to the entity that is going to be accessed, rather than the user that will do the "accessing". We ended up defining a simple custom resource:

kind: KafkaDomain
apiVersion: spoud.io/v1alpha1
metadata:
  name: example-domain
spec:
  # Prefix that the ACLs will target
  domainName: org.division
  # Just some metadata on who to talk to if you want to access this domain
  adminEmails:
  - [email protected]
  # Sub-KafkaDomain objects possibly owned by other teams. By specifying them here, we delegate to them
  # the ability to grant permissions to those prefixes
  subdomains:
  - org.division.accounting
  - org.division.metrics
  acls:
    topic:
      # KafkaUser -> permitted operations
      user1: ["Read", "Write"]
      user2: ["Read"]
    group: { ... }

Our proof-of-concept operator collects all KafkaDomains and patches the KafkaUser resources (which we store in a namespace that a normal user cannot access) such that their ACLs reflect the permissions defined in the KafkaDomains.

For example, they are quite fragile as they rely on the username being defined separately from the ACLs etc.

If a user does not exist (e.g. due to a typo), one could add a warning to the status of the resource which defines the permissions. I feel like it would be nice to have the option to have better separation of permission requestor and approver. If there is interest in this solution, we could release the source code for our PoC.

[scholzj]

If a user does not exist (e.g. due to a typo), one could add a warning to the status of the resource which defines the permissions.

Warning is nice, but it does not help much if you have an application failing with denied access.

[arov00]

But the application failing with denied access is the desired behavior if your application's user has no permissions. As developer I should approach the relevant people within the organization and ask for these permissions. If the people come back to me and tell me "we gave you permissions", but my application is still failing with the same error, then my answer is "no, you did not". The permission-giver could then do k describe KafkaDomain example-domain and see in the warning that they messed up the user name.

I don't think it is possible to design a solution that is 100% proof against human error. The current KafkaUser solution also has potential for these kinds of mistakes. I could define a prefix ACL rule, but miss-type the prefix and my application would fail with denied access. I wouldn't even get a warning in this case, because the operator likely has no way of knowing that when I typed foo.ar I actually meant foo.bar.