Kerberos KCM credential cache by default
Summary
Default to a new Kerberos credential cache type called KCM which is better suited for containerized environments and provides a better user experience in the general case as well.
Owner
- Name: Jakub Hrozek
- Email: <jhrozek@redhat.com>
- Release notes owner:
Current status
Detailed Description
Over time, Fedora used different credential cache types to store Kerberos credentials - going from a simple file-based storage (FILE:) to a directory (DIR:) and most recently a kernel-keyring based cache (KEYRING:).
Each of these caches has its own set of advantages and disadvantages. The FILE ccache is very widely supported, but does not allow multiple primary caches in a collection. The DIR cache does, but creating and managing the directories including proper access control can be tricky. The KEYRING cache is not well suited for cases where multiple semi-isolated environments might share the same kernel. Managing credential caches' life cycle is not well solved in neither of these cache types automatically, only with the help of a daemon like SSSD.
The scope of this change is to introduce a new Kerberos credential cache type called KCM and switch to using it by default.
With KCM, the Kerberos caches are not stored in a "passive" store, but managed by a daemon. In this setup, the Kerberos library (typically used through an application, like for example, kinit) is a "KCM client" and the daemon is being referred to as a "KCM server". The KCM server will be provided as a socket-activated service of the SSSD deamon.
Benefit to Fedora
Having the Kerberos credential caches managed by a daemon has several advantages:
- The daemon is stateful and can perform tasks like Kerberos credential cache renewals or reaping old ccaches without user intervention. Some of these, like renewals are possible already with SSSD, but only for tickets that SSSD itself acquired (typically via a login through pam_sss.so) and tracks. Tickets acquired otherwise, most notably though kinit wouldn't be tracked and renewed.
- Since the process runs in userspace, it is subject to UID namespacing, unlike the kernel keyring
- Unlike the kernel keyring-based cache, which is entirely dependant on UIDs of the caller and in a containerized environment is shared between all containers, the KCM server's entry point is a UNIX socket which can be bind-mounted to only some containers or a separate KCM server instance can be shared between containers
- The protocol between the client and the server can be extended for custom operations such as dumping a cache in a different format to a specific location. This would be beneficial for applications that only understand a certain Kerberos ccache type - for example, some legacy applications only know how to deal with a FILE-based cache, thus preventing the use of cache collections
Only the Heimdal Kerberos implementation currently implements a KCM server, but both Heimdal and MIT implement the client-side operations (in libkrb5) to manage KCM-based Kerberos ccaches. As a part of this change, a KCM server will be added to SSSD. While it's of course possible to create a completely standalone daemon that would implement a KCM server, doing so in the context of SSSD has several advantages, notably:
- An easy access to the authentication provider of SSSD that already has existing and tested code to renew Kerberos credentials on user's behalf
- SSSD already has a D-Bus API that could publish information about Kerberos tickets and for example emit signals when a user's credential cache changes that a graphical application can consume
- SSSD has a 'secrets provider' to store data at rest. It makes sense to leverage this component to store Kerberos ccaches persistently so that the ccaches survive a reboot or KCM server restart
Scope
- Proposal owners: SSSD developers will implement a KCM server. The deamon along with a krb5.conf snippet will be packaged in a subpackage called
sssd-krb5. The interested variants of Fedora that would wish to opt in would add thesssd-krb5subpackage to their compose.
- Other developers: None required
- Release engineering: None required
- List of deliverables: None affected
- Policies and guidelines: None required
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
Since the default would be delivered through a snippet coming from a new subpackage, there is no effect to users who upgrade. Those upgrading from a previous version who would like to opt in can simply choose to 'dnf install sssd-krb5'.
How To Test
When the sssd-kcm package is installed, a file called /etc/krb5.conf.d/kcm_default_ccache would contain:
[libdefaults] default_ccache_name = KCM:
The sssd-kcm socket would also be enabled.
Users should not see any regressions in functionality - the workflow with kinit, klist or any Kerberos-enabled applications should work exactly how it used to. Therefore testing the usual workflows and existing applications should be sufficient to detect regressions.
If the Kerberos ticket that was acquired is renewable, SSSD would renew the ticket automatically.
Use-cases for environments that benefit the most from the change, such as containerized environments are described on the SSSD design page in detail, including steps how to test them.
User Experience
Renewable Kerberos tickets will be renewed automatically. Unlike the KEYRING Kerberos ccache, the ccaches will survive a reboot.
Dependencies
No dependencies.
Contingency Plan
- Contingency mechanism: If the feature is not ready, we revert the changes to krb5-libs and let the user opt-in to the KCM cache, thus changing the Change scope to Self-Contained.
- Contingency deadline: By the beta
- Blocks release? No
- Blocks product? No
Documentation
The design is described in more detail on the SSSD wiki.