[feature] option to disable viewing messages in UI

[akamensky]

Is your proposal related to a problem?

Some of our data has restricted access. Currently this tool will allow anyone to browse this data.

Describe the solution you'd like

A startup configuration parameter to entirely disable viewing messages in UI.

Describe alternatives you've considered

N/A

Additional context

N/A

[akamensky]

I think ideal option would be to have:

• Authentication to UI and groups management
• Group permissions management
• Ability to allow certain group(s) to see messages

But this would make the changeset very large and touch too many parts. So to keep it simple I think ability to just disable reading messages is sufficient for this use case.

[Haarolean]

Hi Alexey, I understand the concern. The ideal implementation of this is #753, but as you mentioned this is a huge task. We'll try to implement the minimal one you're requesting earlier (0.4, or, if we'll have some free time, in 0.3).

[akamensky]

@Haarolean thank you for pointing to that issue. If I may ask here, are there possible plans to include external authentication mechanisms? Or possibly provide plugin interface in this area?

[Haarolean]

We’ll have to support some for sure. Which are you personally interested in?

On 29 Oct 2021, at 15:45, Alexey Kamenskiy @.***> wrote:

 @Haarolean thank you for pointing to that issue. If I may ask here, are there possible plans to include external authentication mechanisms? Or possibly provide plugin interface in this area?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[akamensky]

From my side I would be interested in AD/LDAP as that is what we currently use for centralized AAA service. I believe there would be fairly high demand for those methods outside of my company too.

[Haarolean]

That’s what I have been thinking of as well.

On 29 Oct 2021, at 16:02, Alexey Kamenskiy @.***> wrote:

 From my side I would be interested in AD/LDAP as that is what we currently use for centralized AAA service. I believe there would be fairly high demand for those methods outside of my company too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[NitinAgg]

Any update on this. Generally there are env flag based implementation to disable any existing feature. This is a huge blocker for us

[Haarolean]

Any update on this. Generally there are env flag based implementation to disable any existing feature. This is a huge blocker for us

this won't be released before #753 for sure, but it might be a part of it. Meanwhile, you can try out this image: public.ecr.aws/provectus/kafka-ui-custom-build:2517, it's based on latest master. I've disabled producing, consuming and deleting messages on backend and removed messages tab on frontend.

[akamensky]

@Haarolean since 0.5 released (sadly only with oauth), what is possible ETA on this then (I see it was removed from 0.5 milestone). We need to make sure we can disable the entire feature of "messages" on our system. Users are trying to live-tail topics with ~2mm msgs/s which causes all sort of issues (even after we asked them not to use this feature).

[Haarolean]

@akamensky hey. We're planning to implement at least support for ldap/ad and keyclock for RBAC within 0.6 (1 month eta). What do you personally use, wouldn't these options be enough? Aaaalso, we've recently implemented per-cluster polling rate limits. Isn't it enough to fix your issues with live tailing? Please try it out and let me know. KAFKA_CLUSTERS_0_POLLING_THROTTLE_RATE - Max traffic rate (bytes/sec) that kafka-ui allowed to reach when polling messages from the cluster. Default: 0 (not limited)

[akamensky]

Thanks for the feedback @Haarolean please see below:

We're planning to implement at least support for ldap/ad and keyclock for RBAC within 0.6 (1 month eta). What do you personally use, wouldn't these options be enough?

That's great to hear. We only use AD/LDAP here. But that's a separate matter as this ticket is more about users being able to read/tail messages. I guess you mean here that it is somehow part of RBAC, but we cannot test this until it actually supports AD/LDAP, so I will defer until then.

we've recently implemented per-cluster polling rate limits. Isn't it enough to fix your issues with live tailing? Please try it out and let me know.

We can try this option. However with reading messages we have 2 issues:

1. The remote site with small bandwidth link that get saturated by requests from UI to Kafka cluster (which very well may be resolved by this throttling option above, so we will need to try it first)

2. The fact that some of data should not be available to user to read at all (security concern). I revert to original (top message) intent of this ticket here. I reckon separating topics into allowed/disallowed for reading is much more complex than disabling access to "Messages" tab altogether. I am not sure how RBAC would be implemented here. From our side ideally we would want to allow a small group of users (i.e. security admins) to be able to check messages in topic, while everyone else should not be able to. But if that is not in scope of current RBAC plans -- just an option to completely disable reading messages via UI would be awesome.

[Haarolean]

@akamensky

But that's a separate matter as this ticket is more about users being able to read/tail message I reckon separating topics into allowed/disallowed for reading

It's already doable via RBAC, you can disable viewing them altogether.

        - resource: topic
          value: "mytopicregex.*"
          actions:
            - VIEW
#            - MESSAGES_READ
            - MESSAGES_PRODUCE
            - MESSAGES_DELETE

Also, see data masking, which might be useful for you.

I'll present LDAP & AD support for RBAC soon, stay tuned :)

[Haarolean]

Closing as it's been implemented within RBAC (#753).