1. 統合ガイド
  2. Apache Hadoop MapReduceとの統合
  3. 付録
  4. セキュア・クライアントのビルドおよびパッケージ化のためのモデル

セキュア・クライアントのビルドおよびパッケージ化のためのモデル

セキュア・ストアに格納されているデータに対してMapReduceジョブを実行する場合、特に対処する重要な問題は、Hadoopインフラストラクチャがジョブを実行する各DataNodeで実行されるタスクに対するユーザー資格証明の通信に関連しています。前述したように、Apache Hadoopによって定義されたMapReduceプログラミング・モデルを使用する場合、MapReduceジョブによって実行されるタスクは、それぞれストアのクライアントとして機能します。そのため、ストアがセキュア・アクセス用に構成されている場合、そのストアから目的のデータを取得するには、各タスクがそのデータに関連付けられているユーザーの資格証明にアクセスできることが必要になります。セキュア・ストアのクライアントに必要な資格証明を提供する一般的なメカニズムは、たとえば、scpなどのユーティリティを使用して、クライアントのローカル・ファイル・システムに手動で資格証明をインストールすることです。

この手動メカニズムはセキュア・ストアのほとんどのクライアントに対して実用性がありますが、MapReduceジョブには実用性がありません。その理由は、MapReduceジョブが、個別のアドレス空間でパラレルに実行される複数のタスクで構成されていて、各タスクには一般にユーザーの制御下にない個別のファイル・システムがあるためです。その場合、Hadoop管理者が書込みアクセス権を付与するものと仮定すると(このこと自体が問題)、特定のセキュア・ストアに認識されている可能性のあるすべてのユーザーのクライアント資格証明の手動インストールは、Hadoopクラスタ内の多数のノードのファイル・システムで実行する必要があることになります。これは、実現が非常に困難なことだと考えられます。

この問題に対処するために、開発者およびデプロイヤが、ジョブのクライアント側(つまり、ユーザーが所有するジョブのクライアント・プロセスによって制御されるアドレス空間)から特定のMapReduceジョブへの各ユーザーの資格証明の通信を容易にするために使用できるモデルを提示します。

このモデルは、2つの主要な要素で構成されています。その1つは、セキュア・ストア内の表に格納されているデータを取得して処理するMapReduceジョブを実行するためのプログラミング・モデルです。もう1つは、それらのジョブをビルド、パッケージ化およびデプロイするための一連のベスト・プラクティスです。ユーザーが特定のクラスタ内のすべてのノードに必要なセキュリティ資格証明を手動でインストールすることを防止する要素はありませんが、そうすることは現実的ではなく、様々なセキュリティ脆弱性につながる可能性があります。このプログラミング・モデルを、ここで説明するデプロイメントのベスト・プラクティスと組み合せることで、開発者とデプロイヤがHadoopクラスタのDataNodeに資格証明を手動で事前インストールする必要性をなくすだけでなく、手動インストールで発生する可能性のあるセキュリティ脆弱性の一部も回避できるようになります。

Oracle NoSQL DatabaseセキュリティによるMapReduceのプログラミング・モデル

MapReduceジョブの実行時に、クライアント・アプリケーションはHadoopインフラストラクチャによって提供されるメカニズムを使用して、HadoopクラスタのResourceManagerを実行しているノードにネットワーク・アクセス可能なノード(Hadoopクラスタのアクセス・ノードと呼ばれる)からジョブを開始します。このジョブがセキュア・ストアに対して実行される場合、ジョブの開始前に、クライアントでは次の3つの情報を使用してジョブのTableInputFormatを初期化する必要があります。

  • クライアントがストアへの接続時に使用するトランスポート・プロパティを指定するファイルの名前。このドキュメントでは、このファイルをログイン・プロパティ・ファイル(またはログイン・ファイル)と呼びます。
  • 認証時にクライアントがストアに提示するユーザー名とパスワードを格納しているPasswordCredentials。
  • 認証に必要なパブリック・キーや証明書を格納しているファイルの名前。このドキュメントでは、クライアント信頼ファイル(または信頼ファイル)と呼びます。

