PostgreSQL 的 GSSAPI 认证看起来像是“启用 Kerberos”这么简单，实际却依赖两个容易被忽略的服务端设置：krb_server_keyfile 决定 PostgreSQL 从哪个 keytab 读取服务密钥，krb_caseins_users 决定 Kerberos 用户名与 PostgreSQL 角色名匹配时是否区分大小写。把这两个开关混在一起排查，通常会让认证问题变得更难定位。
krb_server_keyfile：给 PostgreSQL 一份专用 keytab
krb_server_keyfile 指向 PostgreSQL 使用的 keytab 文件。这个文件应当是专门为数据库服务准备的副本，而不是直接复用系统范围的 keytab。系统 keytab 往往包含多个服务主体；让数据库进程读取它，会扩大凭据暴露面，也会让密钥轮换和权限审计变得含混。
可以这样配置：
# postgresql.conf
krb_server_keyfile = '/var/lib/postgresql/15/main/postgres.keytab'
然后为该文件设置严格的属主和权限。下面的命令假设 PostgreSQL 服务账号是 postgres，实际部署时请替换为本机账号和数据目录：
sudo install -o postgres -g postgres -m 0600 /tmp/postgres.keytab \
/var/lib/postgresql/15/main/postgres.keytab
sudo -u postgres klist -k /var/lib/postgresql/15/main/postgres.keytab
keytab 中的服务主体必须与客户端请求的 PostgreSQL GSSAPI 服务主体一致，常见形式是 postgres/<数据库主机名>@<REALM>。主机名、DNS、反向解析和 keytab 主体不一致时，即使 pg_hba.conf 规则写对了，认证仍然会失败。
这个设置的边界也很明确：它只解决 PostgreSQL 服务端如何取得 Kerberos 密钥，不负责决定认证规则。允许哪些客户端、哪些数据库和哪些角色，仍然要在 pg_hba.conf 中配置。
krb_caseins_users：角色映射是否区分大小写
krb_caseins_users 控制 Kerberos 用户名与 PostgreSQL 用户名匹配时的大小写行为。启用后，匹配可以不区分大小写；关闭时，大小写差异可能导致同一个 Kerberos 身份无法映射到预期的 PostgreSQL 角色。
这里有一个容易混淆的点：该设置改变的是用户名匹配规则，不是 Kerberos realm 的大小写约定，也不会自动创建 PostgreSQL 角色。生产环境应先明确组织对主体名和数据库角色名的命名规范，再决定是否开启它。
例如，假设 Kerberos 主体是 Alice@EXAMPLE.COM，数据库角色是 alice，对应的 pg_hba.conf 可以写成：
# TYPE DATABASE USER ADDRESS METHOD
host all all 10.20.0.0/16 gss
若团队允许主体名和角色名仅在大小写上不同，可以在 postgresql.conf 中使用：
krb_caseins_users = on
若希望身份映射严格、可预测，则保持区分大小写，并通过明确的角色命名或用户映射处理差异。无论选择哪种方式，都应使用实际客户端主体做一次端到端测试，而不是只检查配置文件语法。
一份可操作的最小检查流程
可以按下面的顺序缩小问题范围：
# 1. 确认 PostgreSQL 当前生效的值
psql -d postgres -c "SHOW krb_server_keyfile;"
psql -d postgres -c "SHOW krb_caseins_users;"
# 2. 确认服务主体存在于专用 keytab
sudo -u postgres klist -k /var/lib/postgresql/15/main/postgres.keytab
# 3. 确认客户端持有 Kerberos 凭据
klist
# 4. 使用 GSSAPI 发起连接；主机名应使用证书、DNS 和主体配置中的真实名称
psql "host=db01.example.com dbname=app user=alice" -c 'select current_user;'
如果第一步显示的路径不对，先修复 krb_server_keyfile 并重新加载配置。如果 keytab 中没有正确主体，重新生成专用 keytab。如果连接已完成 Kerberos 交换但角色匹配失败，再检查 krb_caseins_users、角色名和用户映射。日志中的错误阶段通常比盲目修改多个参数更有价值。
上线前的取舍
建议把专用 keytab 纳入密钥轮换流程，限制只有 PostgreSQL 服务账号可读，并记录主体变更。对 krb_caseins_users 则应采取保守策略：除非现有命名体系确实需要大小写不敏感匹配，否则优先使用明确且一致的角色命名。
上线检查可以压缩成四项：
krb_server_keyfile指向专用 keytab，而不是系统 keytab。- keytab 文件属主、权限、主体和数据库主机名都正确。
pg_hba.conf使用了适合目标网络范围的gss规则。- 使用真实 Kerberos 主体验证了角色映射，并单独确认大小写策略。
这两个 GUC 一个负责“数据库拿哪把服务密钥”，另一个负责“身份名称如何匹配”。分开理解和验证，Kerberos 认证故障就能从一团模糊的登录失败，变成几个可以逐项确认的配置问题。