启用AWS EMR专职KDC跨域信任(Cross-Realm Trust)的注意事项

Posted 2022-11-29 bluishglc

文章目录

• • 注意事项
  • VPC配置参考
  • 重要的日志
  • 常见错误

启用Cross-Realm Trust后，将对要创建EMR集群提出多个“隐性”的限制条件，启用前需要清楚并满足这些约束条件，否则创建EMR集群就会失败。

注意事项

1. EMR集群必须在一个IP长度少于9个字符的VPC里。为了满足这一条件，VPC的CIDR最好取10.0.0.0/16，子网的CIDR可以依次取10.0.1.0/24，10.0.2.0/24等。这样可以确保IP总长度在9个字符之内。之所以有这样的限制是因为AWS总是基于IPv4地址分配DNS主机名，以IP为10.0.0.1的主机为例，AWS为其配置的DNS主机名是ip-10-0-0-1。而Active Directory对主机名是有长度限制的，不得超过15个字符，这样，去除前缀字符串ip和四个连字符，留给IP地址的长度就只有15-6=9个字符长度了。归根结底，这是由于AWS基于IP生成DNS主机名导致的。

2. Kerberos的KDC和Active Directory域控制器必须能够解析对方的域名。一方面，AD在添加对KDC的信任时，需要提供KDC的FQDN，如果当时不能提供，后续AD还将在DNS中查找，这就意味着：KDC和AD不但网络上必须是通的，并且还必须能解析对方的域名。另一方面，EMR在执行入域操作时需要访问AD服务器。所以文档中直接使用了AD服务器作为VPC的DNS服务器，确保域名解析没有问题。

3. 基于第1、2两点，对AD服务器的网络位置，需要特别注意，要分两种情况区别对待：

   情形一：如果是随EMR新建AD服务器，则：

   • AD服务器最好放置于与EMR相同的VPC里，目的是确保网络联通
   • 让该AD服务器同时担任该VPC的DSN服务器，目的是确保AD和KDC能相互解析对方DNS

   情形二：如果AD已存在，则：

   • 需要打通AD与EMR专职VPC（IP小于9个字符的VPC）的网络
   • AD与KDC能相互解析对方的域名

   情形一一般是测试或为EMR创建专职AD服务器做为LDAP，而大多数企业用户面临的都是情形二，他们的AD服务器均早已建立，且不能更改网络位置，这时候需要首先解决网络和域名解析的问题。（或许会涉及VPC Peering一类的操作，需网络方向上的技术支持。）

4. 如果是创建专职VPC与AD服务器（即情形一），则还应注意如下事项：

   • 确保VPC同时启用了DNS主机名和DNS解析
   • VPC的DHCP Options Sets配置中，Domain name一项配置的值必须不同于AD的Domain，这一点非常重要

   由于我们是要配置的是AD对Kerberos的Cross-Realm的one-way trust，所以AD和KDC必定是两个不同的realm，假设AD的domain是：example.com, kdc(也就是EMR）的domain（计划）是：cn-north-1.compute.internal，则该项一定要填入cn-north-1.compute.internal，不要弄混，如果填入的是AD的domain：example.com，则EMR集群必定会创建失败。

VPC配置参考

基于上述四点注意事项，下面给出一个VPC的配置参考，需要注意的地方均已标注：

• VPC配置参考
  
• DHCP Options Sets配置参考

重要的日志

在EMR启动过程中，会完成Cross-Realm Trust若干重要操作，我们逐一罗列一下，便于了解自动化脚本背后发生的故事，这些日志信息也是排查错误时应该特别关注的一些地方：

• 通过给定的AD的Admin用户-ermadmin将EMR节点加入AD的Realm

• 创建跨越信任的krbtgt principal

常见错误

• GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))
• KrbException: Server not found in Kerberos database (7)
• KrbException: Identifier doesn’t match expected value (906)

以上错误均为未正确配置VPC的DHCP Options Sets中的Domain name一项导致的。

此外，在官方文档中，也存在一处明显的错误：