Hadoop安全认证(2)

凭证过期处理策略

在最早的 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集群的服务来说，上述假设就不成立了。这时候我们可以

1. 扩大 ticket_lifetime 和 renew_lifetime 时限
   扩大凭证存活时限可以解决此问题，但由于Kerberos跟我们线上用户登陆认证绑定，会带来安全隐患，故不方便修改。

2. 定期重新进行kinit 认证更新凭证
   不仅仅是定期延长认证时间，可以直接定期重新认证以延长凭证有限期限。一般我们需要导出 keytab 来进行定期认证的操作。

Hadoop 将 Kerberos 认证部分进行了一定的封装，实际上并不需要那么复杂， 这里重点可以看看 UserGroupInformation 这个类。

UserGroupInformation

UserGroupInformation 这个类在 JAAS 框架上封装了 Hadoop 的用户信息， 更确切地说是对 Subject 做了一层封装。

  UserGroupInformation(Subject subject) {
    this.subject = subject;
    this.user = subject.getPrincipals(User.class).iterator().next();
    this.isKeytab = !subject.getPrivateCredentials(KerberosKey.class).isEmpty();
    this.isKrbTkt = !subject.getPrivateCredentials(KerberosTicket.class).isEmpty();
  }

JAAS 是 Java 认证和授权服务（Java Authentication and Authorization Service）的缩写， 主要包含以下几个实体:

• Subject
  Subject 是一个不可继承的实体类，它标志一个请求的来源， 包含相关的凭证标识(Principal) 和 公开和私有的凭据(Credential)。
• Principal
  凭证标识，认证成功后，一个 Subject 可以被关联多个Principal。
• Credential
  凭据，有公有凭据以及私有凭据。

JAAS的认证过程如下:

1. 
   
2. An application instantiates a LoginContext.
3. The LoginContext consults a Configuration to load all of the LoginModules configured for that application.
4. The application invokes the LoginContext's login method.
5. The login method invokes all of the loaded LoginModules. Each LoginModule attempts to authenticate the subject. Upon success， LoginModules associate relevant Principals and credentials with a Subject object that represents the subject being authenticated.
6. The LoginContext returns the authentication status to the application.
7. If authentication succeeded， the application retrieves the Subject from the LoginContext.

需要认证的代码片段可以包装在 doPrivileged 当中， 可以直接使用 Subject.doAs 方法，支持嵌套。

在安全模式下，UGI 支持不同LoginContext 配置， 均是通过 HadoopConfiguration 类动态产生:

• hadoop-user-kerberos
  使用kerberos缓存凭证登陆的配置， useTicketCache 置为 true.
• hadoop-keytab-kerberos
  使用keytab登陆的配置， useKeyTab 置为 true.

UGI 当中有多处认证， getLoginUser 方法使用 hadoop-user-kerberos 配置认证:

1. 通过配置生成 LoginContext
2. 调用 LoginContext.login 方法完成登陆， 通过 ticket cache 中凭证完成登陆
3. 判断是否需要其他用户身份(proxy user)执行
4. 将 HADOOP_TOKEN_FILE_LOCATION 中的 token 加入 Credentials 集合当中
5. 另起一个线程做周期性的凭证更新 spawnAutoRenewalThreadForUserCreds

步骤5可以看出当我们存在凭证后并不需要主动做周期性地凭证更新。

而 loginUserFromKeytab 方法使用 hadoop-kerberos 配置认证:

1. 通过配置生成 LoginContext
2. 调用 LoginContext.login 方法完成登陆， 使用keytab完成登陆

loginUserFromKeytab 没有对凭证做周期的更新， 那怎么保证凭证不会过期呢?

1. 在访问集群执行相关操作前， 可以调用 checkTGTAndReloginFromKeytab 来尝试更新凭证(实际上是重新登陆了)
2. 在凭证过期时，创建 IPC 失败会触发调用 reloginFromKeytab 来重新登陆

Client.java

    private synchronized void handleSaslConnectionFailure(
        final int currRetries， final int maxRetries， final Exception ex，
        final Random rand， final UserGroupInformation ugi) throws IOException，
        InterruptedException {
          ugi.doAs(new PrivilegedExceptionAction