最初の章の「IDおよびアクセス管理」ではIAMやCognitoなどについて書かれていて、いずれもある程度知っているので読み進められそうではありましたが、IAMロールの図で出てきたSTSが少し気になりました。
STSといえばSecurity Token Serviceの名の通りセキュリティに関するトークンを払い出すサービスですが(そのまま過ぎw)、だいたい他のサービスやSDKが裏でうまい感じに使ってくれているので、今までSTS自体を調べたり触ったりすることがありませんでした。せっかくの機会なので理解を深めようと思ったものの、セッショントークンあるいはセキュリティトークンというものが分からなくて早速行き詰ってしまいました。
MFAなどと関連するもの?
セッショントークンという名前から何か有効期限を表すものなのだろうなぁという察しは付くのですが、調べてみてもアクセスキーIDとシークレットアクセスキーと共に当たり前のように出てきて、「いや、その正体が知りたいんだよ!」と何度も呟いてしまいましたw ただ、このセッショントークンを取得するのはSTSのGetSessionTokenであり、MFAやIAMロール、IDフェデレーションなどと関連するものということは分かったので、まずは改めてIAMユーザーの認証情報について確認しました。
- ユーザー名とパスワード
- アクセスキーIDとシークレットアクセスキー(合わせてアクセスキーと呼ぶらしい)
マネジメントコンソールにログインする時はユーザー名とパスワード、プログラムから使うときはアクセスキーですね、これはさすがに分かります。そしてこのユーザーにMFAを設定するとアクセスキーに加えてセッショントークンの出番が出てくるようです。実際に設定してみると確かにコンソールログイン時にはMFAコードを聞かれるようになりましたが、アクセスキーを用いてAWS CLIを使ってみると…、MFAコードなんて聞かれずに今まで通り使えてしまいました。何故だ!
MFAのセッションを作成する
そこで出てくるのが GetSessionToken です。
参考:MFA トークンを使用して、AWS CLI 経由で AWS リソースへのアクセスを認証する方法を教えてください。
–serial-numberにIAMユーザーで設定したMFAデバイスのARNを(何でSerial Numberなんでしょうね?)、–token-codeにMFAコードを入力してコマンドを実行すると、アクセスキーに加えて有効期限とセッショントークンを取得できました!
> aws sts get-session-token --serial-number {仮想MFAデバイスのARN} --token-code {MFAコード}
Credentials:
AccessKeyId: {access-key-id}
Expiration: '2021-08-08T16:05:30+00:00'
SecretAccessKey: {secret-access-key}
SessionToken: {temporary-session-token}
これらを環境変数に設定します。
> $env:AWS_ACCESS_KEY_ID="{access-key-id}"
> $env:AWS_SECRET_ACCESS_KEY="{secret-access-key}"
> $env:AWS_SESSION_TOKEN="{temporary-session-token}"
こうすることによって、MFAを行った状態のユーザーでAWS CLIを実行できます!
…で?
AssumeRoleと組み合わせる
単にGetSessionTokenするだけでは何の変化もありませんが、AssumeRoleも組み合わせると効果が発揮されるようです。IAMロールではAssumeRoleする時にMFAが行われていることを条件とすることができます。
> aws sts assume-role --role-arn {ロールのARN} --role-session-name {任意のセッション名}
AssumedRoleUser:
Arn: {一時的なロールのARN}
AssumedRoleId: {一時的なロールのID}
Credentials:
AccessKeyId: {access-key-id}
Expiration: '2021-08-08T05:11:55+00:00'
SecretAccessKey: {secret-access-key}
SessionToken: {temporary-session-token}
GetSessionTokenでMFAを行うとセッショントークンを含む認証情報を取得でき、それを使ってAssumeRoleを行うとMFAが済んでいることが条件のIAMロールを引き受けられるという流れですね。ちなみにGetSessionTokenではトークンの有効期限を15分~36時間の間で指定できますが(デフォルトは12時間)、AssumeRoleではIAMロールに設定された最大セッション時間(1~12時間でデフォルトは1時間)までしか指定できません。
設定ファイルでMFAとIAMロールを設定可能!
このように2回のコマンドと認証情報の設定でセキュアにロールを使用できるようになりますが、さすがにこれは面倒です。ですが、そこはさすがに便利な方法があって、configファイルに設定しておけばMFAコードを入力するだけで全てが完了します。
[profile mfauser]
region = ap-northeast-1
output = yaml
mfa_serial = {仮想MFAデバイスのARN}
role_arn = {MFAが必要なロールのARN}
source_profile = {AssumeRoleする時のプロファイル}
> aws --profile mfauser s3 ls
Enter MFA code for {仮想MFAデバイスのARN}:
裏で自動に行ってくれるのは便利ですが、一度は詳しく見るようにすると色々と見えてくるものですね。認証と認可とか後に出てくるIDフェデレーションとか「何となく知っていて使えなくもないけど詳細は分からない」ことの理解に役立ちます。実際に今回調べた時にIDフェデレーションとの関係も見えてきましたしね。それでは引き続きテキストを読み進めて行きましょうか。
…まだ10ページしか進んでねぇ!w
余談:セッショントークンとセキュリティトークンについて
調べ始めた時に混乱したのが、アクセスキーと共に出てくる言葉がセッショントークンだったりセキュリティトークンだったりすることでした。こちらも調べてみると、元々はサービスなどによって別々の呼び方になっていたのが徐々にセッショントークンへ統一されていったようです。AWSでは割とこういうことがあるイメージなのでネットで調べる時には気を付けた方がいいですね。