Spark セキュリティ

• Sparkセキュリティ: 知らなければならない事
• Spark RPC (Sparkプロセス間の通信プロトコル)
  • 認証
    • YARN
    • Kubernetes
  • 暗号化
• ローカルストレージの暗号化
• Web UI
  • 認証と権限
  • Spark履歴サーバのACLs
  • SSL 設定
  • キーストアの準備
    • YARN モード
    • スタンドアローンモード
    • Mesos モード
  • HTTP セキュリティ ヘッダ
• ネットワークセキュリティのためのポートの設定
  • スタンドアローンモードのみ
  • 全てのクラスタマネージャー
• Kerberos
  • 長時間実行中のアプリケーション
    • キータブの使用
    • チケットキャッシュの使用
  • Kubernetes との安全なやり取り
• イベントのログ
• クライアントモードでの永続化ドライバログ

Sparkセキュリティ: 知らなければならない事

認証のようなセキュリティ機能はデフォルトでは有効にされていません。インターネットや信頼できないネットワークに開かれたクラスタを配備する場合、認証されていないアプリケーションをクラスタ上で実行することを防ぐためにクラスタへのアクセスを安全にすることが重要です。

Sparkは複数の配備の種類をサポートし、それぞれは異なるレベルのセキュリティをサポートします。全ての環境で全ての配備が安全なわけではありません。デフォルトでは安全ではありません。環境、Sparkが何をサポートするのかを確認し、Sparkの配備を安全にするために適切な方法を取ってください。

セキュリティの問題には様々な種類があります。Sparkは必ずしも全てを保護するわけではありません。以下でリスト化されたものはSparkがサポートするものの一部です。また、配備固有の設定に使用している配備の種類について、配備ドキュメントを調べてください。ドキュメント化されていないものは全てSparkはサポートしません。

Spark RPC (Sparkプロセス間の通信プロトコル)

認証

現在のところSparkは共有秘密鍵を使ってRPCチャネルのための認証をサポートします。認証はspark.authenticate設定パラメータを設定することで有効にすることができます。

共有鍵を生成および分配するために使われる正確な仕組みは配備に固有です。以下で指定されない限り、秘密鍵は spark.authenticate.secret 設定オプションを設定することで定義される必要があります。その場合、同じ秘密鍵が全ての Spark アプリケーションとデーモンで共有されるため、特にマルチテナントクラスタでこれらの配備の安全性が制限されます。

REST Submission サーバと MesosClusterDispatcher は認証をサポートしません。REST API & MesosClusterDispatcher (デフォルトではそれぞれポート 6066 および 7077) への全てのネットワークアクセスが、ジョブの送信が信頼されているホストに制限されていることを確認する必要があります。

YARN

YARN上のSparkのために、Sparkは共有秘密鍵の生成と配布を自動的に処理します。各アプリケーションはユニークな共有鍵を使うでしょう。YARNの場合、この機能は秘密鍵を安全に配布するために有効にされるYARN RJPC暗号化に依存します。

Kubernetes

Kubernetes では、Spark は各アプリケーションに固有の認証秘密鍵も自動的に生成します。秘密鍵は環境変数を使って executor pod に伝播されます。つまり、Spark アプリケーションが実行されている名前空間で pod を一覧表示できる全てのユーザは、それらの認証秘密鍵も表示することもできます。Spark 認証が安全であることを保障するために、Kubernetes 管理者はアクセス制御ルールを適切に設定する必要があります。

または、ユーザが pod にマウントするファイルと Kubernetes 秘密鍵を使って、認証秘密鍵をマウントすることができます。

ファイルを使う場合は、Spark はそれらのファイルをコンテナにマウントしないことに注意してください。秘密鍵ファイルが安全にコンテナに配備され、ドライバの秘密鍵ファイルが executor の秘密鍵ファイルと一致するようにするのは、あなたの責任です。

暗号化

Spark は RPC接続のために AESベースの暗号化をサポートします。暗号化を有効にするためには、RPC認証も有効にして適切に設定する必要があります。AES 暗号化は Apache Commons Crypto ライブラリを使用し、Sparkの設定システムによって上級ユーザ向けにそのライブラリの設定にアクセスすることができます。

SASLベースの暗号化もサポートされますが、非推奨と見なされるべきです。2.2.0より古いSparkバージョンからシャッフルサービスに通信する時にまだ必要とされます。

