[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/logdmind.log [libdefaults] default_realm = HBASE.YOUKU1 dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true [realms] EXAMPLE.COM = { kdc = kerberos.example.com1 admin_server = kerberos.example.com1 } HBASE.YOUKU = { kdc = a01.regionserver.master.hbase.bigdata.vm.m6.youku1 kdc = a01.regionserver.hbase.bigdata.m6.youku1 admin_server = a01.regionserver.master.hbase.bigdata.vm.m6.youku1 default_domain = hbase.youku1 } [domain_realm] .example.com = EXAMPLE.COM1 example.com = EXAMPLE.COM1 .hbase.youku = HBASE.YOUKU1 hbase.youku = HBASE.YOUKU1
[libdefaults] default_realm = MAOYAN.COM // 默认的domain,这样在kinit中,便可以省略了 allow_weak_crypto = false // 强加密如弱加密,不明白是什么意思,先禁掉 dns_lookup_realm = false // 不走DNS,这几台机器的域名解析都已经相互配置到hosts里了 dns_lookup_kdc = false ticket_lifetime = 24h // ticket 过期时间 renew_lifetime = 7d // ticket 可延期的时间,默认是0 forwardable = true // ticket 是否可转发。注意,最严格的限制点在服务器端的配置 udp_preference_limit = 1 // 大小超过这一限制时,先整TCP;尚不清楚单位是字节还是什么 [realms] MAOYAN.COM = { kdc = dx-movie-data-hadoop05:88 // kdc服务器,如果是master/slave模式,就重复地多写几行 admin_server = dx-movie-data-hadoop05:749 // kdc主服务器,如果有多台,也多写几行 default_domain = MAOYAN.COM // 应该是kerberos 4和5之间兼容用的 } [appdefaults]
Kerberos 凭证(ticket) 有两个属性, ticket_lifetime 和 renew_lifetime。其中 ticket_lifetime 表明凭证生效的时限,一般为24小时。在凭证失效前部分凭证可以延期失效时间(即Renewable), renew_lifetime 表明凭证最长可以被延期的时限,一般为一个礼拜。当凭证过期之后,对安全认证的服务的后续访问则会失败。这里第一个问题就是如何处理凭证过期。
凭证过期处理策略
在最早的 Security features for Hadoop 设计中提出这样的假设:
A Hadoop job will run no longer than 7 days (configurable) on a MapReduce cluster or accessing HDFS from the job will fail.
对于一般的任务, 24小时甚至延迟到一周的凭证时限是足够充分的。所以大部分时间我们只需要在执行操作之前使用 kinit 认证一遍,再起后台任务进行周期性凭证更新即可。
while true ; do kinit -R; sleep $((3600 * 6)) ; done &
不过对于需要常驻的访问Hadoop集群的服务来说,上述假设就不成立了。这时候我们可以
扩大 ticket_lifetime 和 renew_lifetime 时限
扩大凭证存活时限可以解决此问题,但由于Kerberos跟我们线上用户登陆认证绑定,会带来安全隐患,故不方便修改。
定期重新进行kinit 认证更新凭证
不仅仅是定期延长认证时间,可以直接定期重新认证以延长凭证有限期限。一般我们需要导出 keytab 来进行定期认证的操作。
Hadoop 将 Kerberos 认证部分进行了一定的封装,实际上并不需要那么复杂, 这里重点可以看看 UserGroupInformation 这个类。
http://tech.meituan.com/hadoop-security-practice.html
报错信息:
17:24:56 ERROR [http-8280-exec-1] org.apache.hadoop.security.UserGroupInformation(UserGroupInformation.java:1494) - PriviledgedActionException as:yule/[email protected] (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)] 17:24:57 ERROR [http-8280-exec-1] org.apache.hadoop.security.UserGroupInformation(UserGroupInformation.java:1494) - PriviledgedActionException as:yule/[email protected] (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)] 17:24:59 ERROR [http-8280-exec-1] org.apache.hadoop.security.UserGroupInformation(UserGroupInformation.java:1494) - PriviledgedActionException as:yule/[email protected] (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
http://blog.csdn.net/lalaguozhe/article/details/11570009