Kerberos keytab文件按照约定位于/etc/krb5/krb5.keytab，这是一个非用户特定的位置。该键选项卡(以及所有键选项卡(可以包含多个条目。
假设一台计算机有三个用户：爱丽丝、鲍勃和伊芙。他们每个人都通过以下过程向共享键选项卡添加一个条目，但使用各自的名称：
$ ktutil
ktutil: addent -password -p alice@REALM.COM -e aes256-cts -k 1
Password for alice@REALM.COM:
ktutil: list -e
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
1 1 alice@REALM.COM (aes256-cts-hmac-sha1-96)
ktutil: wkt krb5.keytab
稍后，Alice、Bob和Eve都可以使用他们的keytab条目来验证脚本，分别如下：
> kinit alice@REALM.COM -k -t mykeytab; myscript
是什么阻止了伊芙使用Alice或Bob在keytab中的条目？我还没有发现任何明确涵盖如何保护多个条目的keytab安全的内容。如果我们不想让Eve使用Alice的条目，他们是否应该有受文件权限保护的单独的密钥选项卡？
或者，这是Kerberos信任模型吗？如果他们每个人都有权访问这个keytab，那么我们隐含地信任他们使用任何条目？我们应该只让可信的服务共享密钥标签吗？
提前感谢您的提示。只是想确保我正确理解信任模型。
keytab文件包含一个(或多个(Kerberos主体的密码，该主体使用一个(或者多个(密码进行预加密。事实上，这是密码的历史，新密码被添加到旧密码的"顶部"。
必须像保护任何其他密码文件一样保护Keytab文件，即具有严格的FS访问权限
使用一个keytab文件作为多个主体的转储是没有意义的——除非所有这些主体都被在同一Linux帐户下运行的各种服务或作业使用。即便如此，这也可能是个坏主意
例如，阅读Ambari如何管理各种Hadoop服务的键选项卡(包括所有具有HTTP接口的服务共享的"spnego"键选项卡(，并关注chown和chmod命令：
https://ambari.apache.org/1.2.5/installing-hadoop-using-ambari/content/ambari-kerb-1-4.html