krb_server_keyfile

Definition PG 18 manual

Sets the location of the server's Kerberos key file. The default is FILE:/usr/local/pgsql/etc/krb5.keytab (where the directory part is whatever was specified as sysconfdir at build time; use pg_config --sysconfdir to determine that). If this parameter is set to an empty string, it is ignored and a system-dependent default is used. This parameter can only be set in the postgresql.conf file or on the server command line. See Section 20.6 for more information.

How it works

krb_server_keyfile sets the location of the Kerberos server key file. The file contains service keys used by GSSAPI authentication; operating-system ownership and keytab rotation are part of the effective configuration.

krb_server_keyfile is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

The final authentication path combines this setting with pg_hba.conf, role attributes, credential material, client capabilities, and sometimes operating-system identity services.

Operational considerations

Editing krb_server_keyfile without reloading configuration and verifying the effective value and subsequent behavior.

Changing one authentication setting without testing pg_hba.conf ordering, existing secrets, mappings, and every client library.

Weakening identity policy to solve connection churn or CPU cost that should be addressed with pooling and capacity planning.

Changing krb_server_keyfile globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Apply the same security baseline to analytical access; isolate any legacy client exception to a dedicated role and a dated migration plan.

OLTP: Set krb_server_keyfile from the authentication architecture and security policy, not workload throughput. Test every driver, identity mapping, failover path, and credential-rotation procedure.

SMALL: Prefer the current secure default for krb_server_keyfile. Avoid weakening authentication to save marginal CPU on a small node; reduce connection churn with pooling instead.