Skip to content

Split View: cross realm trust HBase 설정 방법

|

cross realm trust HBase 설정 방법

Background

Kerberos가 적용된 두 하둡 클러스터의 REALM이 다르다면, 이론적으로 두 클러스터 간의 데이터 이동은 불가능 하다. 하지만 Cross Realm Trust를 설정한다면 클러스터 간의 data를 조회하거나 자유롭게 옮기는 것도 가능하다.

Prerequisite

Kerberos가 이미 적용된 A와 B라는 두 개의 cluster가 있다고 가정하고 하겠다. A 클러스터는 UBUNTU.YJ.COM 라는 Realm에 속해있고, B 클러스터는 CENTOS.YJ.COM 라는 Realm에 속해있다. 또한 각각의 Cluster는 Zookeeper, HDFS, HBase, YARN 컴포넌트를 가지고 있다.

Steps

1. krbtgt 생성

cross Realm 에서는 krbtgt 라는 이름의 Principal이 굉장히 중요하다.

UBUNTU.YJ.COM KDC에 아래 두개의 principal을 등록한다.

krbtgt/UBUNTU.YJ.COM@CENTOS.YJ.COM krbtgt/CENTOS.YJ.COM@UBUNTU.YJ.COM

마찬가지로 UBUNTU.YJ.COM KDC에 아래 두개의 principal을 등록한다.

krbtgt/UBUNTU.YJ.COM@CENTOS.YJ.COM krbtgt/CENTOS.YJ.COM@UBUNTU.YJ.COM

위의 4개의 principal의 encryption type과 password, kvno는 모두 동일해야한다.

2. /etc/krb5.conf, /etc/hosts 업데이트

UBUNTU.YJ.COM relam에 속한 서버의 /etc/krb5.conf에는 CENTOS.YJ.COM 관련 설정을 아래와 같이 추가해주어야 한다.

krb5.conf
[libdefaults]
  default_realm = UBUNTU.YJ.COM
[realms]
  UBUNTU.YJ.COM = {
    kdc = kdc01.hadoop.example.com:88
    admin_server = kdc01.hadoop.example.com:749
    default_domain = ubuntu.yj.com
  }
  CENTOS.YJ.COM = {
    kdc = kdc01.example.com:88
    admin_server = kdc01.example.com:749
    default_domain = centos.yj.com
  }
[domain_realm]
  .ubuntu.yj.com = UBUNTU.YJ.COM
  ubuntu.yj.com = UBUNTU.YJ.COM
  .centos.yj.com = CENTOS.YJ.COM
  centos.yj.com = CENTOS.YJ.COM

CENTOS.YJ.COM relam에 속한 서버의 /etc/krb5.conf에는 UBUNTU.YJ.COM 관련 설정을 아래와 같이 추가해주어야 한다.

krb5.conf
[libdefaults]
  default_realm = CENTOS.YJ.COM
[realms]
  CENTOS.YJ.COM = {
    kdc = kdc01.example.com:88
    admin_server = kdc01.example.com:749
    default_domain = centos.yj.com
  }
  UBUNTU.YJ.COM = {
    kdc = kdc01.hadoop.example.com:88
    admin_server = kdc01.hadoop.example.com:749
    default_domain = ubuntu.yj.com
  }

[domain_realm]
  .centos.yj.com = CENTOS.YJ.COM
  centos.yj.com = CENTOS.YJ.COM
  .ubuntu.yj.com = UBUNTU.YJ.COM
  ubuntu.yj.com = UBUNTU.YJ.COM

또한 /etc/hosts 에 상대편 클러스터 서버에 대한 정보를 추가해준다.

3. kvno test

A클러스터 에서 keytab으로 인증을 받고 B cluster서버에 kvno로 접근이 되는지 테스트 해본다.

kinit -kt <A keytab> <A principal>
kvno <B principal>

