概要
当エントリーでは、Nutanix Clusters on AWS (以後NCA)環境を構築時に自動的に作成されるセキュリティグループ(以後SG) に対し変更が発生するシチュエーションと対応について考えていきます。
- 概要
- NCAのセキュリティグループのデフォルト設定について
- ケース1. 既存 Nutanix Clusterの延伸
- ケース2. インターネット(IGW経由)からUVMへアクセスさせる構成への対応
- ケース3. NCAとAWSサービスの併用
- まとめ
- 関連エントリー
NCAのセキュリティグループのデフォルト設定について
NCA構築後のセキュリティグループのデフォルト状態を把握している前提で記載します。
NCAのセキュリティグループがどうように自動作成されるかについては、以下blogで詳細を記載しているので、まずは先にご参照頂ければと思います。
(改めて)Nutanixオフィシャルの言及
Nutanixにより自動作成されるSGのルールに関して以下言及があります。
If you want to modify these default rules, you must modify the user security group for management from the AWS console or APIs directly.
編集をするなという訳ではなく、「もし変更が必要な場合はAWS側のオペレーションで実施してくださいね」といった内容です。
今回はその 必要な場合 とは一体どのようなケースがあるか考えていきます。
ケース1. 既存 Nutanix Clusterの延伸
可用性を高めたり、DRサイトとして利用したり、マルチクラウド化したりと目的は様々だと思いますが、NCAを利用する際に多くが該当するであろうケースです。
インフラ構成としては、既存環境(主にオンプレミス)で稼働している Nutanix Clusterを 専用線(AWS Direct Connect)またはVPN(AWS Site-to-Site VPN)経由でAWSに構築した Nutanix Cluster (NCA)へと延伸する形となります。
こちらは多くが該当するケースなので、My NutanixのNCA構築画面に設定項目として用意されています。
Restricted or Disable となっていますが、
Restricted = Enable で有効化する際はセキュリティの理由から接続元指定して制限する必要があると理解してください。
こちらに延伸元のネットワークCIDR指定する事で、EC2ベアメタルインスタンスのENIにアタッチされているセキュリティグループ User Management のInboundに以下ルールが自動的に加わります。
(例) Restrected を選択し、例示IPアドレス(203.0.113.0/24)を指定した際に追加されるルール
IpProtocol FromPort ToPort CidrIpv4 SourceGroupId Description tcp 2020 2020 203.0.113.0/24 None Disaster Recovery tcp 3205 3205 203.0.113.0/24 None Stargate iscsi access for Files tcp 111 111 203.0.113.0/24 None Nutanix Move appliance tcp 3260 3260 203.0.113.0/24 None Stargate iscsi access for Files tcp 22 22 203.0.113.0/24 None SSH to both CVM and Hypervisor udp 111 111 203.0.113.0/24 None Nutanix Move appliance tcp 80 80 203.0.113.0/24 None Cluster remote support tcp 8443 8443 203.0.113.0/24 None Cluster remote support tcp 2009 2009 203.0.113.0/24 None Disaster Recovery udp 2049 2049 203.0.113.0/24 None Nutanix Move appliance udp 123 123 203.0.113.0/24 None NTP Service tcp 2049 2049 203.0.113.0/24 None Nutanix Move appliance tcp 7501 7501 203.0.113.0/24 None AFS services on CVM access for Files
- 設定画面で入力を忘れて構築してしまった
- 構築後にNutanix Cluster延伸元の情報が変更となった
- 構築作業段階で情報が未定である
...等々 の事情で、構築後に設定変更を行いたい場合はAWS APIから手動で当該セキュリティグループにレコードを追加する必要があります。
ケース2. インターネット(IGW経由)からUVMへアクセスさせる構成への対応
UVMのOS上にインターネットへ公開するWebサーバーを構築する場合等で利用が想定されるケースです。
ここでいうインターネット経由とは、具体的にはAWS Internet Gateway(IGW)方向からUVMへ対して通信を許可する場合となり、専用線やVPNの先にあるオンプレミス側のFWから入ってくる構成ではないのでご注意ください。
インターネット経由でPrismをアクセス許可して NCAを構築した場合に Prism用のNetwork Load Balancer(以後NLB)が作成されますがこちらはNCAが自動作成したPrism専用となる為、別途 UVM専用NLBとして AWS側のオペレーションで手動作成する事がNutanixオフィシャルからは推奨されています。
ちなみにNutanix社によると、ここでNLBを使ういうのは汎用的な1つの例であり、AWS側のベストプラクティスに沿いながらインフラで実装可能であれば利用出来るようです。
当手順に従いUVM用NLBを新規作成しただけでは、インターネット方向からUVMへ通信できません。
NCA構築時に自動作成されたセキュリティグループ User Management で UVM用NLB -> UVM 方向の通信が許可されていないことから穴を開ける必要があります。
上の図は NLBでTLSを終端させ、TCP:80がLISTENしているUVM上のWebサーバーへアクセスさせる例となりますが NLBにアタッチされたENIに付与されたPrivate IPアドレス(ランダム割当)を確認し、当該セキュリティグループのInboundで以下のように許可します。
(例) NLBのENIが10.0.3.200/32 であった場合
IpProtocol FromPort ToPort CidrIpv4 SourceGroupId Description tcp 80 80 10.0.3.200/32 None HTTP access for NLB
ケース3. NCAとAWSサービスの併用
NCAは、AWSインフラ(VPC)上に構築されるので、設定さえすれば他のAWSのサービスも併用が可能です。
例えば、NCA上で稼働しているUVM上のOSとAWS側で構築したEC2インスタンス上のOSとで通信させる事も可能という事です。EC2インスタンスは一つの例に過ぎないので、VPCから利用出来る様々なAWSのマネージドサービスで応用が効くとお考えください。
UVMとしてはアウトバウンド制御がされていないのがデフォルトとなります。 つまり対向となるEC2インスタンス側のセキュリティグループのInboundで許可がされていれば通信可能です。
これはAWS視点だとごく一般的な話なので割愛しますが、
逆の場合、つまりは EC2インスタンス -> UVMへの通信を実現したい場合はセキュリティグループ UVMに必要なInbound許可のルールを追加する事で通信が可能となります。
(例) SSH接続元のEC2インスタンスがが10.0.4.100 であった場合
IpProtocol FromPort ToPort CidrIpv4 SourceGroupId Description tcp 22 22 10.0.4.100/32 None ssh access from EC2Instance
こちらは全てのUVMが影響を受けるセキュリティグループでもあるので AWS側でざっくりと穴開けをしつつ、UVM単位の細かい制御がしたい場合は Nutanix Flowを利用して制御するイメージとなります。
(考察) セキュリティグループの独自ルールをどう管理すべきか
今回は、NCA構築時に自動的に作成、ENIにアタッチされたセキュリティグループに対してルールを追加するという前提で紹介してきましたが、各ENIの構成やら用途をきちんと把握できていれば 新規でセキュリティグループを作成してアタッチするという対応も可能 です。
どちらが良いでしょうか？
新規セキュリティグループとして作成する場合のメリデメについて考えてみました。どちらも良し悪しがあると思うので管理者視点で良いと思った方を採用してください。
メリット:
- AWS側のオペレーションで独自にルール追加した内容が明確となる
- オペミスのリスク低減 (SGのNutanixのデフォルトルールを含む編集画面へアクセスしなくて済む)
- 異なるUVMサブネット毎に異なるSGを割り当てる事である程度の制御をかける事が可能となる (NutanixのFlowで制御すべき話なので非推奨ではありますが技術的には可能という事で)
デメリット:
- UVMサブネットを分ける場合は、EC2ベアメタルインスタンスから当該サブネットへ異なるENIが伸びる構成となるため、必要な場合は手動アタッチ対応が必要
- NCAの利用を終了し削除(Terminate)する際に、AWS側のオペレーションで当該SGの手動削除対応が必要
まとめ
NCA構築時に自動作成されたセキュリティグループに対してAWS側のオペレーションで設定変更が必要となるケースについてご紹介しました。
これ以外のケースも思いついたら適宜追加します。