このMapReduceクライアント・アプリケーション(ここではCountTableRows)の初期化を実行するには、TableInputFormatで定義されているsetKVSecurityメソッドを呼び出します。この初期化の実行が完了してジョブが開始されると、ジョブは、そのTableInputFormatを使用してTableInputSplit (スプリット)を作成し、クラスタ内のいずれかのDataNodeで実行される各Mapperタスクに割り当てます。TableInputFormatには、次の2つの理由からsetKVSecurityメソッドによって初期化される情報が必要になります。

  • アクセス・ノードからセキュアなストアに接続し、スプリットの作成に必要な情報を取得するため。
  • 同じセキュリティ情報を使用して各スプリットを初期化するため。このような各スプリットがDataNodeホストからセキュア・ストアに接続して、そのスプリットで処理する特定の表データを取得できるようにします。

MapReduceアプリケーションは、ここで説明したメカニズムを使用して、前述の情報によってジョブのTableInputFormat (それによるスプリット)を初期化および構成する必要があることに加えて、このモデルでは、その情報によって参照されるパブリックおよびプライベートのセキュリティ資格証明がTableInputFormatに安全に通信される必要もあります。これを実現する方法は、その情報の通信先が、アプリケーションのクライアント側のTableInputFormatか、サーバー側のスプリットかによって異なります。

サーバー側のスプリットへのセキュリティ資格証明の通信

クラスタの各DataNodeに分散されるスプリットへのユーザーのセキュリティ資格証明の通信を容易にするために、ここに示すモデルでは、パブリック・セキュリティ情報をプライベート情報(ユーザー名とパスワード)から分離し、プライベート情報を、関連する各DataNodeのローカル・ファイル・システムではなく、各スプリットの内部状態の一部として格納します。これは脆弱になるか、セキュリティ保護が困難になる可能性があります。そのようなスプリットごとにログイン・ファイルと信頼ファイルのパブリック・コンテンツを通信するために、このモデルでは、各スプリットがスプリットのJava VMのクラスパスから取得するJavaリソースとして、その情報をアプリケーションが通信できるようにするメカニズム(オプション)をサポートしています。これにより、それらのファイルの内容を各DataNodeのローカル・ファイル・システムに手動で転送する必要がなくなり、そうしたノードへの手動インストールによる潜在的なセキュリティの脆弱性も回避されます。このメカニズムをアプリケーションで使用する場合は、通常、Hadoopコマンドライン・ディレクティブ-libjarsによってMapReduceジョブに指定するJARファイルに必要な情報を含めることになります。

ここで説明しているメカニズムの目的は、アプリケーションがHadoopインフラストラクチャを利用して、各リモートDataNodeのクラスパスに追加されたJARファイルによって、ジョブに属する各スプリットにパブリックのログインおよび信頼情報を自動的に配布できるようにすることです。ただし、このメカニズムはアプリケーションのパブリック資格証明の配布に使用しても、認証に関連するプライベート情報(具体的にはユーザー名とパスワード)の配布には使用しないでください。これが重要な理由は、ここで説明した方法でDataNodeに配布されるJARファイルが、関連するDataNodeのローカル・ファイル・システムにキャッシュされることがあり、危険にさらされる可能性があるためです。そのため、プライベート認証情報は各スプリットの内部状態の一部としてのみ通信します。

このモデルでサポートされているパブリック資格証明とプライベート資格証明の分離により、各DataNodeでのプライベート資格証明のキャッシュを防止できるだけでなく、現在のHadoop実装で採用されている外部のサード・パーティ製セキュア通信のメカニズムによって、その情報の機密性を容易に保証できるようにもなります。この機能は、セキュア・ストアに対するHive問合せの実行をサポートするためにも重要です。

TableInputFormatへのセキュリティ資格証明の通信

