Emitting events about certain operations inside kani

[tumbl3w33d]

Is your feature request related to a problem? Please describe.

There is one clear use case we talked about in the chat that I will try to summarize here, but I guess it should be handled in a more generic way so the consumer of this feature could decide which events are relevant.

When accounts get removed from Kani (e.g., someone is leaving the company) it usually takes more actions in the connected apps to cleanup and it's very individual per app. Some allow anonymizing the user, others allow full deletion, etc. Either way, you need to create some glue code to do things, but this logic needs to be triggered by some kind of notification and Kani knows best what's happening.

Describe the solution you'd like

At first I thought I put a script next to Kani and expect Kani to run it when certain things happen. That's not fancy enough though and you might have good reasons why the kani host shall not be the source of these actions.

Next idea was the usual configurable webhook, so Kani would send out http requests when things happen. But that would require the target to be reachable by Kani.

Then I thought it might make more sense to publish events to a kind of audit queue to which interested logic can subscribe. I'm just not sure how troublesome the authorization for accessing this information would be.

Describe alternatives you've considered

You could poll the Kani API and track the state between calls to act when things happen.

Additional context

N/A

[yaleman]

This could really tie into #2185 or #22 where audit event logging needs to clearly state the changes - something like an OCSF account change record which you could trigger off.

I wouldn't suggest (or approve) allowing Kanidm to run scripts/programs, that turns into a nightmarish security issue with serialising data and avoiding injection attacks, but a webhook might be doable.

Realistically, collecting logs and taking actions off that is probably the best way, but I'm coloured by working in environments (including my homelab 😄) that have that as part of the base design.

[Firstyear]

Yeah I don't want kani to call out to anything else like this. I'd rather have it go into the event/audit logging capability and then that can poke something else like mqtt or similar.

The issue with log collection @yaleman is ... you guessed it, replication. If you delete an account on one node, when you replicate the delete that shows up differently on the other node. So depending on your log collector, you may miss events. But we'd need to account for this in replication that if we had a node handle the event generation as a single node role then it would read the event and propogate that as needed.

That immediately makes it obvious that this has to be a plugin that can detect events as we go, since they have hooks into replication as well to detect when entries change state or update.

So realistically the thing to nail down then is what events we want to audit, how, and how to publish them.

For example some events like credential updates probably need a special data type on the entry to allow a user to see and review them, and the presence of these events can trigger the plugin.

But something like a delete just needs to check for the live -> recycled transition without special data.

[tumbl3w33d]

One downside about webhooks that I forgot is that you might miss events when the target is unreachable in that moment.

[Firstyear]

One downside about webhooks that I forgot is that you might miss events when the target is unreachable in that moment.

That's why part of my thinking is to catch the events and then record them to an internal audit queue so that we get guaranteed transmission.

[yaleman]

One downside about webhooks that I forgot is that you might miss events when the target is unreachable in that moment.

A lot of these kinds of implementations have a retry functionality etc

[yaleman]

The issue with log collection @yaleman is ... you guessed it, replication. If you delete an account on one node, when you replicate the delete that shows up differently on the other node. So depending on your log collector, you may miss events.

TBH, if you're running multiple nodes and not centralising the logs for this kind of workflow... sigh.