概要
当エントリーでは、Nutanix Clusters on AWS (以後NCA)を構築するAWSアカウント環境にて設定をしておきたいAWSの設定項目について記載します。
はじめに
今回はrootユーザーにMFAを設定〜のような初期設定やアカウント権限管理周りは割愛し、とりあえず設定しておく事でNCA運用時の備えとなる 内容にフォーカスして紹介します。
AWS視点だとすべて基礎的な内容となりますが、普段AWSに触る機会がないNutanix界隈の方は、NCA構築時に今回紹介する設定がされている事で、仮にトラブルシューティング時に AWSレイヤーとして提供/活用出来る情報 が得られるという点についてご理解頂き連携時に役立てば幸いです。
AWSアカウント発行後に実施すべき内容は、以下の弊社のホワイトペーパーとして公開しておりますので、必要に応じてこちらもご参照ください。
AWS CloudTrail
AWSのユーザーアクティビティとAPI利用状況を記録してくれるサービスです。
例えばNCAを構成するAWSリソースに関して、「いつ、誰が、どのような変更した(APIを叩いた)か」の情報を残し、後から追うことが出来ます。
NCA構築時もMy Nutanix画面よりポチポチ作業する事となりますが、裏側ではNutanix社の保有するAWSアカウントからAWS APIが実行される事でNCA環境が出来上がっていますので当然、その際に実行されたAPIの情報も全て記録されます。
(参考) AWS CloudTrailイベント履歴画面
AWS CloudTrail は、AWSアカウント新規開設時から管理イベントのみデフォルトで有効化されており90日間保存される状態となっていますが、必要に応じてデータやInsightと取得する種類の範囲を広げたり、監査目的であれば改ざん出来ないよう設定したS3バケットへ永続保存を検討します。
AWS Config
AWSインフラの構成管理のサービスです。
リソースの構成や変更履歴等を管理する事に加えルールに準拠しているかチェックする機能も備えます。
NCAの場合は、構築されたAWSインフラの構成情報の管理で活用出来ます。
例えば構築後にNCAを構成するAWSインフラリソースに対して行われた変更履歴を情報として残し、後から追うことができます。
NCA構築後にもUVM用サブネットの作成やらセキュリティグループを変更するようなAWS側のAPIで実施されるオペレーションがありますが、その際の設定変更について、変更前の構成と変更後の構成情報を残すことができます。
[1-cliskセットアップ] であれば1クリックで、必要最小限の設定で S3バケットに情報を残すことが可能です。
未設定であれば NCA構築前に設定しておいたほうが良いでしょう。
(参考) タイムライン機能
リソース単位で発生したイベントをタイムラインで表示する機能があり、構成履歴 や 設定変更時の差分 やCloud Trailのイベントを時系列で確認できるので便利です。
参考blog
VPC Flow Logs
VPC内のネットワークのIPトラフィックをキャプチャできる機能です。
ネットワーク機器のパケットキャプチャーのような用途で活用できます。
AWSを管理する上では、特にAWS側まで通信が到達しているか否か、セキュリティグループを通過しているか否かの確認でよく利用されます。
NCAを管理する場合もOSのレイヤーやNutanixのレイヤーでネットワーク到達の判断が出来ない場合等のトラブルシューティング時などにこちらの情報を活用出来る場合があります。
利用するには、My Nutanixの画面から 新規VPCを作成する設定にてNCAを構築するとVPC Flow Logsはデフォルト設定のままで有効化されていないので 手動で有効化 する必要があります。
VPC Flow Logsは ENI単位、Subnet単位、VPC単位で有効化の設定が可能ですが NCA専用のVPCであれば「VPC全体」で有効化設定してしまうのがオススメです。(既存リソースは勿論、以後そのVPC内に作成されたENI全てで同様の設定が自動的に有効となるので、取得漏れを楽に防げるといった具合です)
VPC Flow Logsの出力先は、CloudWatch Logs と S3バケット で選択可能です。(両方に飛ばす事もできます)
やたらめったな事で見ないような環境で備えとして保管しておく程度であれば低コストにS3バケットへの出力だけでも良いかもしれませんが、運用面も加味すると主にトラブルシューティングで活用される性質からして一定期間を定め CloudWatch Logsへ保管しておくのが良いでしょう。
(参考) UVMと外部のEC2インスタンスの通信ログ(CloudWatch Logs)
以下図のようにNCA上で稼働するUVM -> NCAとは別のEC2インスタンスへの通信に関して NCA内のUVMに割り当てられている IPアドレス(ENIに割り当てられたセカンダリ)が直接VPC Flow Logsに載ってくるので切り分け等で有効に活用出来ます。
ここで当該通信が ACCEPT していたらセキュリティグループor NACLを通過している、逆にREJECTならルールを通過出来ていない。そしてログにそもそも載ってこないのであれば、当該ENIまで通信が到達していない といった具合です。
その他
ここまで紹介してきたサービスについては、NCAが稼働するAWS新規アカウントで とりあえず有効化 し、情報を取得しておく事でいざ調査が必要となった際に役立つものでしたが、以下サービスはただ有効化しただけでは意味をなさず、管理者としてチェックしたり改善活動の運用が伴うものとなります。
こちらもアカウントの用途やら組織のポリシーを踏まえAWS利用開始時に合わせて検討してください。
まとめ
今回は Nutanix Clusters on AWS 構築前にAWS側で設定しておきたい項目についてご紹介しました。
Nutanixのレイヤーより下のレイヤーで調査に役立つ情報となりますので、いざという時の備えとして設定を検討してみてください。