ジョブのTableInputFormatについては、このプログラミング・モデルではユーザーのセキュリティ情報を通信するために別のオプションをサポートしています。これは、TableInputFormatがジョブのクライアント側のアクセス・ノードでのみ動作するためです。つまり、セキュリティの確保が必要なファイル・システムは1つのみということです。また、スプリットとは異なり、TableInputFormatはネットワークで送信されません。そのため、読取り権限がユーザーにのみ付与されているかぎり、アクセス・ノードのファイル・システムにパブリック・セキュリティ情報とプライベート・セキュリティ情報の両方をインストールしても危険にさらされる心配はありません。この場合、通常、アプリケーションではコマンドラインでシステム・プロパティを使用することで、ログイン・ファイル、信頼ファイルおよびパスワード・ファイル(またはOracle Wallet)への完全修飾パスを指定します。その後、TableInputFormatはローカル・ファイル・システムからの読取りによって、パブリックおよびプライベートの必要なセキュリティ情報を取得します。

ユーザーのセキュリティ資格証明をTableInputFormatに通信するためのもう1つのオプションは、TableInputFormatを実行しているJava VMのクライアント側のクラスパスに、リソースとしてパブリックおよびプライベート情報を含めることです。これは、このドキュメントに示すサンプルに採用したオプションで、前述のスプリットについての説明と同様です。このオプションは、アプリケーションのビルド・モデルを利用して、アプリケーションのコマンドラインを簡略化するだけでなく、一般的にセキュアなMapReduceジョブのデプロイメントも簡略化する方法を示します。スプリットの場合と同様に、アプリケーションは、通常、その情報をJARファイルに含めることで必要なセキュリティ情報をJavaリソースとして通信します。ただし、Hadoopコマンドライン・ディレクティブ-libjarsを使用してMapReduceジョブのサーバー側にJARファイルを指定するのではなく、ここでは、TableInputFormatはクライアント側のアクセス・ノードでのみ動作するため、単にJARファイルをHADOOP_CLASSPATH環境変数に追加します。

ベスト・プラクティス: Oracle NoSQLセキュリティ用のMapReduceアプリケーションのパッケージ化

前の項で説明したパブリック・セキュリティ情報とプライベート・セキュリティ情報の分離などを実現するために、この項では、クライアント・アプリケーションとそれに必要なアーティファクトのパッケージ化に関連する一連のベスト・プラクティス(オプション)を示します。これは、このドキュメントに記載されているサンプルで採用されています。このようなパッケージ化プラクティスの使用はオプションですが、セキュア・ストアと対話する独自のMapReduceジョブを扱うときには、そうしたプラクティスの使用をお薦めします。

クラスタ内のDataNodeごとに必要なセキュリティ・アーティファクト(ログイン・ファイル、信頼ファイル、パスワード・ファイルまたはOracle Wallet)を手動でインストールするのではなく、クライアント・アプリケーションを実行するノードであるクラスタの単一アクセス・ノードにのみ、これらのアーティファクトをインストールする必要があります。そうすることで、クライアント・アプリケーションは、ローカル環境から各アーティファクトを取得し、必要な情報を再パッケージしてから、Hadoopインフラストラクチャによって提供されるメカニズムを使用して、その情報を実行されるMapReduceジョブの適切なコンポーネントに転送できます。

たとえば、前の項で説明したように、クライアント・アプリケーションは、コマンドライン、構成ファイルまたはクライアント・クラスパス内のリソースからユーザー名とパスワードの場所を取得するように設計できます。ユーザーのパスワードの場所は、ローカルにインストールされたパスワード・ファイルまたはユーザーのみが読取り可能なOracle Walletです。コマンドラインからユーザー名を取得し、指定の場所からパスワードを取得した後、クライアントは、その情報を使用してユーザーのPasswordCredentialsを作成します。これは、ジョブのTableInputFormatによって作成されたスプリットを通じて各MapReduceタスクに転送されます。このモデルを使用すると、ユーザーのPasswordCredentialsがクラスタのDataNodeのファイル・システムに書き込まれなくなります。それらは、各タスクのメモリーにのみ保持されます。そのため、該当する資格証明の整合性と機密性の提供は、通信中にのみ必要になります。これは、現在のHadoop実装が採用している外部のサード・パーティ製セキュア・コミュニケーション・メカニズムを使用して実現できます。

