AWS ParallelCluster クラスター作成時に自動作成するセキュリティグループのルールと FSx for Lustre をマウントするときに必要なルール設定を確認してみた

2022.09.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS ParallelCluster のヘッドノード、コンピュートノードから FSx for Lustre をマウントする際に各ノードのセキュリティグループを見直す機会がありました。AWS ParallelCluster が自動作成するセキュリティグループのルールの備忘録です。

確認結果

ヘッドノードと、コンピュートノード用のセキュリティグループが個別に自動作成されます。

ヘッドノード

  • インバウンド
    • ソース: 0.0.0.0/0 から SSH(22番ポート)を許可
    • ソース: コンピュートノードからすべてのトラフィックを許可
  • アウトバウンド
    • ターゲット: 0.0.0.0/0 すべてのトラフィックを許可

コンピュートノード

  • インバウンド
    • ソース: ヘッドノードからすべてのトラフィックを許可
    • ソース: コンピュートノードからすべてのトラフィックを許可
  • アウトバウンド
    • ターゲット: コンピュートノードからすべてのトラフィックを許可
    • ターゲット: 0.0.0.0/0 すべてのトラフィックを許可

注意事項

パブリックサブネットでヘッドノードを起動する場合は SSH 全開放の AWS ParallelCluster デフォルトセキュリティグループにご注意ください。

ヘッドノード、コンピュートノードからマウントする各種ストレージサービス(FSx、EFS)に対して双方のセキュリティグループのルール設定にご注意ください。

ストレージサービス側のセキュリティグループのインバウンドのルールを許可するのはもちろん、ヘッドノード、コンピュートノード側のセキュリティグループのインバウンド、アウトバウンドの許可設定は必要ないかストレージサービスのドキュメントを確認しましょう。

FSx for Lustre の例

具体的には FSx for Lustre 場合ですと以下のドキュメントに載っている Lustre Client は AWS ParallelCluster で言うとヘッドノード、コンピュートノードに該当します。

File System Access Control with Amazon VPC - FSx for Lustre

FSx for Lustre をマウントするときはヘッドノード、コンピュートノードのセキュリティグループのインバウンド、アウトバウンドのルール追加が必要です。

検証環境

項目
ParallelCluster 3.2.0
OS Ubuntu 20.04
CPU Intel
Head Node t3.micro
Compute Node t3.micro

確認してみた

AWS ParallelCluster のデフォルトのセキュリティグループ設定を確認します。

ドキュメントを確認する

ヘッドノード

自動作成のセキュリティグループの代わりに任意のセキュリティグループをアタッチするか、任意のセキュリティグループを追加でアタッチするオプションが用意されています。

SecurityGroups (Optional, [String])
AdditionalSecurityGroups (Optional, [String])

コンピュートノード

ヘッドノードと同様のオプションが用意されています。

SecurityGroups (Optional, [String])
AdditionalSecurityGroups (Optional, [String])

自動作成のセキュリティグループの代わりに任意のセキュリティグループをアタッチするときの注意事項がありました。

EFA を有効化しているインスタンス同士のインバウンド・アウトバウンドをすべて許可したルールが必要です。要はヘッドノードのセキュリティグループには注意事項がないことから、コンピュートノードの自身のセキュリティグループからセキュリティグループへすべて許可したルールがあればよいということでしょう。

If you're enabling Efa for your compute instances, ensure that your EFA-enabled instances are members of a security group that allows all inbound and outbound traffic to itself.

Scheduling section - AWS ParallelCluster

自動作成されたセキュリティグループを確認する

ヘッドノード

  • ソース: 0.0.0.0/0 から SSH(22番ポート)を許可
  • ソース: コンピュートノードからすべてのトラフィックを許可

  • ターゲット: 0.0.0.0/0 すべてのトラフィックを許可

コンピュートノード

  • ソース: ヘッドノードからすべてのトラフィックを許可
  • ソース: コンピュートノードからすべてのトラフィックを許可

  • ターゲット: コンピュートノードからすべてのトラフィックを許可
    • ドキュメント内で説明があった通り明示的に許可を入れてあります
  • ターゲット: 0.0.0.0/0 すべてのトラフィックを許可

おわりに

ヘッドノードのセキュリティグループは22番ポートを全開放しているため、パブリックサブネットで起動時は自動作成されたセキュリティグループの設定変更か、任意のセキュリティグループをアタッチすればセキュアにご利用いただけるかと思います。 プライベートサブネット(= インターネットから直接アクセスできないサブネット)でヘッドノード、コンピュートノードを起動し、セッションマネージャーで接続することが多いため意識していませんでした。