バージョン: 4.x

Kerberos ベストプラクティス

ユーザーが複数のデータソースにわたる連合分析クエリにDorisを使用する場合、異なるクラスタは異なるKerberos認証資格情報を使用する可能性があります。

大手ファンド会社を例に取ります。その内部データプラットフォームは複数の機能クラスタに分割され、異なる技術チームまたはビジネスチームによって保守され、それぞれがアイデンティティ認証とアクセス制御のために独立したKerberos Realmsで構成されています：

Productionクラスタは日々の純資産価値計算とリスク評価に使用され、厳格に分離されたデータで認証されたサービスアクセスのみを許可します（Realm: PROD.FUND.COM）。
Analysisクラスタは戦略研究とモデルバックテストに使用され、DorisがTVFを通じてこのクラスタへの一時的なクエリを実行します（Realm: ANALYSIS.FUND.COM）。
Data lakeクラスタはIceberg Catalogを統合し、大量の履歴市場データ、ログ、その他のデータをアーカイブおよび分析します（Realm: LAKE.FUND.COM）。

これらのクラスタはクロスドメイン信頼関係を確立しておらず、認証情報を共有できないため、これらの異種データソースへの統一アクセスには、複数のKerberosインスタンスの認証とコンテキスト管理の同時サポートが必要です。

本ドキュメントは、マルチKerberos環境でデータソースを構成およびアクセスする方法に焦点を当てています。

この機能は3.1+以降でサポートされています

マルチKerberosクラスタ認証設定

krb5.conf

krb5.confにはKerberos設定情報、KDCの場所、Kerberosサービスのデフォルト値、およびホスト名からRealmへのマッピング情報が含まれています。

krb5.confを適用する際は、すべてのノードに配置されていることを確認してください。デフォルトの場所は/etc/krb5.confです。

realms

EXAMPLE.COMなど、多くのクライアントのKDCとKerberosネットワークが含まれています。

複数のクラスタを設定する場合、1つのkrb5.confで複数のRealmsを設定する必要があります。KDCとadmin_serverもドメイン名にすることができます。

[realms]
EMR-IP.EXAMPLE = {
    kdc = 172.21.16.8:88
    admin_server = 172.21.16.8
}
EMR-HOST.EXAMPLE = {
    kdc = emr_hostname
    admin_server = emr_hostname
}

domain_realm

Kerberosサービスが配置されているノードに対して、ドメインからRealmへのマッピングを設定します。

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
[domain_realm]
172.21.16.8 = EMR-IP.EXAMPLE
emr-host.example = EMR-HOST.EXAMPLE

例えば、プリンシパルemr1/domain_name@realm.comの場合、KDCを検索する際にdomain_nameを使用して対応するRealmを見つけます。一致しない場合、そのRealmのKDCを見つけることができません。

通常、domain_realmに関連する2つのタイプのエラーがDorisのlog/be.outまたはlog/fe.outで確認できます：

* Unable to locate KDC for realm/Cannot locate KDC

* No service creds

keytab and principal

マルチKerberosクラスタ環境では、keytabファイルは通常異なるパスを使用します。例：/path/to/serverA.keytab、/path/to/serverB.keytab。異なるクラスタにアクセスする際は、対応するkeytabを使用する必要があります。

HDFSクラスタでKerberos認証が有効になっている場合、通常core-site.xmlファイルでhadoop.security.auth_to_localプロパティを確認できます。これはKerberosプリンシパルをより短いローカルユーザー名にマッピングするために使用され、HadoopはKerberos構文ルールを再利用します。

