EIC endpointで踏み台serverを無くす

# 目的
EC2 Instance Connect Endpointを使用してEC2へ接続する方法をご紹介します。
またIAMポリシーを用いたサーバ内OSユーザのアクセスコントロールも合わせてまとめます。

# 導入背景
AWS re:inforce 2023の中で[EC2 Instance Connect Endpoint](https://pages.awscloud.com/rs/112-TZM-766/images/20230906_reInforce2023_ISV_DiveDeepSeminar_yhirokiy_EIC_Endpoint.pdf)が紹介され、これなら踏み台サーバを経由せずにPrivate subnet EC2へ接続できるようになりました。

# EIC endpointについて
従来インスタンスへのSSH/RDPでの接続にはPublic IPや踏み台インスタンス、SSMを用意する必要がありましたが、無料でPublic IP を持たないインスタンスに対しSSH/RDP接続が可能になるサービスです。

### Service Quotas

サービスクウォータは小さいので、まずは実装前にご自分の環境に導入できるか検討する必要があります。
[Quotas for EC2 Instance Connect Endpoint](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/eice-quotas.html)


### Session manegerとの違い
Private subnet EC2に接続する手段としてEC2 Instance Connect Endpointの他にSession Managerが挙げられます。
違いについては以下でまとめられています。
[EC2 Instance Connect Endpoint と Session Managerの違いをまとめてみた](https://dev.classmethod.jp/articles/compare-eic-endpoint-and-session-manager/)

可用性の観点ではSession manegerを選んだ方が良いですが、NAT gatewayやSSMVPCeを経由しないので接続に関わるコストが発生しないのが魅力的です。


# 実装
###  Security groupの作成
まずEIC endpoint用のSecurity groupを作成します。

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に接続してみた](https://blog.denet.co.jp/ec2-instance-connect-endpoint/)


###  EIC endpoint経由でのログイン

今回ログインしたEC2は``Amazon linux``を使用しており、特に設定していない限りデフォルトで`ec2-user`が作成されているのでこのユーザでログインします。

![スクリーンショット 2024-06-02 8.38.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531294/7efa0189-f103-b3a8-c8dc-7af80cd10fdb.png)


EIC endpointでこのログインできました。
![スクリーンショット 2024-06-01 14.32.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531294/ebf4c267-d564-cc5c-76b8-1c8c4d6062d4.png)

# アクセスコントロール

### 各ユーザへのアクセス制限
デフォルトのec2-userでは、組織内において、共通で使用することが許されないところもあるので、EICeを使用する各ユーザに応じて制御方法を一つ紹介します。

### InstanceConnectを用いたアクセスコントロール
EC2 Instance Connectではカスタムユーザが提供されています。これはサーバにログインするOSユーザをIAMポリシーによってアクセス制限することが可能になります。


## 実装

### Private subnet内のEC2でOSアカウントを作成
サーバー内でアカウントを作成します。この際に必要に応じてroot権限への昇降をコントロールする必要があります。

適宜業務に合わせた形でアカウントを作成してください。

### IAMポリシーでの制御
Instance connectd経由でEC2にログインする場合は下記のポリシーを例に使用してリソースへのアクセス制御や使用するOSアカウント名を指定してください。
[IAM への EC2 Instance Connect のアクセス許可の付与](
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-connect-configure-IAM-role.html)
```{
	"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アカウント名を同一のものを指定します。

![スクリーンショット 2024-06-02 8.39.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531294/8add58a9-b928-964b-6bc4-07cdb34dbd14.png)


 問題なくログインすることができました。
![スクリーンショット 2024-06-01 14.42.46のコピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531294/76ef5ff9-0a9c-6d2a-157b-efaa1e76f21d.png)


 
 試しにIAMポリシーで許可されていない適当なユーザ名でログインを試みると拒否されました。

![auth-error.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531294/2e4e92a0-b3cc-dac5-5168-1e433fb5dc4b.png)


 もちろん、rootへの昇降を許可していないユーザで昇格を試みても問題ありません。(Passwordは無効です)
![スクリーンショット 2024-06-01 14.54.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3531294/1636c850-529a-f7f6-debe-695f5ef1f58b.png)

# まとめ

今回はEC2 Instance Connect Endpointを使用することで踏み台サーバ経由でのSSHログインを廃止する試みをしてみました。EIC endpointはデフォルトのサービスクウォータが低いことやAZに依存することはありますが、コストを削減できるのは大きなメリットだと思います。