3

CDH 4.3 (Cloudera Manager 経由) のテスト ベッドで Kerberos を有効にしようとしていました。そのため、WebUI で認証を Simple から Kerberos に変更した後、以下に示すように Hadoop 操作を実行できません。キータブを明示的に指定する方法はありますか?

[root@host-dn15 ~]# su - hdfs
-bash-4.1$ hdfs dfs -ls /
13/09/10 08:15:35 ERROR security.UserGroupInformation: PriviledgedActionException as:hdfs (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
13/09/10 08:15:35 WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
13/09/10 08:15:35 ERROR security.UserGroupInformation: PriviledgedActionException as:hdfs (auth:KERBEROS) cause:java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
ls: Failed on local exception: java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]; Host Details : local host is: "host-dn15.hadoop.com/192.168.10.227"; destination host is: "host-dn15.hadoop.com":8020;
-bash-4.1$ kdestroy
-bash-4.1$ kinit
Password for hdfs@HADOOP.COM:
-bash-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM

Valid starting     Expires            Service principal
09/10/13 08:20:31  09/11/13 08:20:31  krbtgt/HADOOP.COM@HADOOP.COM
    renew until 09/10/13 08:20:31

-bash-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM

Valid starting     Expires            Service principal
09/10/13 08:20:31  09/11/13 08:20:31  krbtgt/HADOOP.COM@HADOOP.COM
    renew until 09/10/13 08:20:31, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
-bash-4.1$

そこでnamenodeのログをよく見てみると、

2013-09-10 10:02:06,085 INFO org.apache.hadoop.ipc.Server: IPC Server listener on 8022: readAndProcess threw exception javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)] from client 10.132.100.228. Count of bytes read: 0
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]

JCE ポリシー ファイルは、すべてのノードにすでにインストールされています。

[root@host-dn15 security]# sha256sum ./local_policy.jar
4a5c8f64107c349c662ea688563e5cd07d675255289ab25246a3a46fc4f85767  ./local_policy.jar
[root@host-dn15 security]# sha256sum ./US_export_policy.jar
b800fef6edc0f74560608cecf3775f7a91eb08d6c3417aed81a87c6371726115  ./US_export_policy.jar
[root@host-dn15 security]# sha256sum ./local_policy.jar.bak
7b26d0e16722e5d84062240489dea16acef3ea2053c6ae279933499feae541ab  ./local_policy.jar.bak
[root@host-dn15 security]# sha256sum ./US_export_policy.jar.bak
832133c52ed517df991d69770f97c416d2e9afd874cb4f233a751b23087829a3  ./US_export_policy.jar.bak
[root@host-dn15 security]#

そして、レルム内のプリンシパルのリスト。

kadmin:  listprincs
HTTP/host-dn15.hadoop.com@HADOOP.COM
HTTP/host-dn16.hadoop.com@HADOOP.COM
HTTP/host-dn17.hadoop.com@HADOOP.COM
K/M@HADOOP.COM
cloudera-scm/admin@HADOOP.COM
hbase/host-dn15.hadoop.com@HADOOP.COM
hbase/host-dn16.hadoop.com@HADOOP.COM
hbase/host-dn17.hadoop.com@HADOOP.COM
hdfs/host-dn15.hadoop.com@HADOOP.COM
hdfs/host-dn16.hadoop.com@HADOOP.COM
hdfs/host-dn17.hadoop.com@HADOOP.COM
hdfs@HADOOP.COM
hue/host-dn15.hadoop.com@HADOOP.COM
host-dn16/hadoop.com@HADOOP.COM
kadmin/admin@HADOOP.COM
kadmin/changepw@HADOOP.COM
kadmin/host-dn15.hadoop.com@HADOOP.COM
krbtgt/HADOOP.COM@HADOOP.COM
mapred/host-dn15.hadoop.com@HADOOP.COM
mapred/host-dn16.hadoop.com@HADOOP.COM
mapred/host-dn17.hadoop.com@HADOOP.COM
root/admin@HADOOP.COM
root@HADOOP.COM
zookeeper/host-dn15.hadoop.com@HADOOP.COM
kadmin:  exit
[root@host-dn15 ~]#