設定されていない場合、NoMatchingRule("No rules applied to例外が発生する可能性があります。コードを参照してください：

hadoop/src/core/org/apache/hadoop/security/KerberosName.java

hadoop.security.auth_to_localパラメータには、プリンシパルをRULEsと上から下へマッチングする一連のマッピングルールが含まれています。一致するマッピングルールが見つかると、ユーザー名を出力し、一致しないルールは無視されます。具体的な設定形式：

RULE:[<principal translation>](acceptance filter)<short name substitution>

複数クラスター環境で異なるKerberosサービスによって使用されるプリンシパルを照合するには、推奨される設定は以下の通りです：

<property>
    <name>hadoop.security.auth_to_local</name>
    <value>RULE:[1:$1@$0](^.*@.*$)s/^(.*)@.*$/$1/g
           RULE:[2:$1@$0](^.*@.*$)s/^(.*)@.*$/$1/g
           DEFAULT</value>
</property>

上記の設定は、core-site.xml 内の hadoop.security.auth_to_local プロパティを追加または置換するために使用できます。core-site.xml を fe/conf と be/conf に配置して、Doris 環境で有効にしてください。

OUTFILE、EXPORT、Broker Load、Catalog（Hive、Iceberg、Hudi）、TVF、およびその他の機能で個別に有効にする必要がある場合は、それらのプロパティで直接設定できます：

"hadoop.security.auth_to_local" = "RULE:[1:$1@$0](^.*@.*$)s/^(.*)@.*$/$1/g
                                   RULE:[2:$1@$0](^.*@.*$)s/^(.*)@.*$/$1/g
                                   DEFAULT"

マッピングルールが正しくマッチするかどうかを確認するには、異なるクラスターにアクセスする際にこのエラーが発生するかどうかをチェックしてください：

NoMatchingRule: No rules applied to hadoop/domain\_name@EMR-REALM.COM

表示された場合は、マッチングが失敗したことを示しています。

ベストプラクティス

このセクションでは、Apache Doris公式リポジトリが提供するDocker環境を使用して、DockerでKerberosを使用したHive/HDFSサービスを開始し、DorisからKerberos対応のHive Catalogsを作成する方法を紹介します。

環境の説明

Dorisが提供するKerberosサービスを使用（2セットのHIVE、2セットのKDC）：
- Docker起動ディレクトリ：docker/thirdparties
- krb5.confテンプレート：
  
  docker-compose/kerberos/common/conf/doris-krb5.conf

1. keytabファイルと権限の準備

keytabファイルをローカルディレクトリにコピー：

mkdir -p ~/doris-keytabs
cp <hive-presto-master.keytab> ~/doris-keytabs/
cp <other-hive-presto-master.keytab> ~/doris-keytabs/

認証の失敗を防ぐためにファイルのアクセス許可を設定してください：

chmod 400 ~/doris-keytabs/*.keytab

2. krb5.confファイルの準備

Dorisが提供するkrb5.confテンプレートファイルを使用する
複数のKerberos HDFSクラスターに同時にアクセスする必要がある場合は、krb5.confをマージする必要があり、基本要件は以下の通りです：
- [realms]：すべてのクラスターのRealmsとKDC IPを記述する。
- [domain_realm]：ドメインまたはIPからRealmへのマッピングを記述する。
- [libdefaults]：統一された暗号化アルゴリズム（des3-cbc-sha1など）。

例：

[libdefaults]
    default_realm = LABS.TERADATA.COM
    allow_weak_crypto = true
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]
    LABS.TERADATA.COM = {
        kdc = 127.0.0.1
        admin_server = 127.0.0.1
    }
    OTHERREALM.COM = {
        kdc = 127.0.0.1
        admin_server = 127.0.0.1
    }

[domain_realm]
    presto-master.docker.cluster = LABS.TERADATA.COM
    hadoop-master-2 = OTHERREALM.COM
    .labs.teradata.com = LABS.TERADATA.COM
    .otherrealm.com = OTHERREALM.COM

krb5.confを対応するDockerディレクトリにコピーします：
```
cp doris-krb5.conf ~/doris-kerberos/krb5.conf
```

3. Docker Kerberos環境の開始

ディレクトリに移動:
```
cd docker/thirdparties
```

Kerberos環境を開始する:

./run-thirdparties-docker.sh -c kerberos

起動後のサービスには以下が含まれます：
- Hive Metastore 1:9583
- Hive Metastore 2:9683
- HDFS 1:8520
- HDFS 2:8620

4. コンテナIPの取得

DockerのIPを確認するコマンドを使用します：

docker inspect <container-name> | grep IPAddress

または、127.0.0.1を直接使用してください（サービスがホストネットワークにマッピングされていることが前提です）。

5. Kerberos Hive Catalogの作成

Hive Catalog1

CREATE CATALOG IF NOT EXISTS multi_kerberos_one
PROPERTIES (
"type" = "hms",
"hive.metastore.uris" = "thrift://127.0.0.1:9583",
"fs.defaultFS" = "hdfs://127.0.0.1:8520",
"hadoop.kerberos.min.seconds.before.relogin" = "5",
"hadoop.security.authentication" = "kerberos",
"hadoop.kerberos.principal" = "hive/presto-master.docker.cluster@LABS.TERADATA.COM",
"hadoop.kerberos.keytab" = "/mnt/disk1/gq/keytabs/keytabs/hive-presto-master.keytab",
"hive.metastore.sasl.enabled " = "true",
"hadoop.security.auth_to_local" = "RULE:[2:$1@$0](.*@LABS.TERADATA.COM)s/@.*//
                                    RULE:[2:$1@$0](.*@OTHERLABS.TERADATA.COM)s/@.*//
                                    RULE:[2:$1@$0](.*@OTHERREALM.COM)s/@.*//
                                    DEFAULT",
"hive.metastore.kerberos.principal" = "hive/hadoop-master@LABS.TERADATA.COM"
);

