keytabmux

[Troels Arvin]

Hello,

SSSD is a great way to maintain server's joined relation to an active 
directory, for example. In combination with msktutil, one may manage 
SPNs in an elegant way, forming the basis of single-signe-on into (e.g.) 
Postgres.

However, there doesn't seem to be a good way to maintain derived keytabs 
from the system's main /etc/krb5.keytab. A use case I have is that I 
need the 'postgres/' keytab entries from a server's main krb5.keytab to 
be available for the server's Postgres database as 
/etc/postgresql-common/krb5.conf with special permissions. (Have I 
overlooked a good, existing solution for it?)

So I've written a little utility to help with this: "keytabmux": 
https://gitlab.com/troelsarvin/keytabmux

The tool may be started by systemd, and it will then keep running, 
keeping an eye on updates of /etc/krb5.keytab and write new derived 
keytabs, as needed.

Maybe someone here will find it interesting. Let me know, if you have 
comments.

[James Ralston]

On Sat, Jan 18, 2025 at 6:51 PM Troels Arvin via sssd-users
 wrote:
> SSSD is a great way to maintain server's joined relation to an
> active directory, for example. In combination with msktutil, one may
> manage SPNs in an elegant way, forming the basis of single-signe-on
> into (e.g.)  Postgres.
>
> However, there doesn't seem to be a good way to maintain derived
> keytabs from the system's main /etc/krb5.keytab. A use case I have
> is that I need the 'postgres/' keytab entries from a server's main
> krb5.keytab to be available for the server's Postgres database as
> /etc/postgresql-common/krb5.conf with special permissions. (Have I
> overlooked a good, existing solution for it?)

A better way would be to use gssproxy(8), which is designed exactly
for this use case.  If postgresql uses the GSSAPI libraries for
Kerberos, it should work.  And at least for Fedora and RHEL
derivatives, that appears to be the case:

$ objdump -x /usr/bin/postgres | grep NEEDED | grep gssapi
  NEEDED               libgssapi_krb5.so.2

So, for /etc/gssproxy/50-postgresql.conf:

[service/postgresql]
    mechs = krb5
    cred_store = keytab:/etc/krb5.keytab
    euid = postgres

And for /etc/systemd/system/postgresql.service.d/use-gss-proxy.conf:

[Service]
Environment=GSS_USE_PROXY=1

For more information about gssproxy, see:

https://github.com/gssapi/gssproxy/tree/main/docs

Note that some of the GitHub documentation above is outdated.  For
example, the systemd ".include" directive is deprecated; using drop-in
files in the /etc/systemd/system/SERVICENAME.service.d/ directory (as
per my example above) is now preferred.

[Troels Arvin]

Hello,

On 2025-01-21, James Ralston wrote:
> A better way would be to use gssproxy(8)

Yes, but I could not get that to work: 
https://lists.fedorahosted.org/archives/list/[e-mail]...

I had tested on Debian 12 with the package from 
https://apt.postgresql.org/pub/repos/apt

I have now tested with Fedora 41, and there, I can get Postgres to work 
with gssproxy.

[Troels Arvin]

Hello again,

Earlier today, I wrote:
> Yes, but I could not get that to work: 
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>
> I had tested on Debian 12 with the package from 
> https://apt.postgresql.org/pub/repos/apt
>
> I have now tested with Fedora 41, and there, I can get Postgres to 
> work with gssproxy.

I have now gotten it to work with the PGDG Postgres packages on Debian.

It turned out with the PGDG packages on Debian, the GSS_USE_PROXY=yes 
(or GSS_USE_PROXY=1) environment variable should be set in 
/etc/postgresql/17/main/environment

Setting it in a systemd override did not work. (And that's actually OK: 
In my opinion, systemd overrides should be used as little as possible.)

[Ethel Andino]

Appreciate the helpful tip on setting up PGDG Postgres on Debian. For sure, adding GSS_USE_PROXY in /etc/postgresql/17/main/environment is way better than messing with a systemd override