Authentication kerberos中服务主体名称的更改

不确定发生了什么，因为这里有多个运动部件。 我们有一个用于hdfs、hadoop、impala和hbase的cloudera集群。我们所有的impala服务器前面都有一个F5负载平衡器。我们正在尝试使用Kerberos保护服务器/群集。我的同事使用MIT KDC设置了Kerberos。当我们直接向服务器查询impala时，此设置工作正常，但当我们通过F5负载平衡器时，此设置工作正常

我们已经运行kinit来获取预创建的keytab文件的票证

kinit -k -t /blah/keytabs/first.last.keytab first.last

当我运行

klist

时，它会显示所有这些票据：

$ klist
Ticket cache: FILE:/tmp/krb5cc_14377
Default principal: first.last@MADEUPNAME

Valid starting     Expires            Service principal
08/23/17 11:32:02  08/24/17 11:32:02  krbtgt/MADEUPNAME@MADEUPNAME
    renew until 08/23/17 11:32:02
08/23/17 11:33:39  08/24/17 11:32:02  impala/hslave32101.company.com@MADEUPNAME
    renew until 08/23/17 11:32:02

当我运行impala shell命令时，它工作正常：

$ impala-shell -i hslave32101.company.com:21000 -k -q "select 1"
Starting Impala Shell using Kerberos authentication
Using service name 'impala'
Connected to hslave32101.company.com:21000
Server version: impalad version 2.7.0-cdh5.9.2 RELEASE (build 2f7871169d894fab16f8a2fb99f2e34f0df8763d)
Query: select 1
Query submitted at: 2017-08-23 13:08:34 (Coordinator: http://hslave32101.company.com:25000)
Query progress can be monitored at: http://hslave32101.company.com:25000/query_plan?query_id=4940ca8ca2f267c5:5eeb29af00000000
+---+
| 1 |
+---+
| 1 |
+---+
Fetched 1 row(s) in 0.01s

但是，当我通过F5 loadbalancer运行命令时，它不起作用，因为它查找的票证与

klist

中的票证不匹配，因为它出于某种原因替换了部分票证

impala-shell -i bdaudit.company.com:21000 -d bigdata -k -q "select 1"
Starting Impala Shell using Kerberos authentication
Using service name 'impala'
Error connecting: TTransportException, Could not start SASL: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server krbtgt/COMPANY.COM@MADEUPNAME not found in Kerberos database)
Not connected to Impala, could not execute queries.

这里的问题是这条线

（服务器krbtgt/公司。COM@MADEUPNAME未在Kerberos数据库中找到）

---

不知何故，当通过F5 VIP时，它会先改变。last@MADEUPNAME去公司。COM@MADEUPNAME. 有人知道为什么它会替换这部分车票吗？

从Cloudera关于如何使用F5和F4设置黑斑羚的说明中找到了原因

以下是PDF中的片段：

在Cloudera Manager中，导航到Impala服务，选择配置窗格，然后搜索“平衡器”以
查找Impala守护进程负载平衡器参数。应以主机：端口格式指定负载平衡器，
其中主机是虚拟服务器的FQDN和端口。Cloudera Manager使用这些值，并传递这些值
调色
如果指定了Impala守护进程负载平衡器参数并启用了Kerberos，Cloudera Manager将添加
将“impala/@”的主体添加到所有impala守护进程的键选项卡。没有额外的
Kerberos需要配置。

---

1/2“我的同事使用MIT KDC设置了Kerberos。当我们直接向服务器查询impala时，此设置工作正常，但当我们通过F5负载平衡器时，此设置工作正常。”-->。F5是配置为传递到应用服务器还是配置为反向代理？我认为必须将其配置为直通负载平衡器，以便Kerberos工作，否则身份验证通信将在F5停止并丢弃，而无需在F5进行进一步配置。我在这里做一个有根据的猜测。2/2“然而，当我通过F5 loadbalancer运行我的命令时，它不起作用，因为它要查找的票证与klist中的票证不匹配，因为它出于某种原因替换了其中的一部分……不知何故，当通过F5 VIP时，它会先更改。last@MADEUPNAME去公司。COM@MADEUPNAME. 有人知道为什么它会取代这部分票吗？“->这些声明似乎证实了您的F5是对黑斑羚的反向代理。你能证实还是否认这一点？我认为如果F5没有进一步配置，它将无法工作。@t-Heron，谢谢你对我的问题感兴趣。F5设置为直通式。在找到Cloudera关于如何实现这一点的文档后，我们让它开始工作。我们仍然不知道为什么名称会在错误中更改，除了猜测KDC正在尝试查找名为bdaudit.company.com的资源，因为资源是hslave33333.company.com，并且出于某种原因，将名称截断为company。com@MADEUPNAME

In Cloudera Manager, navigate to the Impala service, select the Configuration pane, then search for “balancer” to
find the Impala Daemons Load Balancer parameter. The load balancer should be specified in host:port format,
where host is your virtual server’s FQDN and port. These values are used by Cloudera Manager and are also passed
to Hue

If the Impala Daemons Load Balancer parameter is specified and Kerberos is enabled, Cloudera Manager adds a
principal for 'impala/<load_balancer_host>@<realm>' to the keytab for all Impala daemons. No additional
configuration is required for Kerberos.