パブリックのログインおよび信頼アーティファクトの転送については、クライアント・アプリケーションはHadoopインフラストラクチャによって提供されるメカニズムを利用して、クラスパス(JAR)アーティファクトをジョブのタスクに自動的に転送できます。このドキュメントの本文に示したCountTableRowsサンプルで説明したように、クライアント・アプリケーションのビルド・プロセスは、アプリケーションのクラス・ファイルをパブリックのセキュリティ・アーティファクトから分離するように設計できます。具体的には、アプリケーションのクラス・ファイルおよびパブリック資格証明とプライベート資格証明(オプション)をアクセス・ノードのローカルJARファイルに配置して、クライアント自体のクラスパスに含めることができます。一方、パブリックのログイン・プロパティとクライアント信頼情報のみをhadoopコマンドライン指定の-libjarsに追加できる個別のJARファイルに配置して、各MapReduceタスクのクラスパスに含めることができます。

非セキュア・ケースのアプリケーションのパッケージ化

セキュア・ストアに対してアプリケーションを実行するときに、ここで説明するパッケージング・モデルの採用方法を理解するには、まず、非セキュア・ストアに対するCountTableRowsサンプルの実行方法を確認することが役立ちます。前の各項で説明したように、非セキュア・ケースでは、次のコマンドを実行することで、CountTableRowsに必要なクラス・ファイルのみを格納しているJARファイルを生成しました。 

cd /opt/oracle/nosql/apps/kv/examples
jar cvf CountTableRows.jar hadoop/table/CountTableRows*.class

これにより、次のような内容のファイルCountTableRows.jarを生成しました。 

META-INF/
META-INF/MANIFEST.MF
hadoop/table/CountTableRows.class
hadoop/table/CountTableRows$Map.class
hadoop/table/CountTableRows$Reduce.class

また、非セキュア・ストアに対してCountTableRowsサンプルMapReduceジョブを実行するために、次のコマンドを使用しました。 

export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:\
    /opt/ondb/kv/lib/kvclient.jar

cd /opt/ondb/kv 
hadoop jar examples/non_secure_CountTableRows.jar \
    hadoop.table.CountTableRows \
    -libjars \
    /opt/oracle/kv-ee/lib/kvclient.jar,\
    /opt/oracle/kv-ee/lib/sklogger.jar,\
    /opt/oracle/kv-ee/lib/commonutil.jar,\ 
    /opt/oracle/kv-ee/lib/failureaccess.jar,\ 
    /opt/oracle/kv-ee/lib/antlr4-runtime-nosql-shaded.jar,\
    /opt/oracle/kv-ee/lib/jackson-core.jar,\
    /opt/oracle/kv-ee/lib/jackson-databind.jar,\
    /opt/oracle/kv-ee/lib/jackson-annotations.jar \
    example-store \
    kv-host-1:5000 \
    vehicleTable \
    /user/example-user/CountTableRows/vehicleTable/0001

MapReduceジョブの実行時に設定する必要があるクラスパスが3つあることに注目してください。まず、Hadoopコマンド・インタプリタのjar指定により、メイン・プログラム(この場合はCountTableRows)のクラス・ファイルがhadoopランチャ・メカニズムからアクセス可能になるため、プログラムをロードして実行できるようになります。次に、ローカルのアクセス・ノードで実行しているプログラムまたはHadoopフレームワークがロードする必要があるサード・パーティ製ライブラリを含めるように、HADOOP_CLASSPATH環境変数を設定する必要があります。前述の例では、アクセス・ノード上のHadoopフレームワークのジョブ開始メカニズムがTableInputFormatとその関連クラスにアクセスできるように、HADOOP_CLASSPATHにkvclient.jarのみが追加されます。これと指定する必要がある3番目のクラスパスである引数-libjarsの指定内容を比較します。次に説明するように、引数-libjarsには、kvclient.jarだけでなく、リモートHadoop環境で使用できないその他の多くのサード・パーティ製ライブラリも含める必要があります。

Hadoopコマンド・インタプリタの引数-libjarsを使用して、HadoopクラスタのDataNodeで実行する各MapReduceタスクに必要なクラスパスを指定します。引数-libjarsには、目的のアプリケーションの実行に必要なHadoopプラットフォームを通じてまだ使用できないすべてのライブラリを含める必要があります。前述の場合、kvclient.jar、sklogger.jar、commonutil.jar、failureaccess.jar、antlr4-runtime-nosql-shaded.jar、jackson-core.jar、jackson-databind.jarおよびjackson-annotations.jarは、それぞれ引数-libjarsによって指定されているため、各MapReduceタスクはTableInputSplitやTableRecordReaderなどのクラスにアクセスでき、一般的にHadoopプラットフォームで提供されていないロギング関連クラスおよびJSONユーティリティ・クラスにもアクセスできます。