以下の表はこの機能を設定するために利用可能な様々なオプションを示します。

ローカルストレージの暗号化

Spark はローカルディスクに書きこまれた一時データの暗号化をサポートします。これはシャッフルファイル、シャッフルスピル、およびディスクに格納されたデータブロックが含まれます (キャッシュ変数とブロードキャスト変数の両方) 。saveAsHadoopFile あるいは saveAsTable のようなAPIを使ってアプリケーションによって生成された暗号化出力データは含まれません。ユーザによって明示的に作成された一時ファイルを含まないかもしれません。

以下の設定はディスクに書き込まれたデータの暗号化を有効にします:

Web UI

認証と権限

Web UIのための認証を有効にするには、javax servlet filtersを使用します。配備したい認証方法を実装するフィルタが必要です。Spark ｊは組み込みの認証フィルタを提供しません。

Spark は認証フィルタが存在する場合のUIへのアクセス制御もサポートします。各アプリケーションは独自の個別のアクセス制限リスト (ACL)を使って設定することができます。 Sparkは “view” 権限 (誰がアプリケーションのUIを見ることができるか) と “modify” 権限 (誰が実行中のアプリケーションでジョブを強制終了できるか) を区別します。

ACL はユーザあるいはグループのいずれかに設定できます。設定エントリは入力としてカンマ区切りのリストを受け付けます。つまり複数のユーザあるいはグループに必要な権限を付与できます。 これは、共有クラスタ上で実行し、自分で起動していないアプリケーションを監視する必要がある管理者あるいは開発者のセットがある場合に使うことができます。特定のACLに追加されたワイルドカード (*) は、全てのユーザがそれぞれの権限を持つことを意味します。デフォルトでは、アプリケーションを送信するユーザだけがACLに追加されます。

グループメンバーシップは設定可能なグループマッピング プロバイダを使って確立されます。マッパーは以下の表で説明されるspark.user.groups.mapping 設定オプションを使って設定されます。

以下のオプションはWeb UIの認証を制御します:

YARN上では、表示と変更ACLはアプリケーションを送信した時にYARNサービスに提供され、YARNインタフェースを介してそれぞれの権限を持つユーザを制御します。

Spark履歴サーバのACLs

SHS Web UIのための認証は、servletフィルタを使って通常のアプリケーションと同じ方法で有効にされます。

SHSで認証を有効にするために、幾つかの追加オプションが使われます:

SHSは同じ設定を使用してグループマッピング プロバイダを通常のアプリケーションとして設定します。この場合、グループマッピング プロバイダはSHSによって全てのUIサーバに適用され、個々のアプリケーションの設定は無視されます。

SSL 設定

SSLのための設定は階層構造によって整理されます。プロトコル固有の設定で上書きされていない限り、ユーザは全てのサポートされる通信プロトコルのために使われるデフォルトのSSL設定を設定することができます。このようにユーザは全てのプロトコルのための共通の設定を、それぞれ個々に設定する機能を無効にすること無しに、簡単に提供することができます。以下の表はSSL設定名前空間を示します:

利用可能なSSLオプションの完全なブレークダウンは以下で見つけることができます。${ns}のプレースホルダーは上記の名前空間のうちの1つで置き換えられなければなりません。

Spark はHadoop 資格プロバイダから${ns}.keyPassword, ${ns}.keyStorePassword および ${ns}.trustStorePasswordの取得もサポートします。 ユーザはパスワードを資格情報ファイルに保存し、以下のように異なるコンポーネントからアクセスできるようにすることができます:

hadoop credential create spark.ssl.keyPassword -value password \
    -provider jceks://hdfs@nn1.example.com:9001/user/backup/ssl.jceks

資格プロバイダの場所を設定するには、以下のようにSparkが使用するHadoop設定の中のhadoop.security.credential.provider.path設定オプションを見てください:

  <property>
    <name>hadoop.security.credential.provider.path</name>
    <value>jceks://hdfs@nn1.example.com:9001/user/backup/ssl.jceks</value>
  </property>

または、SparkConf の “spark.hadoop.hadoop.security.credential.provider.path=jceks://hdfs@nn1.example.com:9001/user/backup/ssl.jceks” を介して。

キーストアの準備

