Kerberosベストプラクティス
ユーザーが複数のデータソース間でDorisを使用して連携分析クエリを実行する場合、異なるクラスターで異なるKerberos認証資格情報を使用する可能性があります。
大手ファンド会社を例に取ります。その内部データプラットフォームは複数の機能クラスターに分割され、異なる技術チームまたはビジネスチームによって維持され、それぞれが独立したKerberos Realmsでアイデンティティ認証とアクセス制御のために構成されています:
- 本番クラスターは日次純資産価値計算とリスク評価に使用され、認可されたサービスアクセスのみを許可する厳格に分離されたデータを持ちます(Realm: PROD.FUND.COM)。
- 分析クラスターは戦略研究とモデルバックテストに使用され、DorisはTVFを通じてこのクラスターに一時的なクエリを実装します(Realm: ANALYSIS.FUND.COM)。
- データレイククラスターはIceberg カタログを統合して大量の履歴市場データ、ログ、その他のデータのアーカイブと分析を行います(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、およびその他の機能で個別に有効にする必要がある場合は、それらのpropertiesで直接設定できます:
"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 Catalogを作成する方法を紹介します。
環境説明
-
Dorisが提供するKerberosサービスを使用(HIVEを2セット、KDCを2セット):
-
Docker起動ディレクトリ:
docker/thirdparties -
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 IPsを記述する。 -
[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がTGT(Ticket Granting Ticket)を見つけられません。以前動作していた設定ではチケットが期限切れかKDCが再起動されました。新しい設定では
krb5.confまたはkeytabが不正または破損しています。 - 修正:
krb5.confとkeytabを確認し、チケットが有効であることを確認し、kinitで新しいチケットを取得してください。
- 原因:KerberosがTGT(Ticket Granting Ticket)を見つけられません。以前動作していた設定ではチケットが期限切れかKDCが再起動されました。新しい設定では
-
Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
- 原因:GSS-APIチェックサム失敗;
kinitで間違ったパスワードを使用;keytabが無効または古いキーバージョンのためJVMがパスワードログインにフォールバックしています。 - 修正:
kinitで正しいパスワードを使用し、keytabが最新かつ有効であることを確認してください。
- 原因:GSS-APIチェックサム失敗;
-
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
- 原因: プリンシパルがkeytabと一致しないか、アプリケーションが
krb5.confまたはkeytabを読み取れない。 - 修正方法:
klist -kt <keytab_file>とkinit -kt <keytab_file> <principal>を使用してkeytabとプリンシパルを検証する。- ランタイムユーザーが読み取れるように
krb5.confとkeytabのパスと権限を確認する。 - JVM起動オプションで正しい設定パスが指定されていることを確認する。
- 原因: プリンシパルがkeytabと一致しないか、アプリケーションが
-
Principal not found or Could not resolve Kerberos principal name
- 原因:
- プリンシパル内のホスト名を解決できない。
_HOSTプレースホルダーがKDCに未知のホスト名に展開される。- DNSまたは
/etc/hostsが誤って設定されている。
- 修正方法:
- プリンシパルのスペルを確認する。
- 関連するすべてのノード(Doris FE/BEおよびKDC)に正しいホスト名からIPへのエントリがあることを確認する。
- 原因:
-
Cannot find KDC for realm "XXX"
- 原因: 指定されたレルムに
krb5.confでKDCが設定されていない。 - 修正方法:
[realms]の下のレルム名を確認する。kdcアドレスを確認する。/etc/krb5.confを変更後、BEとFEを再起動する。
- 原因: 指定されたレルムに
-
Request is a replay
- 原因: KDCが認証リクエストが重複していると判断している。典型的な理由: ノード間のクロックスキューまたは同じプリンシパルを共有する複数のサービス。
- 修正方法:
- すべてのノードでNTPを有効にして時刻を同期させる。
- 共有を避けるため、
service/_HOST@REALMなどサービスインスタンスごとに一意のプリンシパルを使用する。
- Client not found in Kerberos database
- 原因: クライアントプリンシパルがKerberosデータベースに存在しない。
- 修正方法: KDCでプリンシパルを作成する。
- Message stream modified (41)
- 原因: 特定のOS(例: CentOS 7)でKerberos/Javaの組み合わせにおける既知の問題。
- 修正方法: ベンダーパッチまたはセキュリティアップデートを適用する。
- Pre-authentication information was invalid (24)
- 原因:
- 無効な事前認証データ。
- クライアントとKDC間のクロックスキュー。
- JDK暗号設定とKDCの不一致。
- 修正方法:
- すべてのノードで時刻を同期する。
- 暗号設定を合わせる。