セキュア・ケースのアプリケーションのパッケージ化および実行

前の項で説明した非セキュア・ケースとセキュア・ストアに対してCountTableRows MapReduceジョブを実行するための作業を比較します。セキュア・ケースでは、2つのJARファイルが作成されます。1つはクライアント側のクラスパス用のファイルで、もう1つはサーバー側のDataNodeのクラスパス用のファイルです。最初のJARファイルはクライアント側のクラスパスに追加します。このファイルには、アプリケーションのクラス・ファイルだけでなく、クライアントがセキュア・ストアと対話するために必要なパブリック資格証明とプライベート資格証明も含めます。クライアント側JARファイルにパブリック資格証明とプライベート資格証明を含めると、その情報をコマンドラインで指定する必要がなくなります。

2番目のJARファイルは、引数-libjarsによってサーバー側のDataNodeクラスパスに追加されます。このファイルには、ユーザーのパブリック資格証明のみを含めます。

付録「セキュア・ストアのデプロイ」で説明したように、ユーザーのパスワードはクリアテキストのパスワード・ファイルまたはOracle Walletに格納できます。そのため、最初のJARの生成方法は、パスワード・ファイルとOracle Walletのどちらを使用するかによって異なります。

パスワード・ファイルを使用したセキュア・ケースのアプリケーションのパッケージ化

Oracle Walletのかわりにパスワード・ファイルを使用してCountTableRowsを実行するときに、付録「セキュア・ストアのデプロイ」に示した方法でユーザーのセキュリティ・アーティファクトを生成するためにKVSecurityCreationを使用した場合は、コマンドラインで次のように入力することで、CountTableRowsサンプル・アプリケーションのクライアント側JARファイルとサーバー側JARファイルの両方が生成されます。 

cd /opt/oracle/nosql/apps/kv/examples
jar cvf CountTableRows-pwdClient.jar \
    hadoop/table/CountTableRows*.class \
    hadoop/table/KVSecurityUtil*.class

cd /tmp
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-pwdClient.jar \
    client.trust
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-pwdClient.jar \
    example-user-client-pwdfile.login
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-pwdClient.jar \
    example-user.passwd

jar cvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-pwdServer.jar /
    client.trust
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-pwdServer.jar \
    example-user-server.login

ここに示した最初の4つのコマンドにより、クライアント側のJARファイルCountTableRows-pwdClient.jarが生成されます。このJARの内容は次のようになります。 

META-INF/
META-INF/MANIFEST.MF
hadoop/table/CountTableRows.class
hadoop/table/CountTableRows$Map.class
hadoop/table/CountTableRows$Reduce.class
hadoop/table/KVSecurityUtil.class
client.trust
example-user-client-pwdfile.login
example-user.passwd

このコードの次に示すファイルは、クライアントに対してプライベートのままにしておく必要があるセキュリティ・アーティファクトに対応しています。

example-user-client-pwdfile.login
example-user.passwd

ここに示した最後の2つのコマンドにより、サーバー側JARファイルCountTableRows-pwdServer.jarを生成します。その内容は、次のようになります。 

META-INF/
META-INF/MANIFEST.MF
client.trust
example-user-server.login

このリストの最後の2つのファイルは、パブリックに共有できるクライアントのセキュリティ・アーティファクトに対応しています。

パスワード・ファイルを使用したセキュア・ケースのアプリケーションの実行

クライアント・アプリケーションのパスワードの格納にOracle Walletではなくパスワード・ファイルを使用するセキュア・ストアに対してCountTableRows MapReduceジョブを実行する場合は、前の項で説明したように、パスワード・ファイル・ベースの実行に対応するようにアプリケーションをパッケージ化してから、コマンドラインで次のように入力します。 

