私はちょうどcassandraのdatastaxクラスタをインストールしました。 セキュリティグループとアクセスを制限する方法に関する質問があります。 現在、vnetとすべてのvmsにはセキュリティグループがありません。誰もがクラスタに接続できます。 サブネット上にセキュリティグループを設定しようとすると問題が発生します。これは、casandraノードのhttp通信が内部IPではなく公的なipで使用されているからです。 opscenterでhttp接続がダウンしているというエラーが表示されます。cassandra on azure、セキュリティグループの設定方法
質問はどのようにして（特定のIPのための）クラスタへのアクセスを制限できますか？しかし、動作するすべてのcassandraノードへのアクセスを提供しますか？
パブリッククラウド内で実行しているときにAzure、GCE、AWSなどのセキュリティを実行することをお勧めします。ノード間のゴシップ通信を保護するため、ノード間SSLを有効にすることは非常に良い考えです。次に、内部認証を導入して（最低でも）、cqlshにログインするためのユーザー/パスワードが必要です。また、クライアントをノードSSLにすることをお勧めします。ほとんどの場合、一方向で十分です。
私はAzureについてはあまりよく分かりませんが、AWSとGCEではインスタンスには内部的にルーティングされたローカルIP（通常は10.0.0.0/8プライベート範囲）しかなく、パブリックIPはNAT経由でしかありません。特に、内部IPがルーティングされない異なるアベイラビリティゾーンを実行している場合は、公衆IPをbroadcast_addressとして使用します。パブリックIPとしてbroadcast_rpc_addressを設定したい場合は、パブリックIP経由で接続するクライアントアプリケーションも実行している可能性があります。これらの両方はcassandra.yamlにあります。 listen_addressとrpc_addressはどちらもノードがバインドされるIPなので、ローカルで使用できる必要があります（つまり、ノード上のインターフェイスに設定されていないIPにプロセスをバインドできません）。非常に最低でもノードSSL
概要
便利docs
ここに書いてあることを強くお勧めします。セキュリティを導入することは、（アプリケーションが何であれ）スラグにぶつかると、ややこしいことになります。私いつもクラスタが安全でない状態でokを実行していることを確認してから、をというものを導入してテストし、検証してから次のことを紹介してください。一度にすべてを構成しないでください！
Client to node SSL - 1ウェイのためのfalseあるべきrequire_client_auth: trueに注意してください。
Unified authentication（内部、LDAP、ケルベロスなど）
注 SSLキーと本命を生成するとき、通常あなただけの1ペアを生成し、すべてにわたってそれを使用したいですあなたがノードからノードへのSSLを持っているときのノードそれ以外の場合は、新しいノードを導入する場合、新しい証明書をすべてのノードにインポートする必要があります。これは実際にはスケーラブルではありません。大規模なクラスタを使用している組織で働いていた私の経験では、これは物事を管理する方法です。また、クライアントアプリケーションは、少なくとも同じキーまたは別のキーを使用することもできます。
さらに詳細/読書
2ウェイSSLがサポートされていますが、1-方法として、そのような共通のされていません。これは、通常、もう少し複雑で、cassandra.yaml
でOpsCenterを使用している場合は、ドキュメント（下記）でカバーされます。なお、基本的にその2つの場所で：のOpsCenterとエージェントとのOpsCenterとエージェントとの間
私はこれがあなたが必要とするものを達成するのに役立つことを願っています！
ほとんどの場合、あなたはcassandraに直接アクセスする必要はありません。本番環境では、アプリケーション層へのアクセスのみを許可する必要があります。開発中にSSHトンネルを使用することができます。 – grochmal
私は同意します。問題はそれを行う方法です？内部のカサンドラ通信と外部からの制限との間に矛盾があります –
これに関する更新はありますか？ – Timmerz