目的
EC2 Instance Connect Endpointを使用してPrivate subnetにあるEC2へ接続する方法をご紹介します。
またIAMポリシーを用いたサーバ内OSユーザのアクセスコントロールも合わせてまとめます。
導入背景
AWS re:inforce 2023の中でEC2 Instance Connect Endpointが紹介され、これなら踏み台サーバを経由せずともPrivate subnet EC2に接続できる！と思い今回実装しました。
弊社環境ではPublic subnetの踏み台サーバの運用には鍵の管理や踏み台サーバの運用コスト(脆弱性対応・ランニングコスト)の課題があり、これらを解決すべくまずはテスト環境で導入してみました。
EIC endpointについて
従来インスタンスへのSSH/RDPでの接続にはPublic IPや踏み台インスタンスを用意する必要がありましたが、Public IP を持たないインスタンスに対しSSH/RDP接続が可能になるサービスです。
Service Quotas
サービスクウォータが小さいので、まずは実装前にご自分の環境に導入できるか検討する必要があります。
Quotas for EC2 Instance Connect Endpoint
Session manegerとの違い
Private subnet EC2に接続する手段としてEC2 Instance Connect Endpointの他にSession Managerが挙げられます。
違いについては以下でまとめられています。
EC2 Instance Connect Endpoint と Session Managerの違いをまとめてみた
可用性の観点ではSession manegerを選んだ方が良いですが、NAT gatewayやSSMVPCeを経由しないので接続に関わるコストが発生しないのが魅力的ですね。
実装
Security groupの作成
まずEIC endpoint用のSecurity groupを作成します。
ステートフルなのでOUTboundだけ作れば大丈夫です。
EIC endpoint用のSecurity group
| Type | Procotol | Port | Source |
|---|---|---|---|
| Egress/Outbound | TCP | 22 | 0.0.0.0/0 |
ログイン先のEC2のSecurity groupに以下のルールを追加します。
| Type | Procotol | Port | Source |
|---|---|---|---|
| Ingress/Inbound | TCP | 22 | 上記のEIC用SG |
EIC endpointの作成
EIC endpointの作成方法についてはこちらの方が書いた記事がわかりやすいです。
各自の使用するSubnetに作成してください。
EC2 Instance Connect Endpointを使ってEC2に接続してみた
EIC endpoint経由でのログイン
今回ログインしたEC2はAmazon linuxを使用しており、特に設定していない限りデフォルトでec2-userが作成されているのでこのユーザでログインします。
EIC endpointでこのログインできました。
エラーが出る際はIAMユーザに適切な権限がついているか、これまでの設定にミスがないか確認してください。
個人開発ならここまでで十分でしょう。
アクセスコントロール
業務の制約
弊社には踏み台サーバ経由でPrivate EC2サーバにアクセスするユーザは複数人程度存在し、ログの管理やアクセスコントロールの実施が必要になります。特にサーバ内のOSアカウントでユーザの管理やユーザに応じたroot権限への昇降性の有無を細かく制御する必要があります。
InstanceConnectを用いたアクセスコントロール
EC2 Instance Connectではカスタムユーザが提供されています。これはサーバにログインするOSユーザをIAMポリシーによってアクセス制限することが可能になります。
実装
Private subnet内のEC2でOSアカウントを作成
今回使用するEC2はAmazon LinuxなのでLinuxOSアカウントを作成します。この際に必要に応じてroot権限への昇降をコントロールする必要があります。
適宜業務に合わせた形でアカウントを作成してください。
IAMポリシーでの制御
Instance connectd経由でEC2にログインする場合は下記のポリシーを例に使用してリソースへのアクセス制御や使用するOSアカウント名を指定してください。
IAM への EC2 Instance Connect のアクセス許可の付与
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2-instance-connect:SendSSHPublicKey",
"Resource": [
"arn:aws:ec2:region:account-id:instance/i-1234567890abcdef0",
"arn:aws:ec2:region:account-id:instance/i-0598c7d356eba48d7"
],
"Condition": {
"StringEquals": {
"ec2:osuser": "test-username"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
}
]
}
EIC endpointでのログイン
ユーザ名はサーバ内でで作成したosアカウント名を同一のものを指定します。
問題なくログインすることができました。
試しにIAMポリシーで許可されていない適当なユーザ名でログインを試みると拒否されました。
もちろん、Linux側でrootへの昇降を許可していないユーザでsudo操作を試みても問題ありません。
(Linuxでの設定によりここら辺は各々で異なります)
まとめ
今回はEC2 Instance Connect Endpointを使用することで踏み台サーバ経由でのSSHログインを廃止する試みをしてみました。EIC endpointはデフォルトのサービスクウォータが低いことやAZに依存することはありますが、コストを削減できるのは大きなメリットだと思います。