export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:\
    /opt/oracle/kv-ee/kv/lib/kvclient.jar:\
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-pwdServer.jar

cd /opt/oracle/nosql/apps/kv

hadoop jar examples/CountTableRows-pwdClient.jar \
    hadoop.table.CountTableRows \
    -libjars \
    /opt/oracle/kv-ee/kv/lib/kvclient.jar,\
    /opt/oracle/kv-ee/kv/lib/sklogger.jar,\
    /opt/oracle/kv-ee/kv/lib/commonutil.jar,\ 
    /opt/oracle/kv-ee/kv/lib/failureaccess.jar,\ 
    /opt/oracle/kv-ee/kv/lib/antlr4-runtime-nosql-shaded.jar,\
    /opt/oracle/kv-ee/kv/lib/jackson-core.jar,\
    /opt/oracle/kv-ee/kv/lib/jackson-databind.jar,\
    /opt/oracle/kv-ee/kv/lib/jackson-annotations.jar,\
    /opt/oracle/nosql/apps/examples/CountTableRows-pwdServer.jar \
    example-store \
    kv-host-1:5000 \
    vehicleTable \
    /user/example-user/CountTableRows/vehicleTable/0001 \
    example-user-client-pwdfile.login \
    example-user-server.login
Oracle Walletを使用したセキュア・ケースのアプリケーションのパッケージ化

クライアントのパスワードを格納するファイルを使用するかわりに、Oracle Walletを使用してパスワードを難読化した形式で格納することもできます。Oracle Walletを使用するときに、CountTableRowsのウォレット・ベースのアーティファクトを生成するために付録「セキュア・ストアのデプロイ」に示した方法でKVSecurityCreationコンビニエンス・プログラムを使用した場合は、コマンドラインで次のように入力することで、ウォレット・ベースのCountTableRowsサンプル・アプリケーション用のクライアント側JARファイルとサーバー側JARファイルの両方が生成されます。 

cd /opt/oracle/nosql/apps/kv/examples
jar cvf CountTableRows-walletClient.jar \
    hadoop/table/CountTableRows*.class \
    hadoop/table/KVSecurityUtil*.class

cd /tmp
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-walletClient.jar \
    client.trust
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-walletClient.jar \
    example-user-client-walletfile.login
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-walletClient.jar \
    example-user-wallet.dir

jar cvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-walletServer.jar /
    client.trust
jar uvf \
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-walletServer.jar \
    example-user-server.login

ここに示した最初の4つのコマンドにより、クライアント側のJARファイルCountTableRows-walletClient.jarが生成されます。このJARの内容は次のようになります。 

META-INF/
META-INF/MANIFEST.MF
hadoop/table/CountTableRows.class
hadoop/table/CountTableRows$Map.class
hadoop/table/CountTableRows$Reduce.class
hadoop/table/KVSecurityUtil.class
client.trust
example-user-client-wallet.login
example-user-wallet.dir/
example-user-wallet.dir/cwallet.sso

同様に、最後の2つのコマンドにより、サーバー側JARファイルCountTableRows-walletServer.jarが生成されます。その内容は、次のようになります。 

META-INF/
META-INF/MANIFEST.MF
client.trust
example-user-server.login
Oracle Walletを使用したセキュア・ケースのアプリケーションの実行

クライアント・アプリケーションのパスワードの格納にOracle Wallet使用するセキュア・ストアに対してCountTableRows MapReduceジョブを実行する場合は、前の項で説明したように、ウォレット・ベースの実行に対応するようにアプリケーションをパッケージ化してから、コマンドラインで次のように入力します。 

export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:\
    /opt/oracle/kv-ee/kv/lib/kvclient.jar:\
    /opt/oracle/nosql/apps/kv/examples/CountTableRows-walletServer.jar

cd /opt/oracle/nosql/apps/kv