キーストアはkeytool プログラムで生成することができます。Java 8 のためのこのツールのリファレンス文章は ここにあります。Spark スタンドアローン配備モードのためのキーストアとtrustストアを設定する最も基本的なステップは以下の通りです:

• 各ノードのためにキーを生成します
• キーのペアの公開鍵を各ノード上のファイルにエクスポートします
• 全てのエクスポートされた公開鍵を1つのtrustストアにインポートします
• trustストアをクラスタノードに分配します

YARN モード

クラスタモードで実行中のドライバにローカルクラスタストアあるいはキーストアを提供するために、--files コマンドライン引数 (あるいは 同等のspark.files 設定)を使ってアプリケーションと共に配布できます。ファイルはドライバの作業ディレクトリに配置されるため、TLS設定は絶対パスではなくファイル名のみを参照する必要があります。

この方法でローカルキーストアを配布するには、ファイルをHDFS (あるいはクラスタで使用される他の似た分散ファイルシステム)に置く必要があるかもしれません。そのため基礎となるファイルシステムはセキュリティを考慮して設定することをお勧めします (例えば、認証とwire暗号化を有効にする)。

スタンドアローンモード

ユーザがマスターとワーカーのためにキーストアと設定オプションを提供する必要があります。それらはSPARK_MASTER_OPTS と SPARK_WORKER_OPTS 環境変数内、あるいは単にSPARK_DAEMON_JAVA_OPTSの中で、適切なJavaシステムプロパティを加えることで設定されなければなりません。

ユーザはexecutorにワーカープロセスから継承したSSL設定を使えるようにするかも知れません。これはspark.ssl.useNodeLocalConf を true に設定することで実現できます。この場合、クライアント側でユーザによって提供された設定は使われません。

Mesos モード

Mesos 1.3.0 以上はファイルベースおよび環境ベースの両方の秘密鍵としてSecrets プリミティブをサポートします。Sparkはそれぞれspark.mesos.driver.secret.filenames と spark.mesos.driver.secret.envkeys を使ってファイルベースと環境変数ベースの秘密鍵の使用を許可します。

秘密ストアに応じて、バックエンドの秘密鍵はそれぞれspark.mesos.driver.secret.names と spark.mesos.driver.secret.values構成プロパティを持つリファレンスあるいは値で渡すことができます。

参照型の秘密鍵は秘密鍵ストアとして提供され、名前で参照されます。例えば /mysecret。値型の秘密鍵はコマンドラインで渡され、適切なファイルあるいは環境変数に解釈されます。

HTTP セキュリティ ヘッダ

Apache Sparkは Cross Site Scripting (XSS), Cross-Frame Scripting (XFS), MIME-Sniffing を避けるのに役立ち、HTTP Strict Transport Securityも強制する HTTPヘッダを含むように設定することができます。

ネットワークセキュリティのためのポートの設定

一般的に言って、Spark クラスタとそのサービスは公的なインターネットに配備されません。それらは一般的にプライベートなサービスで、Sparkを配備する組織のネットワーク内でのみアクセス可能な筈です。Sparkサービスによって使われるホストとポートへのアクセスはサービスへアクセスする必要があるオリジンのホストに制限されるべきです。

以下はSparkが通信のために使用する主なポートと、それらのポートの設定方法です。

スタンドアローンモードのみ

全てのクラスタマネージャー

Kerberos

Sparkは認証のためにKerberosを使う環境でのアプリケーションの提出をサポートします。ほとんどの場合、Sparkは、Kerberos対応サービスの認証時に現在ログインしているユーザの資格情報に依存します。そのような資格情報は設定されたKDCにkinitのようなツールを使ってログインすることで取得できます。

Hadoopベースのサービスと通信する場合、Sparkは非ローカルプロセスが認証できるように移譲トークンを取得する必要があります。SparkにはHDFSと他のHadoopシステム、HiveとHBaseのためのサポートが付属しています。

(DFS あるいは WebHDFSのような)Hadoopファイルシステムを使う場合、Sparkはユーザのホームディレクトリをホストするサービスのための関連トークンを取得します。

HBaseがアプリケーションのクラスパスにあり、HBase構成でKerberos認証が有効になっている場合 (hbase.security.authentication=kerberos)、HBaseトークンが取得されます。

同様に、Hive がクラスタパスにあり、構成にリモートのメタストア サービスのURIが含まれる場合 (hive.metastore.uris が空では無い)、Hiveトークンが取得されます。

