SSSD / sssd

#3685 KCM: Default to a new back end that would write to the secrets database directly
Closed: Fixed Opened by jhrozek.

Closed: Fixed
Reopen Issue

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.

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.

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

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.
  • master:
    fcbedf46fcfc66f443afa3171036b4bc7bbd380b
    f74feb08b86e72eb3e098ed097d0574f815f6de3
    7dd1991c93a8c0ac5c887573a1be18523a861522
    f91adcc8eb58294d0a69b5ce938d959f059a8a84
    24ba2120697d95139ba6c0107608f31196532097
    0b9001e3a8c820f137cbe07f853317474dac53ac
    e0bf64a736dc0fa244dc8023970ed4e65b4d7f31
    fdfa36ae07dfc9bb7488d8dcde1e37ff95aeb3be
    24b151e076313441518692a6afe7d3ec50e8c02f
    ca73eedba23f4746d57161f185a5da5e1c5b6b7c
    80811f941160e481112adc6933f59e3d2e5c5c85
    0294bcf7cdf21fe6702423f77554a880699c85bc
    aafaacd59d3ce935c4ca0a73a140f1e6f4cd49b0
    4d7f07893fb3bcf9c39ec0ff318c73529f7f8278

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4704

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None

KCM RFE

None
None
Lowest
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.