Kerberos認証を使用するようDataStax Enterpriseノードを構成します。
始める前に
Kerberos認証を有効にする前に、DSEノードでKerberosを完全に設定しておきます。認証方法を切り替える場合や、実稼働環境で認証を初めて有効にする場合は、認証済みの接続のみにアクセスを制限する前に、Kerberosチケットを使用するようアプリケーションを設定しておくことが推奨されます。DSE Authenticator(DSEオーセンティケーター)が無効になっている場合、接続要求の認証情報部分は無視されます。そのため、認証を環境に実装する前に、KerberosチケットをDSEに渡すことができます。
system_authキースペースとdse_securityキースペースのレプリケーション・ストラテジとデフォルトのレプリケーション係数を変更します。「system_authキースペースのレプリケーションの構成」を参照してください。
Kerberosオーセンティケーターをcassandra.yamlに追加し、Kerberosオプションをdse.yamlに追加する方法。
手順
-
各ノードで、ファイルを編集して、オーセンティケーターをDSE Authenticator(DSEオーセンティケーター)に設定します。
authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
-
rpc_addressとlisten_addressをIPアドレスに設定します。localhostやホスト名は使用しないでください。
rpc_address: 100.200.182.1
listen_address: 100.200.182.1
-
各ノードで、ファイルを編集します。
-
認証オプションでKerberosをデフォルトまたはその他のスキームとして設定します。
authentication_options:
enabled: false
default_scheme: kerberos
other_schemes:
- internal
scheme_permissions: true
allow_digest_with_kerberos: true
plain_text_without_ssl: warn
transitional_mode: disabled
注: 最初に認証を有効にするときは、内部スキームをデフォルトまたはその他のスキームとして指定します。DSEを再起動した後、ロールを設定するには、内部のデフォルトのcassandaraアカウントを使用する必要があります。
表 1. authentication_options
オプション |
説明 |
enabled |
デフォルト・スキームを使用した認証を有効にします。 |
default_scheme |
認証スキームが接続で定義されていない場合に指定します。
- internal- 内部ログイン・ロールとパスワードを使用するプレーン・テキスト認証。ロール名とパスワードを認証情報として指定します。他に必要な構成はありません。
- ldap - パススルーLDAP認証を使用するプレーン・テキスト認証。「LDAPスキームの定義」を参照してください。
- kerberos - Kerberosオーセンティケーターを使用するGSSAPI認証。「Kerberosスキームの定義」を参照してください。
|
other_schemes |
other_schemes重要:
Analyticsデータ・センターのCFSやCassandraHiveMetastoreなど、Thriftを使用するDSEコンポーネントではother_schemes を使用できません。Thriftドライバーを使用するコンポーネントを使用する場合は、default_scheme のみが使用されます。
|
scheme_permissions |
ユーザーにマップされているロールが認証スキームと一致していることを確認します。そのロールにスキームに対するパーミッションを付与します。 |
allow_digest_with_kerberos |
Kerberos digest-md5認証を許可します。 |
plain_text_without_ssl |
プレーン・テキスト接続要求の処理:
- block - 要求をブロックし、認証エラーが発生します。
- warn - 要求について警告をログに記録しますが、処理を続行します。デフォルト。
- allow - 警告なしで要求を許可します。
|
transitional_mode |
認証が失敗し、認証情報が見つからない場合の動作を設定します。
- disabled - 移行モードは無効になります。デフォルト。
- permissive - スーパーユーザーだけが認証されてログインできます。他のすべての認証は匿名ユーザーとしてログインします。
- normal - 有効な認証情報を指定したユーザーのみがログインします。
- 認証が成功すると、ユーザーはログインします。
- 認証が失敗すると、ユーザーは匿名ユーザーとしてログインします。
- 認証情報が渡されない場合、ユーザーは匿名ユーザーとしてログインします。
- strict - 認証情報が渡された場合、認証されます。
- 認証が成功すると、ユーザーはログインします。
- 認証が失敗すると、認証エラーが返されます。
- 認証情報が渡されない場合、ユーザーは匿名ユーザーとしてログインします。
|
-
Kerberosオプションを構成します。
オプションはkerberos_options
セクションにあります。
例:
kerberos_options:
keytab: /etc/dse/dse.keytab
service_principal: dse/_HOST@REALM
http_principal: HTTP/_HOST@REALM
qop: auth
表 2. kerberos_options
オプション |
説明 |
keytab |
キータブ・ファイルには、完全に解決された両方のプリンシパル名の認証情報が含まれている必要があります。これにより_HOST をservice_principal およびhttp_principal 設定でホストのFQDNに置き換えます。DataStax Enterpriseを実行しているUNIXユーザーには、キータブの読み取りパーミッションも必要です。 |
service_principal |
DSEデータベース・プロセスとDSE Search(Solr)プロセスのプリンシパル名を設定します。形式dse/_HOST@REALM を使用します。ここで、dseはサービス名です。 _HOST は、そのままにしておきます。この変数はdse.yamlで使用されます。DataStax Enterpriseが実行されているホストのFQDNが自動的に代入されます。このプリンシパルの認証情報がキータブ・ファイルに含まれていて、Cassandraを実行するユーザー(通常はcassandra)がその認証情報を読み取り可能である必要があります。
以下のすべての場所で service_principal の整合性が保たれている必要があります。
- dse.yamlファイル
- keytab
- cqlshrcファイル(ここでは、サービス/ホスト名に分かれています)
|
http_principal |
http_principalは、Tomcatアプリケーション・コンテナーがDSE Searchを実行する際に使用します。Tomcat Webサーバーは、GSS-APIメカニズム(SPNEGO)を使用して、GSSAPIセキュリティ・メカニズム(Kerberos)をネゴシエートします。REALMをKerberosレルムの名前に設定します。Kerberosプリンシパルでは、REALMは大文字で指定します。 |
qop |
クライアントとサーバーが相互接続のために使用できる保護品質(QOP)値のコンマ区切りリスト。クライアントには複数のQOP値を指定することができますが、サーバーに指定できるのは1つのQOP値のみです。有効な値: |
cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストールInstaller-Servicesインストール
|
/etc/dse/cassandra/cassandra.yaml |
tarボール・インストールInstaller-No Servicesインストール
|
installation_location/resources/cassandra/conf/cassandra.yaml |
dse.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストールInstaller-Servicesインストール
|
/etc/dse/dse.yaml |
tarボール・インストールInstaller-No Servicesインストール
|
installation_location/resources/dse/conf/dse.yaml |
-
Kerberosスキームを認証対応クラスターに追加する場合は、DSEを再起動する前にKerberosロールを構成しておきます。「ロールの管理」を参照してください。
次のタスク
認証を最初に構成するとき、以下を行って設定を完了します。