もしアプリケーションが他の安全なHadoopファイルシステムとやり取りをする必要がある場合、それらのURIは起動時に明示的にSparkに提供される必要があります。spark.kerberos.access.hadoopFileSystems プロパティの中でそれらをリスト化することで行われます。以下の設定の章で説明されます。

Spark はJavaサービスの仕組みを使った独自の移譲トークン プロバイダもサポートします (java.util.ServiceLoaderを見てください)。jarのMETA-INF/servicesディレクトリ内の対応するファイルの中でそれらの名前をリスト化することで、Sparkでorg.apache.spark.security.HadoopDelegationTokenProvider の実装を利用可能にすることができます。

移譲トークンのサポートは現在のところYARNとMesosモードでのみサポートされます。詳細は配備固有のページを参照してください。

以下のオプションはこの機能のきめ細やかな制御を提供します:

ユーザは、リソーススケジューラでKerberos委任トークンの更新を除外できます。現在のところ、YARNでのみサポートされます。設定については、YARN上でSparkの実行ページで説明されます。

長時間実行中のアプリケーション

長時間実行中のアプリケーションは、実行時間がアクセスする必要のあるサービスで設定された移譲トークンの最大生存時間を超えた場合、問題が発生するかもしれません。

この機能はどこでも利用できるわけではありません。特に、YARN と Kubernetes (クライアントモードとクラスタモードの両方)、およびクライアントモードを使う場合は Mesos にのみ、実装されます。

Spark はこれらのアプリケーションのための新しいトークンの自動作成をサポートします。この機能を有効にする方法は2つあります。

キータブの使用

Spark にプリンシパルとキータブを提供することにより (例えば、spark-submit を --principal と --keytab パラメータを使って)、アプリケーションは移譲トークンを無限に取り出すのに使うことができる有効な Kerberos ログインを維持します。

クラスタモードでキータブを使う場合、Spark ドライバが実行されるマシーンにコピーされることに注意してください。YARN の場合、これは、キータブのステージング領域として HDFS を使うことを意味するため、少なくとも YARN と HDFS の両方を暗号化で保護することを強くお勧めします。

チケットキャッシュの使用

Spark の設定の中で、spark.kerberos.renewal.credentials を ccache に設定することで、ローカル Kerberos チケットキャッシュが認証に使われます。Sparkは更新可能な期間中はチケットを更新し続けますが、有効期限が切れた後は、新しいチケットを取得する必要があります(例えば、kinitを実行する)。

Spark が使用できる更新されたチケットキャッシュを維持するかどうかは、ユーザ次第です。

チケットキャッシュの場所は、KRB5CCNAME 環境変数を使ってカスタマイズすることができます。

Kubernetes との安全なやり取り

Kerberos の背後にある Hadoop ベースのサービスと通信する時、非ローカルプロセスが認証できるように Spark が移譲トークンを取得する必要があることが指摘されました。Kubernetes のこれらの移譲トークンは、ドライバとその executor によって共有される秘密鍵に格納されます。そのため、Kerberos ジョブを送信するには3つの方法があります:

全ての場合において、環境変数 HADOOP_CONF_DIR あるいは spark.kubernetes.hadoop.configMapName. を定義する必要があります。

また、KDC はコンテナ内部から見えるようにする必要があることにも注意してください。

ユーザが Hadoop 設定ファイルを含む、リモート HADOOP_CONF ディレクトリを使いたい場合は、spark.kubernetes.hadoop.configMapName を既存の ConfigMap に設定することで、これを実現できます。

1. TGT をローカルチケットキャッシュに保存する $kinit を使って送信します:

   /usr/bin/kinit -kt <keytab_file> <username>/<krb5 realm>
   /opt/spark/bin/spark-submit \
    --deploy-mode cluster \
    --class org.apache.spark.examples.HdfsTest \
    --master k8s://<KUBERNETES_MASTER_ENDPOINT> \
    --conf spark.executor.instances=1 \
    --conf spark.app.name=spark-hdfs \
    --conf spark.kubernetes.container.image=spark:latest \
    --conf spark.kubernetes.kerberos.krb5.path=/etc/krb5.conf \
    local:///opt/spark/examples/jars/spark-examples_<VERSION>.jar \
    <HDFS_FILE_LOCATION>
   