hdfs のキータブをエクスポートし、kinit に使用しました。

-bash-4.1$ kinit -kt ./hdfs.keytab hdfs
-bash-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM

Valid starting     Expires            Service principal
09/10/13 09:49:42  09/11/13 09:49:42  krbtgt/HADOOP.COM@HADOOP.COM
    renew until 09/10/13 09:49:42

すべてが無駄になりました。何か案が？？

よろしくお願いします。

4

1 に答える 1

2

Kerberos 化された CDH クラスターがあり、有効な Kerberos チケットがあっても、コマンド ラインから Hadoop コマンドを実行できないという問題に遭遇しました。

注:この回答を書いた後、http://sarastreeter.com/2016/09/26/resolving-hadoop-problems-on-kerberized-cdh-5-x/にブログ投稿として書きました。共有してください！

したがって、有効なチケットがあっても、これは失敗します。

$ hadoop fs -ls /

WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

これが私が学んだことと、どのようにして問題を解決したかです。可能であれば現在のバージョンの Cloudera ドキュメントにリンクしましたが、一部のドキュメントは古いバージョンにのみ存在するようです。

問題は構成の問題に帰着しますが、Kerberos 自体と Cloudera Manager の両方が正しくインストールされていることに注意してください。答えを探しているときに出くわした問題の多くは、Kerberos または Hadoop が正しくインストールされていないことが原因でした。Hadoop と Kerberos の両方が機能していたにもかかわらず、私が発生した問題は、適切に連携するように構成されていませんでした。

TL;DR

チケットを持っていることを確認してください

klisthadoop コマンドを実行しようとしているユーザーからaを実行します。

$ sudo su - myuser
$ klist

チケットがない場合は、次のように印刷されます。

klist: Credentials cache file '/tmp/krb5cc_0' not found

チケットなしで hadoop コマンドを実行しようとすると、仕様GSS INITIATE FAILEDによりエラーが発生します。

WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

つまり、これはインストールの問題ではありません。これがあなたの状況である場合は、以下をご覧ください。

CDH デフォルト HDFS ユーザーおよびグループの制限

Cloudera のデフォルト インストールには、hadoop コマンドの実行に対するユーザーおよびグループの制限があり、特定のユーザーに対する特定の禁止が含まれます (詳細はhttp://www.cloudera.com/documentation/enterprise/5-6-x/PDFの 57 ページを参照)。 /cloudera-security.pdf )。

supergrouphdfs のスーパーグループがではなく文字列に設定されているhdfs、dfs_permissions enabledプロパティがfalseデフォルトで設定されている ( hadoop ユーザー ファイル アクセス許可)、uid が 1000 を超えるユーザーが禁止されているなど、これに対処するプロパティがいくつかあります。

これらのいずれかが要因である可能性があります。私にとっては、banned.users プロパティにリストされているのは HDFS でした。

特にユーザー HDFS の場合、hdfs-site.xml 構成のbanned.users 構成プロパティから hdfs を削除したことを確認してください。これを使用して hadoop コマンドを実行しようとしている場合。

  1) UNPRIVILEGED USER AND WRITE PERMISSIONS

Cloudera が推奨する Hadoop コマンドの実行方法は、hdfs ユーザーを使用する代わりに、権限のないユーザーと一致するプリンシパルを作成することです。落とし穴は、このユーザーにも独自の/userディレクトリが必要であり、/user ディレクトリで書き込み権限エラーが発生する可能性があることです。権限のないユーザーが にディレクトリを持っていない場合/user、WRITE アクセス許可が拒否されたというエラーが発生する可能性があります。

Cloudera ナレッジ記事

http://community.cloudera.com/t5/CDH-Manual-Installation/How-to-resolve-quot-Permission-denied-quot-errors-in-CDH/ta-p/36141

  2) DATANODE PORTS AND DATA DIR PERMISSIONS

もう 1 つの関連する問題は、Cloudera が非 kerberized クラスターで dfs.datanode.data.dir を 750 に設定するが、kerberized クラスターでは 700 を必要とすることです。間違ったディレクトリ権限が設定されていると、Kerberos のインストールは失敗します。データノードのポートも 1024 未満の値に設定する必要があります。これは、HTTP ポートの場合は 1006、データノード ポートの場合は 1004 として推奨されます。

