本記事はAWSでWordPressブログを立ち上げるまでの過程を、
キリの良いところで区切った内容になっています。
通して確認されたい方は以下を先に確認してみてください！
はじめに
以下の方法でSSH接続をしている方、意外と多い気がします。
- SSH（22）をマイIPで開放 → パブリックIPで接続
- SSH（22）を接続元を絞って解放 → プライベートIPで接続
前者は初心者向けの記事とかでよく目にしますよね。
後者は会社勤めのエンジニアの方でも意外とやってませんか。
SSHポート開けないのがベストプラクティスなのは分かってるよ！
でも新しいことやってる時間ないのよ！
というのが後者の私だったので、第二章ではいきなり
- AssumeRoleで一時認証情報を取得 → AWS CLIからstart-session
を勉強がてらやってみます！
ということで本編です。
そもそもAssumeRoleとはなんぞ
※AWSを勉強されている方向け
呪術廻戦で例えると、乙骨 憂太 のコピー術式（里香の解呪後）な気がします。
乙骨の術式は、コピー対象の肉体の一部を里香に取り込ませることで、
里香と接続している5分間は対象の術式を使用できるというものです。
強い術式は取り込む量が多くないといけないなどの縛りあり。
真面目にいくと、AWS STS (AWS Security Token Service)のAssumeRoleというアクションです。
ロールを指定してsts:AssumeRoleを行うと、呼び出し元と対象ロールのポリシーを確認して
ロールを使用しても問題ない場合はトークンが発行されます。
そのトークンを使用して呼び出し元はロールを使用することができます。
比較するとこんな感じです。
| 乙骨 & 里香 | AssumeRole |
| コピー対象の肉体の一部を取り込む | 使用したいロールを指定してAssumeRole |
| コピーする術式に対して、取り込んだ量が足りているか | 呼び出し元がロールを使用できる許可があるかポリシーを確認（MFA込み） |
| コピーした術式を里香と接続している5分間は使用することができる | 取得したトークンを使用してIAMロールを使用 トークンには時間制限付き |
以降の内容はこんな感じです。
- 何も権限を与えていないIAMユーザの作成（要MFA）
- 作成したIAMユーザからのAssumeRoleを許可したIAMロールの作成
- ロールにはセッションマネージャーで指定したインスタンスにstart-sessionできるポリシー
何もできないIAMユーザがAssumeRoleすることで、
一時的に指定したEC2インスタンスにセッションマネージャー接続できるようになる という内容です。
アクセスキーが漏洩したとて何も権限はありませんし、
一時認証が漏洩したとて時間制限がありますのでずっとは使えないという二段構えです。
IAMユーザとロールの作成
AssumeRoleをするためのIAMユーザと
セッションマネージャーのstart-sessionを許可したIAMロールを作成します。
・IAMユーザ作成
マネジメントコンソールを開いているブラウザで以下をクリックすると作成画面に飛びます
IAMユーザ作成
ユーザ名は任意の値、マネジメントコンソールへのアクセスは不要です
許可は何も設定しなくて良いです。次へを押します
タグも任意で大丈夫です。ユーザーの作成 を押します
・IAMポリシー作成
作成画面でJSONを指定して、以下の内容を入力します。
赤字の部分は接続するインスタンスIDに置き換えてください。
こちらを確認して設定しています。公式ドキュメント大事
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-restrict-access-quickstart.html#restrict-access-quickstart-end-user
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ssm:GetConnectionStatus",
"ssm:DescribeSessions",
"ssm:DescribeInstanceProperties"
],
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ssm:ap-northeast-1:[account-id]:document/*",
"arn:aws:ecs:ap-northeast-1:[account-id]:task/*",
"arn:aws:ssm:ap-northeast-1:[account-id]:managed-instance/[instance-id]",
"arn:aws:ec2:ap-northeast-1:[account-id]:instance/[instance-id]"
],
"Condition": {
"BoolIfExists": {
"ssm:SessionDocumentAccessCheck": "true"
}
}
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"ssm:ResumeSession",
"kms:GenerateDataKey",
"ssm:TerminateSession"
],
"Resource": [
"arn:aws:ssm:ap-northeast-1:[account-id]:session/*",
"arn:aws:kms:ap-northeast-1:[account-id]:key/*"
]
}
]
}
ポリシー名や説明、タグは任意の値を設定して ポリシーの作成 を押します
・IAMロール作成
カスタム信頼ポリシーを選択して、画面下部のポリシー欄に以下の内容を入力します。
赤字の値を置き換えるか、作成したIAMユーザのARNを置き換えてください。
指定したIAMユーザがこのロールにAssumeRoleできるという許可です。
ちなみにMFA認証も必須にしてます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[account-id]:user/[iam-user-name]"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
先ほど作成したポリシーを検索してチェックを入れます
ロール名や説明、タグは任意の値を設定して ロールを作成 を押します
ここまでで、作成したIAMユーザのアクセスキーでMFA認証を突破すると
作成したIAMロールにAssumeRoleできるようになりました。
AWS CLIの設定
・AWS CLIのインストール
まだインストールされていない方は以下のリンクから
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html
・MFA設定
作成したIAMユーザの画面から、セキュリティ認証情報 > MFAデバイスの割り当て で設定できます。
まさおは Google Authenticator を使用したので「認証アプリケーション」で設定してます。
・アクセスキー発行
先ほどのMFA設定の下にアクセスキー欄があります。
コマンドラインインターフェース（CLI）を選択します。
最後に代替案の警告のようなものが出ますが無視で大丈夫です。
チェックを入れて次へ
説明は何も入力せず アクセスキー を作成
表示されたアクセスキー/シークレットアクセスキーをコピーしておくか、
csvをダウンロードしておきましょう。
※
何もせず画面遷移してしまうとシークレットアクセスキーの確認ができなくなります！
やってしまった場合は作成したものを削除して新しいものを作成すれば大丈夫です。
・AWS CLIにアクセスキー設定
以下のコマンドで設定できます。
PS C:\Users\xxxxx> aws configure --profile ssm
AWS Access Key ID [None]: ← アクセスキー
AWS Secret Access Key [None]: ← シークレットアクセスキー
Default region name [None]: ← デフォルトのリージョン ap-northeast-1(東京)
Default output format [None]: ← コマンドの実行結果などが返ってくる際の形式 JSONちなみに、–profile [profile名] を付け足しています。
AWS CLIコマンドを実行する際にprofileを指定すると、そのcredentialsが使用されます。
複数のcredentialsを使用する際には必須と言えますね。
AssumeRole
以下のコマンドでAssumeRoleする
aws sts assume-role --role-arn [作成したロールのARN] --role-session-name AssumeRoleSession --serial-number [MFAデバイスARN] --token-code [6桁のコード] --profile ssm–role-arn [作成したロールのARN] ： 作成したIAMロールの画面↓
–role-session-name AssumeRoleSession ： 任意のセッション名
–serial-number [MFAデバイスARN] ： MFAデバイスを設定したとこ↓
–token-code [6桁のコード] ： 設定したMFAデバイスに表示されている6桁のコード
–profile ssm ： profileを設定した場合、その名前
設定が問題なければ一時credentialsがJSONで返ってきます。
# サンプル（以下は使えません）
{
"Credentials": {
"AccessKeyId": "XXXXXXXXXXXXXXXXXXXXX",
"SecretAccessKey": "YYYYYYYYYYYYYYYYYYYYYYYYYY",
"SessionToken": "IQoJb3JpZajsangnewagnonklgnkmnda:ji9u285hhjifj8u8yh4VBFubqBeyqnAgiH//////////8BEAAaDDk3MTQyMjY5ODQ5MyIMT7Bgb1KT9aAdGcjEKvsBWRJlSvyxgd9KE2YTXp2qn2WOj3jNX/ooXJ21x/pZrK52zXabykJd3CiGCAiiCk/pT+askgnfnanregnrneam+P5eNUEO95i++i5d0QWWmZA156ojJaSsc+/rozux9rlBNZAXJlrU4+m+aLC41n5aHGF1bgWAK2TQBxeXXrEoybQYklzspgYLwVHofn5q7dmNgge41QRPNbGGp/HkKtxspIJYhU52VaF7C0b+gIW8pSG//Fw/5VMqfs00eId+DbK8kNdT+VgVODMsQJIl+kKhckufjjz05ndZUN0wxKDutwY6nQGhLC3YV4+jEUbOXmKv6Zcqr830asgdnagnrlnvaeij90ut034jhijaThlyU/x+9228eVxfoSHangran;ioijroeapm:e*Lgoorjeaj[]amkagnooguherlmPoFj/LOuLS7kq38+3z4gSy",
"Expiration": "2024-10-01T07:01:40+00:00"
},
"AssumedRoleUser": {
"AssumedRoleId": "ACSDGKNNER445FGNFNVH:AssumeRoleSession",
"Arn": "arn:aws:sts::[account-id]:assumed-role/ec2-session-manager-role/AssumeRoleSession"
}
}
このcredentialsを設定ファイルに追記していきます。
ファイルの場所は公式ドキュメントに記載されています。
https://docs.aws.amazon.com/ja_jp/sdkref/latest/guide/file-location.html
まさおはWindowsですので以下ですね。
%USERPROFILE%.aws\config
%USERPROFILE%.aws\credentials
profile名をssm-roleで設定する例は赤字の部分です。
先頭に記載されている[profile ssm]は先ほどのaws configureで、–profileから指定したものですね。
# %USERPROFILE%.aws\config
[profile ssm]
region = ap-northeast-1
output = json
[ssm-role]
region = ap-northeast-1
output = json# %USERPROFILE%.aws\credentials
[ssm]
aws_access_key_id = AKIA6ELKOBP6XJ6K37PN
aws_secret_access_key = 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
[ssm-role]
aws_access_key_id = JSONの"AccessKeyId"
aws_secret_access_key = JSONの"SecretAccessKey"
aws_session_token = JSONの"SessionToken"ここまでの作業でAWS CLIコマンドに –profile ssm-role を付け足すと、
AssumeRoleしたロールでの操作ができるようになります。
セッションマネージャー start-session
以下のコマンドを実行するとstart-sessionできます。
aws ssm start-session --target [instance-id] --region ap-northeast-1 --profile ssm-role–target [instance-id] ： 接続するインスタンスID
–region ap-northeast-1 ： 接続するインスタンスがap-northeast-1（東京）以外の場合は変更
–profile ssm-role ： 設定したprofileに合わせて変更
PS C:\Users\xxxxx> aws ssm start-session --target [instance-id] --region ap-northeast-1 --profile ssm-role
Starting session with SessionId: AssumeRoleSession-ej5g56avxapp6gl43x7qrnzhpy
sh-5.2$
sh-5.2$
sh-5.2$ date
Tue Oct 1 06:28:27 UTC 2024サーバに接続できてdateコマンドが実行できています。
おわりに
今回はAssumeRoleで取得した一時cedentialsでセッションマネージャー接続をしました。
これでSSHポートを開かずに、一時認証情報を用いたセキュアな接続ができます。
アクセスキーの発行自体があまり良くないことな気はしますが、AssumeRoleやAWS CLIからセッションマネージャー接続をするということを勉強のためにやってみました。
マネジメントコンソール上でセッションマネージャーも使えますし、
アクセスキー発行の代替案にもあったCloudShellからもできるので無理にこの方法をとる必要はないですね。
次回は接続したEC2のOS設定をします！
