self application通過kerbeos認證的四種方式

Simple Hadoop Client

• 這種方法不包含任何的認證，他依賴於當前機器已經取得TGT，這對於服務或者需要長時間執行的程式不適用，因為TGT可能會過期。每個使用者在使用時都需要kinit先獲取TGT

• 這種方法為Kerberos建立一個service account（服務的principal），所有的使用者都將使用這個service account來進行認證，而不是每個使用者都需要使用自己的賬戶進行認證。隨之帶來的問題是，由於所有的使用者都使用相同的service account來進行認證，無法在HDFS上建立基於使用者的許可權控制。 步驟如下
  
  • 1.建立Service Principal

 kadmin -q "addprinc -randkey myapplication/myhost@CLOUDERA"
Authenticating as principal cloudera-scm/admin@CLOUDERA with password.
Password for cloudera-scm/admin@CLOUDERA:
WARNING: no policy specified for myapplication/myhost@CLOUDERA; defaulting to no policy
Principal "myapplication/myhost@CLOUDERA
 
" created.

• 注： 其中-randkey是為了使用一個隨機的金鑰進行加密，而不是使用使用者的密碼加密。

  • 2.為了檢視Principal是否生成，可以執行以下程式碼

kadmin -q "getprinc myapplication/myhost"
Principal: myapplication/myhost@CLOUDERA
Expiration date: [never]
Last password change: Tue Jul 28 14:35:16 PDT 2015

• 3.然後，將此Principal倒入keytab檔案。後面我們將使用這個keytab檔案來認證。

kadmin -q "xst -k myapplication.keytab myapplication/myhost"

注：上面的xts是指對所有的加密方式都生成一個Principal。
* 4.可以通過Klist檢視keytab

klist -ke myapplication.keytab

• 5.示例程式碼如下：

class FileCount {
public static void main(final String[] args) throws IOException, FileNotFoundException, InterruptedException{

UserGroupInformation ugi = UserGroupInformation.loginUserFromKeytabAndReturnUGI("myapplication/myhost", "myapplication.keytab");
ugi.doAs( new PrivilegedExceptionAction() {
    public Void run() throws Exception {
        String path = "/";
        if( args.length > 0 )
            path = args[0];

        FileSystem fs = FileSystem.get(new Configuration());
        FileStatus[] status = fs.listStatus(new Path("hdfs://quickstart.cloudera:8020" + path));
        System.out.println("File Count: " + status.length);

        return null;
    }
} );
}
}

Kerberos Impersonation

• 這種方法相當於結合了上面的兩種方法的優點，使用統一的service Principal來認證，同時，使用proxyuser，可以在使用者層面進行許可權控制。
• 所有的使用者操作，不再依賴於使用者登陸到相應的叢集上而是相當於登陸到我們的程式裡，然後進行操作。
• 方法如下：建立 service Pincipal和keytab 的方法和上面相同，然後修改core-site.xml

<property>
<name>hadoop.proxyuser.myapplication.groups</name>
<value>group1,group2</value>
</property>
<property>
<name>hadoop.proxyuser.myapplication.hosts</name>
<value>apphost</value>
</property>
myapplication用我們建立的principal替代。group1,group2為service principal所允許的group，*表示允許所有的組。apphost用application的server的hostname代替
然後enable service auth，修改core-site.xml. 
<property>
<name>hadoop.security.authorization</name>
<value>true</value>
</property>

• 這裡有個小問題：在core-site.xml中配置這些，並不生效，需要在cloudera執行時產生的執行檔案中如：/run/cloudera-scm-agent/process/721-hdfs-HTTPFS/core-site.xml中去修改才會生效。但每次重啟叢集都需要重新配置。
• 示例程式碼如下：

class FileCount {
    public static void main(final String[] args) throws IOException, FileNotFoundException, InterruptedException{

        UserGroupInformation app_ugi = UserGroupInformation.loginUserFromKeytabAndReturnUGI("myapplication/myhost", "myapplication.keytab");
        UserGroupInformation proxy_ugi = UserGroupInformation.createProxyUser("{user}", app_ugi);

        proxy_ugi.doAs( new PrivilegedExceptionAction() {
            public Void run() throws Exception {
                String path = "/";
                if( args.length > 0 )
                    path = args[0];

                FileSystem fs = FileSystem.get(new Configuration());
                FileStatus[] status = fs.listStatus(new Path("hdfs://quickstart.cloudera:8020" + path));
                System.out.println("File Count: " + status.length);

                return null;
            }
        } );
    }
}

Single Sign On

• 沒太理解

總結

• 最後，我們選取了第三種方法Kerberos Impersonation來進行kerberos認證，通過以上的示例程式碼，可以通過FileSystem來操作HDFS。但是如果想要使用WebHDFS來操作HDFS呢。

獲取Kerberos Token。