B클러스터 에서 keytab으로 인증을 받고 A cluster서버에 kvno로 접근이 되는지 테스트 해본다.

kvno 값이 정수로 잘 출력이 된다면, 정상적으로 cross realm 구성이 완료된 것이다.

4. auth to local Rule 추가

/etc/krb5.conf 가 변경되면, 관련된 모듵 컴포넌트를(HBase, HDFS, YARN)재시작 해주어야하는데 이때 모든 component의 A cluster에는 core-site.xml에 아래와 같은 config를 추가해주어야 한다.

core-site.xml
<property>
    <name>hadoop.security.auth_to_local</name>
    <value>RULE: [1:$1@$0](.*@\QCENTOS.YJ.COM\E$)s/@\QCENTOS.YJ.COM\E$//
    RULE: [2:$1@$0](.*@\QCENTOS.YJ.COM\E$)s/@\QCENTOS.YJ.COM$//
    DEFAULT</value>
</property>

B cluster에는 아래를 추가해준다.

core-site.xml
<property>
    <name>hadoop.security.auth_to_local</name>
    <value>RULE: [1:$1@$0](.*@\QUBUNTU.YJ.COM\E$)s/@\QUBUNTU.YJ.COM\E$//
    RULE: [2:$1@$0](.*@\QUBUNTU.YJ.COM\E$)s/@\QUBUNTU.YJ.COM$//
    DEFAULT</value>
</property>

auth_to_local에 문법에 대한 이해는 이곳을 참조한다.

5. test

이후 재시작이 완료되면, A cluster에서 B cluster로 또는 B cluster에서 A cluster로의 export snapshot, replication 설정, verify replication 과 같은 migration 작업을 진행할 수 있다.

Reference

How to Configure Cross Realm Trust for HBase

Background

If two Hadoop clusters with Kerberos applied have different REALMs, data transfer between the two clusters is theoretically impossible. However, by configuring Cross Realm Trust, it becomes possible to query data across clusters or freely move data between them.

Prerequisite

We will assume that there are two clusters, A and B, with Kerberos already applied. Cluster A belongs to the UBUNTU.YJ.COM realm, and Cluster B belongs to the CENTOS.YJ.COM realm. Each cluster has Zookeeper, HDFS, HBase, and YARN components.

Steps

1. Creating krbtgt

In cross realm setups, the principal named krbtgt is extremely important.

Register the following two principals in the UBUNTU.YJ.COM KDC:

krbtgt/UBUNTU.YJ.COM@CENTOS.YJ.COM krbtgt/CENTOS.YJ.COM@UBUNTU.YJ.COM

Similarly, register the following two principals in the CENTOS.YJ.COM KDC:

krbtgt/UBUNTU.YJ.COM@CENTOS.YJ.COM krbtgt/CENTOS.YJ.COM@UBUNTU.YJ.COM

The encryption type, password, and kvno of all four principals must be identical.

2. Updating /etc/krb5.conf and /etc/hosts

On servers belonging to the UBUNTU.YJ.COM realm, you need to add the CENTOS.YJ.COM related configuration to /etc/krb5.conf as follows.

krb5.conf
[libdefaults]
  default_realm = UBUNTU.YJ.COM
[realms]
  UBUNTU.YJ.COM = {
    kdc = kdc01.hadoop.example.com:88
    admin_server = kdc01.hadoop.example.com:749
    default_domain = ubuntu.yj.com
  }
  CENTOS.YJ.COM = {
    kdc = kdc01.example.com:88
    admin_server = kdc01.example.com:749
    default_domain = centos.yj.com
  }
[domain_realm]
  .ubuntu.yj.com = UBUNTU.YJ.COM
  ubuntu.yj.com = UBUNTU.YJ.COM
  .centos.yj.com = CENTOS.YJ.COM
  centos.yj.com = CENTOS.YJ.COM

On servers belonging to the CENTOS.YJ.COM realm, you need to add the UBUNTU.YJ.COM related configuration to /etc/krb5.conf as follows.

