Kerberos

Kerberos scaffolding (based on the Ambari environment)

To build the KDC

1. The installation
   
   yum install krb5-server krb5-libs krb5-workstation

2. Change the configuration file vi /etc/krb5.conf

   [libdefaults] renew_lifetime = 7d forwardable = true default_realm = EXAMPLE.COM ticket_lifetime = 24h dns_lookup_realm = false dns_lookup_kdc = false default_ccache_name = /tmp/krb5cc_%{uid} #default_tgs_enctypes = aes des3-cbc-sha1 rc4 des-cbc-md5 #default_tkt_enctypes = aes des3-cbc-sha1 rc4 des-cbc-md5 [logging] default = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log kdc = FILE:/var/log/krb5kdc.log [realms] EXAMPLE.COM = { admin_server = Master. Hadoop // Here is your host name KDC = master. Hadoop // Here is your host name}

3. Create the Kerberos database
   
   kdb5_util create -s

The terminal will prompt you for the password, which is required to administer the Kerberos database

1. To start the KDC
   
   systemctl start krb5kdc

systemctl start kadmin
2. Start the auto boot service
   
   systemctl enable krb5kdc

systemctl enable kadmin
3. Create a Kerberos administrator
   
   kadmin.local -q "addprinc admin/admin"
4. Restart the kadmin process
   
   systemctl restart kadmin

Install the JCE

1. Gets the JCE policy file for the JDK version in the cluster

   • For Oracle JDK 1.8:

http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html - for Oracle JDK 1.7:  http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

1. Unzip it into the installed JDK (this step must be installed on each cluster! Keep in mind! Remember!)
   
   Unzip-o-j-q jce_policy-8.zip-d /opt/jdk1.8.0_111/jre/lib/security/
2. Restart the Ambari server
   
   ambari-server restart

Enter the Ambari wizard to enable Kerbores

I did not take the screenshot until I finished it. There are two configuration options missing from KADMIN. Please fill in one piece from the Internet.

Just go next.

Kerbores use

1. The kadmin. Local and kadmin

   Kadmin. local or kadmin depends on your account and access rights: Kadmin. local (on the KDC machine) or kadmin (on others machine) If you have root access to the KDC server, but do not have Kerberos admin account, If you do not have root access to the KDC server, but do have a Kerberos admin account, use kadmin

2. Add notes

   $ kadmin.local
   addprinc -randkey test/[email protected]
   
   xst -norandkey -k /etc/security/keytabs/test.service.keytab test/[email protected]

3. Obtain bill information

   kadmin.local:  getprinc test/[email protected]
   Principal: test/[email protected]
   Expiration date: [never]
   Last password change: Wed Apr 03 16:05:50 CST 2019
   Password expiration date: [none]
   Maximum ticket life: 1 day 00:00:00
   Maximum renewable life: 0 days 00:00:00
   Last modified: Wed Apr 03 16:05:50 CST 2019 (ljk/[email protected])
   Last successful authentication: [never]
   Last failed authentication: [never]
   Failed password attempts: 0
   Number of keys: 8
   Key: vno 1, aes256-cts-hmac-sha1-96
   Key: vno 1, aes128-cts-hmac-sha1-96
   Key: vno 1, des3-cbc-sha1
   Key: vno 1, arcfour-hmac
   Key: vno 1, camellia256-cts-cmac
   Key: vno 1, camellia128-cts-cmac
   Key: vno 1, des-hmac-sha1
   Key: vno 1, des-cbc-md5
   MKey: vno 1
   Attributes:
   Policy: [none]

4. List all notes of KDC

   listprincs

5. Delete the bill

   delprinc test/[email protected]

6. Modify the properties

   modprinc -maxlife 30days test/[email protected]

7. Cache paper

   
    klist -k -t /etc/security/keytabs/test.service.keytab
    kinit -k -t /etc/security/keytabs/test.service.keytab test/[email protected]
    kinit -k -t /etc/security/keytabs/test.service.keytab  -c /tmp/testkeytab test/[email protected]

8. Update the bill

   kinit -R

9. View or delete tickets cached by the user

   klist

kdestroy

10. Merge paper

    ktutil
    ktutil: rkt test.service.keytab
    ktutil: rkt test1.service.keytab
    ktutil: wkt test-test1.service.keytab

How does a client access the Kerbores HDP cluster

Most of the methods on the Web generate their own ticket and use that ticket as the basis for client validation.

But in fact, HDP has generated a lot of tickets and keytabs for the cluster, which can be used directly.

So let’s verify that.

