こんにちは、技術1課 長崎です。
表題の通り、やり方のまとめを記載します。
Session Managerは、Systems Manager(以下SSM)の機能の一つです。
前提
- Linux OSのEC2インスタンスへの接続
- クライアント端末はWindows
- 東京リージョンで実行
全体の流れ
今回、Account AのIAMユーザーが持つ権限でAccount BのIAMロールにスイッチして、SSM Session Managerを利用してEC2へ接続します。
これをAWS CLIでやります。
手順
Account B(EC2インスタンスがいるAWSアカウント)の準備
IAMロールの作成
Account AのIAMユーザー権限でAssumeRoleするIAMロールです。
以下が必要最低限のポリシーです。
※環境内全てのEC2へログインしたい場合は、[Resource]プロパティのinstance idを*(アスタリスク)にします。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:ap-northeast-1:<Account BのAWSアカウントID>:instance/<instance id>"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
信頼関係のポリシーは以下を記述します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Account AのAWSアカウントID>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
EC2のポリシー設定
EC2に割り当てるIAMロールの中で、SSMへの操作権限を付与しておきます。
「AmazonSSMManagedInstanceCore」という必要なアクセス権限が含まれたAWSマネージドポリシーの選択がおすすめです。
このポリシーにはS3の操作権限が含まれていない為、操作ログをS3バケットに保管したい場合は追加で以下のポリシーを付与してください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "sessionlog",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::<S3 Bucket Name>/*"
]
}
]
}
EC2へSSMエージェントをインストール
デフォルトでプリインストールされているOS以外は、手動でインストールする必要があります。
- ドキュメント：
EC2 インスタンスに SSM エージェントを手動でインストールする (Linux 用) - AWS Systems Manager
SSM エージェントは、以下の Amazon Machine Images (AMIs) にデフォルトでプレインストールされています。
Amazon Linux
Amazon Linux 2
Amazon Linux 2 ECS に最適化された AMIs:
Ubuntu Server 16.04、18.04 および 20.04
EC2からSSMエンドポイントへの経路確保
EC2からインターネット上のSSMエンドポイントへの経路を確保します。
EC2がElastic IPを持ってパブリックな環境にいるかNAT経由でインターネットに出られるなら問題ないです。
完全閉域網のEC2の場合は、PrivateLink(VPC EndPoint)を利用します。
ステップ 6: (オプション) AWS PrivateLink を使用して Session Manager 用の VPC エンドポイントをセットアップする - AWS Systems Manager
Account A(IAMユーザーがいるAWSアカウント)の準備
IAMユーザーへAssumeRole権限の割り当て
IAMユーザーを作成後、以下のポリシーを設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam:: <Account BのAWSアカウントID>:role/<AssumeRole先のIAMロール名>"
}
]
}
クライアント端末側の準備
AWS CLIをインストール
以下を参考にインストールします。
AWS CLI バージョン 2 のインストール、更新、およびアンインストール - AWS コマンドラインインターフェイス
Session Manager Pluginをインストール
以下を参考にインストールします。
(オプション) AWS CLI 用の Session Manager プラグインをインストールする - AWS Systems Manager
AWS CLIを設定する
credentialsファイルに作成したIAMユーザーのアクセスキー・シークレットキーを設定します
[default] aws_access_key_id = xxxxxxxxxxxxxxxxxxxxx aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxx
configファイルにはAssumeRole先のIAMロールを設定します。
[profile assumerole] #profile名は任意です region = ap-northeast-1 output = json mfa_serial = arn:aws:iam::<Account AのAWSアカウントID>:mfa/<IAM User Name> #AssumeRoleする時のMFA認証を有効化 role_arn = <AssumeRoleするIAMロールARN> source_profile = default
以上で、プロファイル[assumerole]をAWS CLI実行時に指定する事で、role_arnのIAMロールへAssumeRoleしてその際に得た一時的な認証情報でAPIを実行できます。
アクセスしてみる
クライアント端末でコマンドを実行する。
aws ssm start-session --target <instance-id> --profile assumerole
アクセスが成功しました。
Starting session with SessionId: botocore-session-111111111-0000000000000 sh-4.2$
まとめ
Session Managerを利用すれば、SSH鍵や踏み台サーバの管理がいらなくなる為、セキュリティが向上します。
SSMにはRunCommand等、運用を楽にする機能が豊富ですのでぜひ一度利用してみてください。