hadoop jar examples/CountTableRows-walletClient.jar \
    hadoop.table.CountTableRows \
    -libjars \
    /opt/oracle/kv-ee/kv/lib/kvclient.jar,\
    /opt/oracle/kv-ee/kv/lib/sklogger.jar,\
    /opt/oracle/kv-ee/kv/lib/commonutil.jar,\ 
    /opt/oracle/kv-ee/kv/lib/failureaccess.jar,\ 
    /opt/oracle/kv-ee/kv/lib/antlr4-runtime-nosql-shaded.jar,\
    /opt/oracle/kv-ee/kv/lib/jackson-core.jar,\
    /opt/oracle/kv-ee/kv/lib/jackson-databind.jar,\
    /opt/oracle/kv-ee/kv/lib/jackson-annotations.jar,\
    /opt/oracle/nosql/apps/examples/CountTableRows-walletServer.jar \
    example-store \
    kv-host-1:5000 \
    vehicleTable \
    /user/example-user/CountTableRows/vehicleTable/0001 \
    example-user-client-walletfile.login \
    example-user-server.login

セキュアと非セキュアのコマンドラインの比較

ウォレット・ベースまたはパスワード・ファイル・ベースのパスワード・ストレージ・メカニズムを使用するアプリケーションがどのように実行されるかを調べるときには、まず、非セキュア・ケースとは異なり、HADOOP_CLASSPATHと引数-libjarsの両方が、ログインおよび信頼のパブリック資格証明のみを格納しているJARファイル(CountTableRows-pwdServer.jarまたはCountTableRows-walletServer.jar)で拡張されている点に注目してください。これらのJARファイルにはパブリック情報のみが格納されているため、サーバー側のリモート・アドレス空間に安全に転送できます。

これと、Jarディレクティブによってアプリケーションのローカル・クラスパスが設定されている値を比較します。アプリケーションのサーバー・ベースのJARファイルを含めるのではなく、ローカル・クラスパスは、アプリケーションのクライアント・ベースのJARファイル(CountTableRows-pwdClient.jarまたはCountTableRows-walletClient.jarのどちらか)を含めるように設定されます。アプリケーションのクライアント・ベースのJARファイルには、アプリケーションのパブリック資格証明とプライベート資格証明の両方を含めます。これらのJARファイルには、アプリケーションのアドレス空間(アプリケーションのクライアント側)に対してプライベートのままにしておく必要があるセキュリティ・アーティファクトが格納されています。そのため、これらのJARファイルは、HADOOP_CLASSPATHまたは-libjarsの指定に含めないでください。クライアントのローカル・クラスパスにのみ含めるようにします。

最後に、セキュア実行のコマンドラインと非セキュア実行のその他のコマンドラインの違いは、セキュア・ケースの引数リストの最後にある2つの追加の引数のみです。具体的には、example-user-server.loginと、example-user-client-pwdfile.loginまたはexample-user-client-wallet.loginです。

これらの引数の値では、それぞれクライアント側とサーバー側のログイン・ファイルの名前を指定します。その内容は、対応するJARファイルからリソースとして取得されます。

ここに示すような方法でMapReduceアプリケーションをパッケージ化して実行する場合は、コマンドラインでユーザー名またはパスワード・ファイル(またはウォレット)を指定する必要がない点に注目してください。その情報はクライアント側JARファイルの一部として含まれているためです。また、Hadoopクラスタのアクセス・ノードからジョブのDataNodeに転送されるサーバー側JARファイルには、そうしたプライベート情報は含まれません。転送されたJARファイルは各DataNodeのファイル・システムにキャッシュされるため、このことが重要になります。

まとめ

前述の各項で説明したように、MapReduceとOracle NoSQL Databaseセキュリティのプログラミング・モデルでは、Oracle NoSQL Database表APIを使用して、特定のOracle NoSQL Databaseストア(セキュアまたは非セキュア)にあるデータを取得および処理する特定のMapReduceジョブのビルド、パッケージ化およびデプロイに対して、この項に示したベスト・プラクティスをサポート(奨励)しています。その結果として、別個のJARファイルを生成するだけで、セキュア・ケースに対応する一連のJARファイルが生成されます。また、非セキュア・ケースに対応するJARファイルを使用すると、デプロイヤはセキュリティの有無にかかわらずジョブを都合に応じて実行できます。

ノート:

このパブリックのユーザー資格証明とプライベートのユーザー資格証明を分離するモデルは、セキュア・ストア内の表データに対してHive問合せを実行する際にも重要な役割を果たします。