Hive Catalog2

CREATE CATALOG IF NOT EXISTS multi_kerberos_two
PROPERTIES (
"type" = "hms",
"hive.metastore.uris" = "thrift://127.0.0.1:9683",
"fs.defaultFS" = "hdfs://127.0.0.1:8620",
"hadoop.kerberos.min.seconds.before.relogin" = "5",
"hadoop.security.authentication" = "kerberos",
"hadoop.kerberos.principal" = "hive/presto-master.docker.cluster@OTHERREALM.COM",
"hadoop.kerberos.keytab" = "/mnt/disk1/gq/keytabs/keytabs/other-hive-presto-master.keytab",
"hive.metastore.sasl.enabled " = "true",
"hadoop.security.auth_to_local" = "RULE:[2:$1@$0](.*@OTHERREALM.COM)s/@.*//
                                    RULE:[2:$1@$0](.*@OTHERLABS.TERADATA.COM)s/@.*//
                                    DEFAULT",
"hive.metastore.kerberos.principal" = "hive/hadoop-master-2@OTHERREALM.COM"
);

この時点で、マルチKerberosクラスタアクセス設定が完了します。両方のHiveクラスタからデータを閲覧し、異なるKerberos認証情報を使用できます。

接続テストツール

Kerberosなどの外部依存関係への接続を検証するために、オープンソースツールPulseを使用できます。

Pulseは独立したオープンソースの接続テストツールです。使用方法、インストール詳細、リリース情報については、プロジェクトドキュメントを参照してください。

ドキュメント: Kerberos Connectivity Tool
リリースパッケージ: Kerberos Connectivity Tool v1.0.0

FAQ

