Changes/KerberosKCMCache

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

• Targeted release: Fedora 26
• Last updated: 2017-03-17
• Tracker bug: #1421604

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 krb5-libs package will then switch its default from KEYRING to KCM. The libkrb5 package will require the sssd-kcm subpackage and enable its socket so that the KCM server is socket activated when needed. Please note that the KCM server only listens on a local UNIX socket, not over the network.

• 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 ccache name and type are selected with an option in the krb5.conf file, which is typically not overwritten during an upgrade, this change will not affect upgrades from previous versions of Fedora. Users who upgrade their Fedora can opt-in by changing a line in the krb5.conf file.

How To Test

When the sssd-kcm package is added to Fedora, but before the defaults are switched, or when testing on an upgraded system, the user has to manually select the KCM credential cache type in krb5.conf:

  [libdefaults]
  default_ccache_name = KCM:

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

As desribed above, the krb5-libs defaults have to be changed. No other packages except SSSD and krb5-libs are affected by this change

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.