Kerberos認証用のDataStax Enterpriseの構成

各ノードのファイルで、オーセンティケーターをKerberosオーセンティケーターに設定します。

authenticator:com.datastax.bdp.cassandra.auth.KerberosAuthenticator

cassandra.yamlのrpc_addressとlisten_addressオプションをDNSのホスト名と一致するIPアドレスまたはホスト名に設定してください。DNSのホスト名は、kadminの最初のほうのステップで作成したサービス・プリンシパルのFQDN（完全修飾ドメイン名）と同じです。localhostには設定しないでください。

rpc_address: 1.2.3.4
listen_address: 1.2.3.4

各ノードで、ファイルを編集して正しいKerberosオプションを入力します。

オプションは、kerberos_optionsセクションに記載されています。以下の表を参照してください。

kerberos_options:
keytab:path_to_keytab/dse.keytab
service_principal:dse_user/_HOST@REALM
http_principal:HTTP/_HOST@REALM
qop:auth

例：

kerberos_options:
keytab:/etc/dse/dse.keytab 
service_principal:cassandra/_HOST@EXAMPLE.COM
http_principal:HTTP/_HOST@EXAMPLE.COM
qop:auth

Kerberosオプション
オプション	説明
keytab	キータブ・ファイルには、完全に解決された両方のプリンシパル名の認証情報が含まれている必要があります。これにより、`service_principal`および`http_principal`設定で`_HOST`がホストのFQDNに置き換えられます。DataStax Enterpriseを実行しているUNIXユーザーには、キータブの読み取りパーミッションも必要です。
service_principal	CassandraおよびDSE Search（Solr）プロセスがその下で実行されるプリンシパルを設定します。`dse_user/_HOST@REALM`という形式を使用します。 Installer-Servicesおよびパッケージのインストール： cassandra パッケージ・インストール：サービスを開始するUNIXユーザーの名前 `_HOST`は、そのままにしておきます。この変数は、dse.yamlで使用されています。DataStax Enterpriseは、実行されるホストのFQDNを自動的に置き換えます。キータブ・ファイルには、このプリンシパルの認証情報が含まれている必要があり、かつCassandraが実行されるユーザー（通常はcassandra）によって読み取り可能である必要があります。 `service_principal`は、以下のすべてで整合性が取れている必要があります。 dse.yamlファイル keytab cqlshrcファイル（サービスとホスト名に分かれています）
http_principal	REALMをKerberosレルムの名前に設定します。Kerberosプリンシパルでは、REALMはすべて大文字で指定する必要があります。 `_HOST`は、そのままにしておきます。この変数は、dse.yamlで使用されています。DataStax Enterpriseは、実行されるホストのFQDNを自動的に置き換えます。キータブ・ファイルには、このプリンシパルの認証情報が含まれている必要があり、かつCassandraが実行されるユーザー（通常はcassandra）によって読み取り可能である必要があります。 `http_principal`は、アプリケーション・コンテナー（tomcat）によって、Solrを実行するために使用されます。Webサーバーは、GSS-APIメカニズム（SPNEGO）を使用して、GSSAPIセキュリティ・メカニズム（Kerberos）をネゴシエートします。DSE Searchノード用のパスワードを設定するには、「Cassandra内部のパスワード認証」を参照してください。
qop	クライアントとサーバーが相互接続のために使用できる保護品質（QOP）値のコンマ区切りリスト。クライアントには複数のQOP値を指定することができますが、サーバーに指定できるのは1つのQOP値のみです。有効な値： `auth` - デフォルト：認証のみ。 `auth-int` - すべての転送データに対して認証とインテグリティを保護します。 `auth-conf` - すべての転送データに対して認証とインテグリティを保護し、かつ暗号化します。 `auth-conf`を使用する暗号化は別個のものであり、SSLを使用した暗号化とは関係ありません。`auth-conf`とSSLの両方を有効にすると、転送されるデータは2回暗号化されます。DataStaxでは、1つの方法だけを選択し、それを暗号化と認証の両方に使用することを推奨します。

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストール	/etc/dse/cassandra/cassandra.yaml
tarボール・インストール	`install_location`/resources/cassandra/conf/cassandra.yaml

dse.yamlファイルの場所は、インストールのタイプによって異なります。

Installer-Services	/etc/dse/dse.yaml
パッケージ・インストール	/etc/dse/dse.yaml
Installer-No Services	`install_location`/resources/dse/conf/dse.yaml
tarボール・インストール	`install_location`/resources/dse/conf/dse.yaml

クラスターが起動し、稼動したら、system_authキースペースのレプリケーション・ストラテジとデフォルトのレプリケーション係数を変更します。「system_authキースペースのレプリケーションの構成」を参照してください。

DataStaxでは、フォールト・トレランス（障害が発生した場合）用にsystem_authキースペースを構成することを推奨します。マルチノード・クラスターでは、ユーザー・データが格納されているノードがダウンしている場合に、system_authキースペースにデフォルトのレプリケーション係数1を指定すると、セキュリティ保護されたノードへのログインが行われません。

Kerberos認証用のDataStax Enterpriseの構成

手順