2. ローカルキータブとプリンシパルを送信

   /opt/spark/bin/spark-submit \
    --deploy-mode cluster \
    --class org.apache.spark.examples.HdfsTest \
    --master k8s://<KUBERNETES_MASTER_ENDPOINT> \
    --conf spark.executor.instances=1 \
    --conf spark.app.name=spark-hdfs \
    --conf spark.kubernetes.container.image=spark:latest \
    --conf spark.kerberos.keytab=<KEYTAB_FILE> \
    --conf spark.kerberos.principal=<PRINCIPAL> \
    --conf spark.kubernetes.kerberos.krb5.path=/etc/krb5.conf \
    local:///opt/spark/examples/jars/spark-examples_<VERSION>.jar \
    <HDFS_FILE_LOCATION>
   

3. 名前空間にすでに存在する移譲トークンを含む、事前に設定された秘密鍵を使って送信する

   /opt/spark/bin/spark-submit \
    --deploy-mode cluster \
    --class org.apache.spark.examples.HdfsTest \
    --master k8s://<KUBERNETES_MASTER_ENDPOINT> \
    --conf spark.executor.instances=1 \
    --conf spark.app.name=spark-hdfs \
    --conf spark.kubernetes.container.image=spark:latest \
    --conf spark.kubernetes.kerberos.tokenSecret.name=<SECRET_TOKEN_NAME> \
    --conf spark.kubernetes.kerberos.tokenSecret.itemKey=<SECRET_ITEM_KEY> \
    --conf spark.kubernetes.kerberos.krb5.path=/etc/krb5.conf \
    local:///opt/spark/examples/jars/spark-examples_<VERSION>.jar \
    <HDFS_FILE_LOCATION>
   

3b. (3) と同様に送信しますが、事前に作成された krb5 ConfigMap と事前に作成された HADOOP_CONF_DIR ConfigMap を指定します。

/opt/spark/bin/spark-submit \
    --deploy-mode cluster \
    --class org.apache.spark.examples.HdfsTest \
    --master k8s://<KUBERNETES_MASTER_ENDPOINT> \
    --conf spark.executor.instances=1 \
    --conf spark.app.name=spark-hdfs \
    --conf spark.kubernetes.container.image=spark:latest \
    --conf spark.kubernetes.kerberos.tokenSecret.name=<SECRET_TOKEN_NAME> \
    --conf spark.kubernetes.kerberos.tokenSecret.itemKey=<SECRET_ITEM_KEY> \
    --conf spark.kubernetes.hadoop.configMapName=<HCONF_CONFIG_MAP_NAME> \
    --conf spark.kubernetes.kerberos.krb5.configMapName=<KRB_CONFIG_MAP_NAME> \
    local:///opt/spark/examples/jars/spark-examples_<VERSION>.jar \
    <HDFS_FILE_LOCATION>

イベントのログ

アプリケーションがイベントログを使っている場合は、イベントログが入るディレクトリ(spark.eventLog.dir) は手動で作成され、適切なパーミッションが設定されていなければなりません。ログファイルを保護するために、ディレクトリのパーミッションは drwxrwxrwxt に設定されなければなりません。ディレクトリの所有者とグループはSpark履歴サーバを実行するスーパーユーザに対応する必要があります。

これにより、全てのユーザはディレクトリに書き込むことができますが、権限のないユーザはファイルを所有していない限り、ファイルの読み込み、削除あるいは名前の変更をできません。イベントログファイルはSparkによってユーザおよびグループのみが読み書きアクセスを持つパーミッションで生成されるでしょう。

クライアントモードでの永続化ドライバログ

spark.driver.log.persistToDfs.enabled を有効にすることでアプリケーションがクライアントモードでドライバログを永続化する場合は、ドライバログが保存されるディレクトリ (spark.driver.log.dfsDir) は適切な権限で手動で作成する必要があります。ログファイルを保護するために、ディレクトリのパーミッションは drwxrwxrwxt に設定されなければなりません。ディレクトリの所有者とグループはSpark履歴サーバを実行するスーパーユーザに対応する必要があります。

これにより、全てのユーザはディレクトリに書き込むことができますが、権限のないユーザはファイルを所有していない限り、ファイルの読み込み、削除あるいは名前の変更をできません。ドライバログファイルはSparkによってユーザおよびグループのみが読み書きアクセスを持つパーミッションで生成されるでしょう。