1. Take a look at the Principal generated by the HDP

   You can see that the principals generated by the HDP are very formal, in the form of $service /$host name.

   kadmin.local:  listprincs 
   HTTP/[email protected]
   HTTP/[email protected]
   HTTP/[email protected]
   K/[email protected]
   admin/[email protected]
   [email protected]
   [email protected]
   amshbase/[email protected]
   amshbase/[email protected]
   amszk/[email protected]
   dn/[email protected]
   dn/[email protected]
   [email protected]
   hbase/[email protected]
   hbase/[email protected]
   [email protected]
   hive/[email protected]
   hive/[email protected]
   hive/[email protected]
   jhs/[email protected]
   [email protected]
   jn/[email protected]
   jn/[email protected]
   jn/[email protected]
   kadmin/[email protected]
   kadmin/[email protected]
   kadmin/[email protected]
   kiprop/[email protected]
   krbtgt/[email protected]
   nm/[email protected]
   nm/[email protected]
   nn/[email protected]
   nn/[email protected]
   rm/[email protected]
   yarn/[email protected]
   zookeeper/[email protected]
   zookeeper/[email protected]
   zookeeper/[email protected]

2. Download the keytab for Active NN
   
   In the configuration information it can be found where it is located/etc/security/keytabsNext, locate nn.service.keytab and download it locally.

3. Now that the Hadoop cluster is protected by Kerbores, you will receive an error if you access it as usual.

   Caused by: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException): SIMPLE authentication is not enabled.  Available:[TOKEN, KERBEROS]

   Just add validation on top of what you usually do.

   The code is as follows:

   public static void main(String[] args) throws IOException { final String USER_KEY = "nn/nn2.ambari"; final String KEY_TAB_PATH = "/Users/LJK/Downloads/nn.service.keytab"; Configuration conf = new Configuration(); System.setProperty("java.security.krb5.conf", "/Users/LJK/Downloads/krb5.conf"); // System.setProperty("sun.security.krb5.debug", "true"); conf.set("fs.defaultFS", "hdfs://mycluster:8020"); conf.set("hadoop.security.authentication", "KERBEROS"); conf.set("dfs.client.block.write.replace-datanode-on-failure.policy", "NEVER"); UserGroupInformation.setConfiguration(conf); UserGroupInformation.loginUserFromKeytab(USER_KEY, KEY_TAB_PATH); FileSystem fileSystem = FileSystem.get(conf); FileStatus[] fileStatuses = fileSystem.listStatus(new Path("/LJKTEST")); for (FileStatus fileStatus : fileStatuses) { Path path = fileStatus.getPath(); System.out.println(path.toString()); }}

   There’s a little bit of a hole here. I always thought that if I put the keytab file in the resource directory, I would be able to access it directly. This is the same reason that you assign the null value to the path address. The error is also disgusting. I always thought that the file could not be found. A little hole ~

   Caused by: javax.security.auth.login.LoginException: Unable to obtain password from user

Access the Kerberos HBase cluster

@Before
    public void init() throws IOException {

        BasicConfigurator.configure();
        final String USER_KEY = "hbase/[email protected]";
        String keyTabPath = Objects.requireNonNull(
            HBaseSoulTest.class.getClassLoader().getResource("hbase.service.keytab")).getPath();
        String krb5Path = Objects.requireNonNull(
            HBaseSoulTest.class.getClassLoader().getResource("krb5.conf")).getPath();
        System.setProperty("java.security.krb5.conf", krb5Path);
        Configuration conf = HBaseConfiguration.create();
        conf.set("hbase.master.kerberos.principal", "hbase/[email protected]");
        conf.set("hbase.regionserver.kerberos.principal", "hbase/[email protected]");
        conf.set("hbase.zookeeper.quorum", "nn1.ambari");
        conf.set("hbase.zookeeper.property.clientPort", "2181");
        conf.set("zookeeper.znode.parent", "/hbase-secure");
        conf.set("hadoop.security.authentication", "Kerberos");
        conf.set("hbase.security.authentication", "Kerberos");

        UserGroupInformation.setConfiguration(conf);
        UserGroupInformation.loginUserFromKeytab(USER_KEY, keyTabPath);

        connection = ConnectionFactory.createConnection(conf);
    }

If you create your own keytab, you need to go to the HBase shell to do an authorization action. Otherwise your account permissions are insufficient.

HBase shell authorization action statements

permissions is either zero or more letters from the set “RWXCA”.

READ(‘R’), WRITE(‘W’), EXEC(‘X’), CREATE(‘C’), ADMIN(‘A’)

grant 'test', 'RWXCA'

The appendix

• Common language to interpret Kerberos
• The illustration Kerberos
• Build Kerberos based on Ambari
• How does Ambari add Kerberos
• How do clients access the Kerberos cluster
• How does Kerbores work