• Webhdfs使用不同的REST來操作HDFS，如果想要使用REST訪問受kerbeos保護的資源，可以先獲取kerberos的token。(這裡獲取kerberos token的keytab必須要有HTTP//[email protected]的principal)
• 使用FileSystem的getDelegationToken函式。示例程式碼如下：

 public String getDelegationToken( String doas){
        Logger.getLogger(FileSystemClient.class.getName()).log(Level.INFO,"getDelegationToken:"+doas);
        final HdfsResult result = new HdfsResult();
        try{
                UserGroupInformation doas_ugi = UserGroupInformation.createProxyUser(doas, UserGroupInformation.loginUserFromKeytabAndReturnUGI("myapplication/myhost", "myapplication.keytab"));
                doas_ugi.doAs(new PrivilegedExceptionAction(){
                @Override
                public Object run() throws Exception {
                    FileSystem fs = getFileSystem(rootURI_kerberos);
                     Token <?> token = fs.getDelegationToken("hdfs");//to be ensure
                     String res = token.encodeToUrlString();
                     result.setData(res);
                    fs.close();
                    return null;
                }
            });

        }catch(IOException | InterruptedException ex){
            Logger.getLogger(FileSystemClient.class.getName()).log(Level.SEVERE, null, ex);
        }

        return result.getData();
    }

• 通過這樣，獲取到kerberos的Token,然後在每個REST請求的後面加上delegation=”+token即可。

String token = FileSystemClientFactory.getCliet().getDelegationToken(doas);
            uri = rootURI + dir  + "?op=MKDIRS"+"&delegation="+token;

總結

• 到這裡，我們已經能夠在kerberos的環境下使用FileSystem和Webhdfs來訪問HDFS了下面，HIVE如何通過Kerberos認證呢。

HIVE通過Kerberos。

• 我們是通過JDBC來連線hive的，以下皆為JDBC連線情況下如何通過Kberberos認證。
• hive 通過kerberos很簡單，只要在獲取connection之前進行認證即可。
• 示例程式碼如下

Configuration conf = new Configuration();
conf.set("hadoop.security.authentication", "Kerberos");
UserGroupInformation.setConfiguration(conf);
UserGroupInformation.loginUserFromKeytab("myapplication/myhost", "myapplication.keytab");

• 接下來就按照之前沒有kerberos的情況下去正常獲取connection即可。

• 問題： 這樣獲取的連線，都是使用相同的使用者（principal代表的使用者），這樣沒有辦法進行許可權控制。

• 解決辦法：如同上面HDFS一樣，通過產生proxyUser來獲取連線，在cloudera中叫做hive impersonation。程式碼不再貼出。
• 問題：在配置了kerberos之後，無法跑成作業的問題，在hive的cli中報錯

execution error return code 2 from org.apache.hadoop.hive.ql.exec.mr.mapredtask state 08s01 code 2 

• 通過這個報錯，查看不出什麼資訊。到resource manager中檢視，發現：

main : run as user is root
main : requested yarn user is root
user root is not allowd

• 即，root使用者不被允許跑hive作業。至此，找到錯誤，在yarn的security中，有配置
  
  • min.user.id(預設為1000)
  • allowed systen user
  • banned system user
• 這裡的root和hdfs使用者的userid都是小於1000的，而且在banned system user中，所以不能跑通hive作業。
• 問題： 在這裡，我將min.user.id改為0,並將root和hdfs從banned中去除，仍然是跑不了hive作業。好奇怪。但無論如何，換成普通使用者是可以跑通hive作業的。

Impala通過Kerberos

• 如果叢集未開啟kerberos，且impala和hive使用相同的驅動hive2.則imapala通過kerberos的方式和hive相同。不再多說。

HIVE 在開啟sentry後的問題

• 在hive開啟sentry後hive impersonation不再可用(cloudera解釋說，這是因為sentry和impersonation是兩種不同的認證授權方式，不可同時使用。)。所以之前使用hive impersonation通過kerberos的方法不再可行。
• 在cloudera裡，看到關於trust delegation的描述，通過受信任的使用者通過認證，然後在產生proxyUser即可通過認證，同時可以進行許可權控制，程式碼很簡單，只需要在獲取connection的url中加入

jdbc:hive2://myHost.myOrg.com:10000/default;principal=hive/[email protected];hive.server2.proxy.user=bob

這裡的principal使用者，如果是自定義的，需要在core-site.xml中配置，但我們可以偷偷的使用hue使用者（自己新增一個類似hue/[email protected]的principal），這樣，就免去配置了。

Impala 在開啟sentry後的問題

• 在開啟sentry之前，impala是使用和hive一樣的方式來通過kerberos認證的，那末，在開啟sentry之後，是否也能使用相同的辦法來進行kerberos下的sentry許可權管理呢，很可惜，答案是不能。
• 在google中，有人提到可以在impala的jdbc的url後面想hive一樣，新增impala.proxy.user和impala.doas.user來完成，但經過實驗，這兩種方式都不行。
• 由於impala和hive使用相同的jdbc驅動，會不會是這裡出現了問題呢。於是我將impala的驅動換為impala自己的simba。
• 在simba的文件中，解決方案如下：

Configuration conf = new Configuration();
        conf.set("hadoop.security.authentication", "Kerberos");
        UserGroupInformation.setConfiguration(conf);
//            UserGroupInformation.loginUserFromKeytab(ConfigurationUtil.getValue("kerberos.principal.name", ConfigurationUtil.getRequestURL()), ConfigurationUtil.getValue("kerberos.principal.location", ConfigurationUtil.getRequestURL()));
        UserGroupInformation app_ugi=UserGroupInformation.loginUserFromKeytabAndReturnUGI(ConfigurationUtil.getValue("kerberos.principal.name", ConfigurationUtil.getRequestURL()), ConfigurationUtil.getValue("kerberos.principal.location", ConfigurationUtil.getRequestURL()));

        try{
            con=  (Connection) app_ugi.doAs(new PrivilegedExceptionAction(){//這裡按說應是doas_gui,但doas_gui卻不生效，待考慮。
              @Override
              public Object run() throws Exception {
                Connection   con = DriverManager.getConnection(rootURI+";AuthMech=1;KrbRealm="+krbRealm +
                ";KrbHostFQDN="+hostFQDN+";KrbServiceName=impala"+";DelegationUID="+doas);
                  return con;
              }
          });
        }catch(IOException | InterruptedException ex){
            Logger.getLogger(ImpalaConnection.class.getName()).log(Level.SEVERE, null, ex);
        }   

• 這裡是使用delegationUID來進行不同使用者的區分的。

呼~~~~