この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ちゃだいん（@chazuke4649）です。
Session Manager で特定の EC2 のみアクセスできるよう制限してみます。
前提
AdministratorAccessの権限を持つIAMユーザーが対象のEC2インスタンスに対して、Session Managerをすでに使用できる状態（＝Session Managerが利用可能な設定が完了している状態）とします。- 制限対象はすでに作成済みのIAMユーザー
TestUserA - デフォルトのIAMポリシーとしては
ReadOnlyAccessを付与し、参照はできる状態とする - 環境は同じAWSアカウントのEC2インスタンス
i-0885b2e35926f1fb3 - 設定は管理者ユーザーが全て行う
基本的には以下公式ドキュメントのIAMポリシーサンプルを参考にします。
Session Manager の追加サンプル IAM ポリシー - AWS Systems Manager
先にテスト結果
今回は以下３つのアクションに対してIAMポリシーで記述します。
ssm:StartSession: 新しくセッションを開始するssm:TerminateSession: 既存のセッションを終了するssm:ResumeSession: 既存のセッションを再開する
そのうち、セッションの開始と終了を試しましたが、この後紹介する３パターンで意図した動作が確認できました。
許可された時
新しくセッションを開始する
EC2コンソールから、対象のインスタンスを選択し、Connect画面を開きます。
Session Managerを選択し、Connectボタンを押します。
そうするとターミナルが開き、コマンドが実行できる状態になります。
既存のセッションを終了する
ターミナルでexitコマンド等でも終了できますが、あえてSSMコンソールからセッションを終了させます。 以下の通り、現在のセッションが表示されているので、これを終了させます。
無事終了できると、以下の通り成功したことがわかります。
拒否された時
新しくセッションを開始する
対象のインスタンスにてセッションの開始が許可されていないと、先ほどのConnect画面でConnectボタンを押した後、ターミナルが開かずに、SSMコンソールにてエラーが表示されます。
既存のセッションを終了する
例えば、自分以外のユーザーのセッションを終了しようとすると、以下の通りエラーが表示され拒否されます。
1.ARNを使用するパターン
例 1: 特定のマネージドノードへのアクセスを制限 - AWS Systems Manager
上記公式ドキュメントのサンプルほぼそのままです。 最もシンプルなパターンで対象のインスタンスに変更がない場合、これでOKです。
手順
- 以下ポリシーを対象のIAMユーザーにアタッチする
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0885b2e35926f1fb3"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}補足
- 指定したARNのインスタンスしかセッションを開始できない
- Prefixが自分のユーザー名の既存セッションしか終了・再開できない
2.タグを使用するパターン（定数・固定）
例 2: タグに基づいてアクセスを制限 - AWS Systems Manager
こちらも上記公式ドキュメントのサンプルほぼそのままです。 次にシンプルなパターンで、ARN指定は変わりうるのでやめたく、代わりにポリシーに記載したタグで許可/拒否したい場合に有効です。
手順
- 以下ポリシーを対象のIAMユーザーにアタッチする
- 対象のインスタンスに
Project: testタグを付与する
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:ap-northeast-1:123456789012:instance/*"
],
"Condition": {
"StringEquals": {
"ssm:ResourceTag/Project": [
"test"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}補足
Project: testタグがアタッチされたインスタンスしかセッションを開始できない- Prefixが自分のユーザー名の既存セッションしか終了・再開できない
3.タグを使用するパターン（変数・ABAC）
最後は2.を ssm:StartSession の条件だけ少し変え、ABAC（属性ベースアクセスコントロール）にした場合です。
IAMポリシー内のConditionのProjectタグが固定でなくなるので、１つのポリシーで最も柔軟に対応できます。ただし、その分設定内容も増えます。
そもそもABACについては、以下ブログなどをご覧ください。
AWSにおけるABACの嬉しさ、辛さを語りました #AKIBAAWS | DevelopersIO
このアクション、ABAC ないし RBAC に対応してる？難解な IAM リファレンスに立ち向かうための地図を描いてみた | DevelopersIO
手順
- 以下ポリシーを対象のIAMユーザーにアタッチする
- 対象のIAMユーザーに
Project: testタグを付与する - 対象のインスタンスに
Project: testタグを付与する
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:ap-northeast-1:123456789012:instance/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}補足
- IAMユーザーとECインスタンスで
Projectタグの値が一致したインスタンスしかセッションを開始できない - Prefixが自分のユーザー名の既存セッションしか終了・再開できない
- JSONハイライト箇所箇所が
ssm:ResrouceTagからaws:ResourceTagに変更している点が要注意
ちなみに、対象AWSサービスがABACに対応しているかどうかは下記表にて確認が必要です。
AWS services that work with IAM - AWS Identity and Access Management
終わりに
次回は AWS SSO でやってみます。
それではこの辺で。ちゃだいん（@chazuke4649）でした。
8