javax.security.sasl.SaslException: No common protection layer between client and server
- 原因: クライアントのhadoop.rpc.protectionがHDFSクラスタ設定と異なります。
- 修正: クライアントとHDFSサーバー間でhadoop.rpc.protectionを一致させます。
No valid credentials provided (Mechanism level: Illegal key size)
- 原因: Javaはデフォルトで128ビットより大きい暗号化キーをサポートしていません。
- 修正: Java Cryptography Extension (JCE) Unlimited Strength Policyをインストールし、JARを$JAVA_HOME/jre/lib/securityに展開してサービスを再起動します。
Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled
- 原因: 現在のJava環境にAES256サポートがない一方で、Kerberosがそれを使用している可能性があります。
- 修正: /etc/krb5.confの[libdefaults]でサポートされている暗号を使用するよう更新するか、JCE拡張をインストールしてAES256を有効にします（上記と同様）。
No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
- 原因: Kerberosが有効なTicket Granting Ticket (TGT)を見つけることができません。以前に動作していたセットアップでは、チケットが期限切れになったかKDCが再起動されました。新しいセットアップでは、krb5.confまたはkeytabが正しくないか破損しています。
- 修正: krb5.confとkeytabを確認し、チケットが有効であることを確認し、kinitで新しいチケットを取得してみます。
Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
- 原因: GSS-APIチェックサム失敗；kinitで間違ったパスワードが使用された；keytabが無効であるか古いキーバージョンを持っているため、JVMがパスワードログインにフォールバックしています。
- 修正: kinitで正しいパスワードを使用し、keytabが最新で有効であることを確認します。
Receive timed out
- 原因: 不安定なネットワークまたは大きなパケットでKDCとの通信にUDPを使用しています。
- 修正: /etc/krb5.confに以下を追加してKerberosにTCPの使用を強制します:

[libdefaults]
udp_preference_limit = 1

javax.security.auth.login.LoginException: Unable to obtain password from user
- 原因: Principalがkeytabと一致しないか、アプリケーションがkrb5.confまたはkeytabを読み取れません。
- 修正方法:
  - klist -kt <keytab_file>とkinit -kt <keytab_file> <principal>を使用してkeytabとprincipalを検証してください。
  - 実行時ユーザーが読み取れるように、krb5.confとkeytabのパスと権限を確認してください。
  - JVM起動オプションで正しい設定パスが指定されていることを確認してください。
Principal not found or Could not resolve Kerberos principal name
- 原因:
  - principalのホスト名が解決できません。
  - _HOSTプレースホルダーがKDCに認識されないホスト名に展開されます。
  - DNSまたは/etc/hostsの設定に誤りがあります。
- 修正方法:
  - principalのスペルを確認してください。
  - すべての関連ノード（Doris FE/BEおよびKDC）に正しいホスト名からIPアドレスへのエントリがあることを確認してください。
Cannot find KDC for realm "XXX"
- 原因: 指定されたrealmにkrb5.confでKDCが設定されていません。
- 修正方法:
  - [realms]の下のrealm名を確認してください。
  - kdcアドレスを確認してください。
  - /etc/krb5.confを変更した後、BEとFEを再起動してください。
Request is a replay

原因: KDCが認証リクエストが重複していると判断しています。典型的な理由: ノード間のクロックスキューまたは複数のサービスが同じprincipalを共有している。
修正方法:
- すべてのノードでNTPを有効にして時刻を同期させてください。
- 共有を避けるために、service/_HOST@REALMなどサービスインスタンスごとに一意のprincipalを使用してください。

Client not found in Kerberos database

原因: クライアントprincipalがKerberosデータベースに存在しません。
修正方法: KDCでprincipalを作成してください。

Message stream modified (41)

原因: 特定のOS（例: CentOS 7）とKerberos/Javaの組み合わせで発生する既知の問題。
修正方法: ベンダーパッチまたはセキュリティアップデートを適用してください。

Pre-authentication information was invalid (24)

原因:
- 無効な事前認証データ。
- クライアントとKDC間のクロックスキュー。
- JDK暗号設定がKDCと一致しない。
修正方法:
- すべてのノードで時刻を同期させてください。
- 暗号設定を合わせてください。

マルチKerberosクラスタ認証設定​

krb5.conf​

realms​

domain_realm​

keytab and principal​

ベストプラクティス​

環境の説明​

1. keytabファイルと権限の準備​

2. krb5.confファイルの準備​

3. Docker Kerberos環境の開始​

4. コンテナIPの取得​

5. Kerberos Hive Catalogの作成​

接続テストツール​

FAQ​