DSE Unified Authenticatorによる認証の構成

DSE Unified Authenticatorによって認証を構成するための手順。

各ノードで、次のようにします。

1. cassandra.yamlファイルで、オーセンティケーターとオーソライザーにDSE Unified Authenticationを使用するのに必要な値が含まれていることを確認します。
   1. オーセンティケーターをDseAuthenticatorに変更します。デフォルトでは、オーセンティケーター・オプションはAllowAllAuthenticatorに設定されています。
   2. オーソライザーをDseAuthorizerに変更します。デフォルトでは、オーソライザー・オプションはAllowAllAuthorizerに設定されています。

   authenticator:com.datastax.bdp.cassandra.auth.DseAuthenticator
   authorizer:com.datastax.bdp.cassandra.auth.DseAuthorizer

2. dse.yamlファイルで、DataStax Enterpriseオーセンティケーション・オプションを以下のように設定します。

   authentication_options:
   enabled:true
   default_scheme:kerberos
   other_schemes:
   - internal
   scheme_permissions:true
   allow_digest_with_kerberos:false
   plain_text_without_ssl:warn
   transitional_mode:disabled

   1. 認証をオンにし、DSE Unified Authenticatorを使用してユーザーを認証します。

      enabled:true

      DSE Unified Authenticatorがユーザーを認証するかどうかを制御します。DSE Unified Authenticatorでは、内部Cassandraパスワード認証、LDAPパススルー認証、およびKerberos認証の任意の組み合わせを使用して認証を提供します。 DSE Unified Authenticatorにより、複数の認証スキームを同時に使用することが可能になります。認証時に使用するスキームは、ドライバーが選択します。
   2. ドライバーによって特定のスキームが要求されない場合に使用する認証スキームを指定します。
      default_schemeの場合、以下の値のいずれかを選択します。

      • internal - 内部Cassandraパスワード認証を使用するプレーンテキスト認証。「内部認証」を参照してください。
      • ldap - パススルーLDAP認証を使用するプレーンテキスト認証。「LDAPを使用したクラスターの認証」を参照してください。
      • kerberos - Kerberosオーセンティケーターを使用するGSSAPI認証。「Kerberosを使用した認証」を参照してください。
   3. ドライバーによる使用のために自動的に選択される他のスキーマを指定します。

      Analyticsデータ・センター内の他のスキーマで内部認証とKerberos認証を両方使用することはできません。たとえば、default_schemeがinternalに設定され、other_schemesがkerberosに設定されている場合、Kerberos認証のみが機能します。

      other_schemesの場合、スキーマのリストを指定するか、これらの認証スキーマを1つ以上選択します。

      other_schemes:
      - kerberos
      - ldap

   4. ロールによって特定の認証スキームのパーミッションを要求するかどうかを指定します。
      強制するには、scheme_permissions:trueを設定します
   5. Kerberosによるdigest-md5認証を許可するかどうかを指定します。
      Kerberosによるdigest-md5認証を許可するにはallow_digest_with_kerberos: trueを設定します
   6. 暗号化されていないクライアント接続経由でDseAuthenticatorがプレーンテキスト認証要求に応答する方法を指定します。
      plain_text_without_sslの場合、以下の値のいずれかを選択します。

      • block - 要求を認証エラーでブロックします。
      • warn - 要求に関する警告をログに記録しますが、続行を許可します。
      • allow - 警告を出さずに要求を許可します。
   7. クラスターでの認証のセットアップ中、DataStax Enterprise認証は暫定モードで機能します。このモードは、ダウンタイムのない認証の有効化をサポートする一時モードです。DseAuthenticatorが暫定モードで動作するかどうかを指定し、許容、通常、または厳密な認証を設定します。
      transitional_modeの場合、以下の値のいずれかを選択します。

      • disabled - 移行モードは無効になります。
      • permissive - スーパーユーザーのみが認証されログインできます。他のすべての認証は匿名ユーザーとしてログインが試みられます。
      • normal - 認証情報が渡された場合、認証されます。
        • 認証が正常に実行された場合、ユーザーはログインします。
        • 認証が行われなかった場合、ユーザーは匿名ユーザーとしてログインします。
        • 認証情報が渡されなかった場合、ユーザーは匿名ユーザーとしてログインします。
      • normal - 認証情報が渡された場合、認証されます。
        • 認証が正常に実行された場合、ユーザーはログインします。
        • 認証が行われなかった場合、認証エラーが返されます。
        • 認証情報が渡されなかった場合、ユーザーは匿名ユーザーとしてログインします。
3. system_authおよびdse_securityキースペースを構成します。
4. キャッシュを構成します。パーミッションの呼び出しは負荷の大きい操作になる場合があります。必要に応じて、cassandra.yamlファイルのオプションを設定し、パーミッション・キャッシングの有効期間を調整します。あるいは、このオプションを0に設定してパーミッション・キャッシングを無効にすることもできます。
5. サポートされているクライアントを起動するために使用する同じスーパーユーザー名とパスワード（cassandra）を使用してcqlshを起動します。たとえば、Linuxでcqlshを起動するには：

   ./cqlsh -u cassandra -p cassandra

   cassandraユーザー名は例としてのみ提供されています。
6. デフォルトのスーパーユーザーを変更します。
   注: デフォルトのcassandraユーザーは、新しいユーザーとスーパーユーザーの初期セットアップを支援して、これを無効にする場合にのみ使用します。

   • cassandraユーザーのログインは、QUORUM整合性を使用して実行されます。

     実稼働環境ではデフォルトのcassandraユーザーを使用しないでください。複数のデータ・センターの場合、QUORUM整合性に重大なパフォーマンスの低下が生じます。

   • 他のすべてのユーザーのログインは、LOCAL_ONE整合性を使用して実行されます。

   セキュリティおよびパフォーマンスのベスト・プラクティス：

   • セキュリティに基づきユーザーの権利を制限します。たとえば、他のキースペースへのアクセスを許可しないでください。
   • デフォルトのスーパーユーザーを変更するには、次の手順を実行します。
7. ノードを再起動します。
   注: 既存のクラスターで内部権限管理をダウンタイムなしで有効にすることができます。
8. オプションで、権限およびロールの管理を構成します。