#3685 KCM: Default to a new back end that would write to the secrets database directly

Created 2 months ago by jhrozek
Modified 2 months ago

At the moment, KCM uses the sssd-secrets REST API to communicate with the SSSD secrets database. This has the advantage of using a clean public API and the advantage that the secret can be forwarded to a Custodia server and potentially shared, but at the same time the disadvantage that there are two daemons to synchronize, two set of debug logs to correlate. Also, we are /bound/ to the sssd-secrets REST API, which might prevent us from doing things like quota reporting easily.

Therefore, this ticket proposes adding a new sssd-secrets back end that would write directly to the secrets database.

We should probably define some API that would be only private to SSSD to write to the secrets database. We should also expose the option that allows to choose the KCM back end. Since we have integration tests, we can just run them the same with just the back new back end changed, like we already do for the memory back end.

2 months ago

Metadata Update from @jhrozek:
- Issue tagged with: KCM

Ideally you use the same code sssd-secrets uses for KCM, sharing it completely.
KCM would basically just shortcircuit the kcm->secrets communication over sockets.
If you do that the API is common and no divergence will happen.

2 months ago

Metadata Update from @jhrozek:
- Issue priority set to: blocker (was: minor)
- Issue set to the milestone: SSSD 2.0

2 months ago

Metadata Update from @jhrozek:
- Issue tagged with: RFE

Another side-effect of this change might be that we might split the secrets responder into a lib and the responder itself to avoid the dependency on http-parser and libjansson. Considering that Fedora ships KCM in its default installation, reducing dependencies is something we should do.

Login to comment on this ticket.

cancel