データノード ディレクトリ

http://www.cloudera.com/documentation/enterprise/5-6-x/topics/cdh_ig_hdfs_cluster_deploy.html

データノード ポート

http://www.cloudera.com/documentation/archive/manager/4-x/4-7-2/Configuring-Hadoop-Security-with-Cloudera-Manager/cmchs_enable_security_s9.html

  3) SERVICE-SPECIFIC CONFIGURATION TASKS

セキュリティ ドキュメントの 60 ページに、Hadoop サービスを kerberize する手順が記載されています。あなたがこれらをしたことを確認してください！

MapReduce 
$ sudo -u hdfs hadoop fs -chown mapred:hadoop ${mapred.system.dir}
HBase 
$ sudo -u hdfs hadoop fs -chown -R hbase ${hbase.rootdir}
ハイブ 
$ sudo -u hdfs hadoop fs -chown hive /user/hive
糸 
$ rm -rf ${yarn.nodemanager.local-dirs}/usercache/*

これらのすべてのステップは、YARN の場合を除き、いつでも実行できます。YARN の手順は、Kerberos のインストール後に実行する必要があります。これは、Kerberos 化されていない YARN データのユーザー キャッシュを削除するためです。Kerberos のインストール後に mapreduce を実行すると、これに Kerberos 化されたユーザー キャッシュ データが入力されます。

YARN ユーザーキャッシュ

YARN アプリケーションが exitCode: -1000 で終了しました ユーザー ディレクトリを初期化できません

ケルベロスの主な問題

  1) SHORT NAME RULES MAPPING

Kerberos プリンシパルは、OS レベルのサービス ユーザーに「マップ」されます。たとえば、hdfs/WHATEVER@REALM は、Hadoop のコア サイトに設定された名前マッピング ルールによってのみ、オペレーティング システムのサービス ユーザー 'hdfs' にマップされます。ネーム マッピングがなければ、Hadoop は、どのユーザーがどのプリンシパルによって認証されているかを認識できません。

hdfs にマップするプリンシパルを使用している場合は、これらの Hadoop ルールに従って、プリンシパル名が hdfs に正しく解決されることを確認してください。

良い

(デフォルトで名前マッピング規則があります)

  • hdfs@REALM
  • hdfs/_HOST@REALM
悪い

(デフォルトではネーム マッピング ルールはありません)

  • hdfs-TAG@REALM

「悪い」例は、それに対応するルールを追加しない限り機能しません

名前規則のマッピング

http://www.cloudera.com/documentation/archive/cdh/4-x/4-5-0/CDH4-Security-Guide/cdh4sg_topic_19.html )

  2) KEYTAB AND PRINCIPAL KEY VERSION NUMBERS MUST MATCH

キー バージョン番号 (KVNO) は、アクティブに使用されているキーのバージョンです (家のキーを持っていたが、ドアのロックを変更して新しいキーを使用した場合、古いキーはもう役に立たない場合など)。 . キータブとプリンシパルの両方に KVNO があり、バージョン番号が一致している必要があります。

デフォルトでは、ktadd または xst を使用してプリンシパルをキータブにエクスポートすると、キータブのバージョン番号は変更されますが、プリンシパルの KVNO は変更されません。そのため、誤ってミスマッチを作成してしまう可能性があります。

キータブ番号の更新と KVNO の不一致の作成を回避するために、プリンシパルをキータブにエクスポートするときに、 またはキータブにエクスポートするときに使用-norandkeyします。kadminkadmin.local

一般に、プリンシパルに認証の問題がある場合は常に、プリンシパルとキータブの KVNO が一致していることを確認してください。

主要 
$ kadmin.local -q 'getprinc myprincipalname'
キータブ 
$ klist -kte mykeytab
プリンシパルの作成

http://www.cloudera.com/documentation/archive/cdh/4-x/4-3-0/CDH4-Security-Guide/cdh4sg_topic_3_4.html

セキュリティ jar と Java ホーム

  1) JAVA VERSION MISMATCH WITH JCE JARS

Kerberos で AES-256 暗号化を使用するには、Hadoop に Java セキュリティ JCE Unlimited Strength jar をインストールする必要があります。Hadoop と Kerberos の両方がこれらの jar にアクセスできる必要があります。これはインストールの問題ですが、実際にはインストールされていないのにセキュリティ jar がインストールされていると考えることができるため、見逃しがちです。

確認する JCE 構成:
  • jar は正しいバージョンです - 正しいセキュリティ jar は Java にバンドルされていますが、実際にインストールした後に jar のバージョンが Java のバージョンに対応していることを確認する必要があります。そうしないと、引き続きエラーが発生します。トラブルシューティングを行うには、使用している JDK の新しいダウンロードからの md5sum ハッシュを、Kerberos サーバー上のものの md5sum ハッシュと比較して確認します。
  • 瓶は正しい場所にあります$JAVA_HOME/jre/lib/security
  • Hadoop は、適切な場所でそれらを探すように構成されています。$JAVA_HOMEの正しい Java インストール場所へのエクスポート ステートメントがあるかどうかを確認します。/etc/hadoop/conf/hadoop-env.sh

Hadoop がJAVA_HOME正しく設定されていない場合、「GSS INITIATE FAILED」で失敗します。jar が適切な場所にない場合、Kerberos はそれらを見つけられず、AES-256 暗号化タイプ (UNSUPPORTED ENCTYPE) をサポートしていないというエラーを返します。

Cloudera と JCE Jars

http://www.cloudera.com/documentation/enterprise/5-5-x/topics/cm_sg_s2_jce_policy.html

JCE Jar のトラブルシューティング

https://community.cloudera.com/t5/Cloudera-Manager-Installation/Problem-with-Kerberos-amp-user-hdfs/td-p/6809

JDK 6 および MIT KERBEROS 1.8.1 以降でのチケットの更新

Cloudera には、http: //www.cloudera.com/documentation/archive/cdh/3-x/3u6/CDH3-Security-Guide/cdh3sg_topic_14_2.html に記載されている問題があり、 hadoop コマンドを発行する前にチケットを更新する必要があります。これは、Oracle JDK 6 Update 26 以前およびパッケージ バージョン 1.8.1 以降の MIT Kerberos ディストリビューションでのみ発生します。

パッケージを確認するには、rpm -qa | grep krb5CentOS/RHEL またはaptitude search krb5 -F "%c %p %d %V"Debian/Ubuntu で実行します。

したがって、通常の kinit を実行してkinit -Rから、チケットを強制的に更新するために a を実行します。

$ kinit -kt mykeytab myprincipal
$ kinit -R

そして最後に、どこにも文書化されていない私が実際に抱えていた問題...

構成ファイルとチケットのキャッシュ

krb5.confKerberos には、と kdc.confという 2 つの重要な構成ファイルがあります。これらは、krb5kdc サービスと KDC データベースの構成です。私の問題は、krb5.confファイルにプロパティがあったことでした: default_ccache_name = KEYRING:persistent:%{uid}.

これにより、キャッシュ名が KEYRING:persistent およびユーザー uid に設定されます ( https://web.mit.edu/kerberos/krb5-1.13/doc/basic/ccache_def.htmlで説明)。kinit を実行すると、キャッシュ名が別の場所で /tmp として設定されていたため、チケットが /tmp に作成されました。Cloudera サービスは、実行時に /var/run/cloudera-scm-agent/process で生成されるファイルを使用して認証を取得し、これらはすべて、実行前にキャッシュ名環境変数 (KRB5CCNAME) をエクスポートしますkinit。そのため、Cloudera はチケットを取得できましたが、私の Hadoop ユーザーは取得できませんでした。

解決策は、default_ccache_name を設定し、kinit が資格情報を に保存できるようにする行を krb5.conf から削除すること/tmpでした。 /mitK5defaults.html#paths )。

Cloudera および Kerberos インストール ガイド:

ステップバイステップ

https://www.cloudera.com/documentation/enterprise/5-6-x/topics/cm_sg_intro_kerb.html .

高度なトラブルシューティング

http://www.cloudera.com/documentation/enterprise/5-6-x/PDF/cloudera-security.pdfの 48 ページから。

于 2016-09-26T16:04:41.713 に答える