Kerberos认证技术咨询：服务端Keytab与用户主体相关疑问

问题1：所有采用Kerberos认证的服务（例如Postgres）是否必须拥有KDC生成的keytab文件？能否不依赖keytab实现Kerberos认证？ #

• 绝大多数Kerberos服务端（包括Postgres）必须使用KDC生成的keytab文件。keytab存储了服务主体的密钥，服务端需要用它来解密客户端提交的服务票据，完成自身身份验证以及和KDC的交互流程，这是Kerberos服务端认证的核心基础。
• 存在极少数不依赖keytab的特殊场景，但几乎不用于生产环境：
  • 服务以已完成kinit的用户身份启动，直接复用该用户的Kerberos缓存完成验证，仅适用于临时测试或单用户专属服务场景。
  • 部分定制化实现用硬件安全模块（HSM）等替代keytab存储服务密钥，但本质只是密钥存储方式的变更，仍依赖KDC生成的服务密钥体系，并非完全脱离keytab的逻辑。

问题2：已为Postgres配置好KDC生成的keytab后，在KDC中新增用户主体Born并在Postgres中创建对应角色，为何通过kinit Born仍能连接Postgres？Postgres的keytab如何获取新用户的信息？ #

• Postgres的keytab不存储任何用户信息，它仅保存Postgres服务自身的密钥，用于解密KDC签发的服务票据。
• 成功连接的完整逻辑：
  1. 用户Born通过kinit向KDC申请并获取TGT（票据授予票据）。
  2. Born凭借TGT向KDC请求Postgres服务的服务票据，KDC验证Born的主体合法性后，生成包含Born身份信息的服务票据返回给Born。
  3. Born携带该服务票据连接Postgres，Postgres用自身keytab中的密钥解密票据，从中提取Born的主体信息，再与本地数据库中已创建的对应角色进行匹配，匹配通过则允许连接。
• 整个过程中，Postgres无需主动从KDC同步用户信息，而是通过客户端提交的服务票据获取用户身份，只要KDC认可该用户且Postgres存在对应角色，即可完成认证。

内容的提问来源于stack exchange，提问作者Gerzzog