krb5.conf
[libdefaults]
  default_realm = CENTOS.YJ.COM
[realms]
  CENTOS.YJ.COM = {
    kdc = kdc01.example.com:88
    admin_server = kdc01.example.com:749
    default_domain = centos.yj.com
  }
  UBUNTU.YJ.COM = {
    kdc = kdc01.hadoop.example.com:88
    admin_server = kdc01.hadoop.example.com:749
    default_domain = ubuntu.yj.com
  }

[domain_realm]
  .centos.yj.com = CENTOS.YJ.COM
  centos.yj.com = CENTOS.YJ.COM
  .ubuntu.yj.com = UBUNTU.YJ.COM
  ubuntu.yj.com = UBUNTU.YJ.COM

Also, add the information about the other cluster's servers to /etc/hosts.

3. kvno test

Authenticate with a keytab on Cluster A and test whether you can access Cluster B's server using kvno.

kinit -kt <A keytab> <A principal>
kvno <B principal>

Authenticate with a keytab on Cluster B and test whether you can access Cluster A's server using kvno.

If the kvno value is displayed as an integer properly, the cross realm configuration has been completed successfully.

4. Adding auth to local Rules

When /etc/krb5.conf is changed, all related components (HBase, HDFS, YARN) must be restarted. At this time, the following config must be added to core-site.xml on Cluster A.

core-site.xml
<property>
    <name>hadoop.security.auth_to_local</name>
    <value>RULE: [1:$1@$0](.*@\QCENTOS.YJ.COM\E$)s/@\QCENTOS.YJ.COM\E$//
    RULE: [2:$1@$0](.*@\QCENTOS.YJ.COM\E$)s/@\QCENTOS.YJ.COM$//
    DEFAULT</value>
</property>

Add the following to Cluster B.

core-site.xml
<property>
    <name>hadoop.security.auth_to_local</name>
    <value>RULE: [1:$1@$0](.*@\QUBUNTU.YJ.COM\E$)s/@\QUBUNTU.YJ.COM\E$//
    RULE: [2:$1@$0](.*@\QUBUNTU.YJ.COM\E$)s/@\QUBUNTU.YJ.COM$//
    DEFAULT</value>
</property>

For understanding the auth_to_local syntax, refer to this page.

5. test

Once the restart is complete, you can proceed with migration tasks such as export snapshot, replication setup, and verify replication from Cluster A to Cluster B or from Cluster B to Cluster A.

Reference

Quiz

Q1: What is the main topic covered in "How to Configure Cross Realm Trust for HBase"?

How to configure cross realm trust for HBase

Q2: What is Creating krbtgt? In cross realm setups, the principal named krbtgt is extremely important. Register the following two principals in the UBUNTU.YJ.COM KDC: krbtgt/UBUNTU.YJ.COM@CENTOS.YJ.COM krbtgt/CENTOS.YJ.COM@UBUNTU.YJ.COM Similarly, register the following two principals in the CENTOS.YJ.COM KD...

Q3: Explain the core concept of Updating /etc/krb5.conf and /etc/hosts. On servers belonging to the UBUNTU.YJ.COM realm, you need to add the CENTOS.YJ.COM related configuration to /etc/krb5.conf as follows. On servers belonging to the CENTOS.YJ.COM realm, you need to add the UBUNTU.YJ.COM related configuration to /etc/krb5.conf as follows.

Q4: What are the key aspects of kvno test? Authenticate with a keytab on Cluster A and test whether you can access Cluster B's server using kvno. Authenticate with a keytab on Cluster B and test whether you can access Cluster A's server using kvno.

Q5: How does Adding auth to local Rules work? When /etc/krb5.conf is changed, all related components (HBase, HDFS, YARN) must be restarted. At this time, the following config must be added to core-site.xml on Cluster A. Add the following to Cluster B. For understanding the auth_to_local syntax, refer to this page>).