3
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

AWS SSO + CLIでロール連鎖をする際のセッション時間制限をマシにする方法を考えてみた

Last updated at Posted at 2021-06-21

これは何

3000文字Tipsイベントの参加記事です。

はじめに

本記事では、AWS SSO利用時にネックとなりやすい、ロール連鎖における1時間のセッション時間上限による使い勝手の悪さをマシにする方法についてご紹介します。

Webサービスプロバイダである弊社では複数のAWSアカウントを管理しており、IT運用部門と開発部門が協力してAWS SSOの導入を進めています。
image.png
運用概要は上記のようにしております。
AWS SSOの機能で、各AWSアカウントに一律でアクセス権限セットにより定義したロール(RoleA)がプロビジョンされます。
各AWSアカウントを管理する各チームが、実運用に必要なポリシーと、利用を許可するユーザーのprincipalを付与したロール(RoleB)を定義します。
これにより、実運用に必要なユーザーのみがRoleBのCredentialを得て活動できる、ということになります。

ただ、この運用ではCLI利用時に問題が起こります。
AWS SSOコンソールで発行されるCLI向け認可情報は、ロールベースの一時Credentialです。このCredentialを元にさらにAssume Roleで別のCredentialを発行しようとする場合、上で紹介したロール連鎖扱いになるため、指定できるdurationsecondsの上限は3600秒です。

最終的に利用するCredentialを発行するまでの流れとしては、

となります。
特に開発環境において、上記の流れをセッションが切れる度に行うのはあまりにも面倒だ、ということで、今回のやり方を考えました。

ソリューション

ざっくりと以下3つの段階で実現します。

  1. .aws/credentialにRoleAのCredentialを保存
    • このCredentialはセッション時間を12時間まで伸ばせる
  2. .aws/credentialに保存したRoleAのCredentialを呼び出してAssume Roleし、得た認証情報を.aws/credentialに保存

AWS SSOコンソールで発行される一時Credentialはロール連鎖扱いになっていないため、セッション時間を最大12時間まで延長できます。
このセッション時間はAWS SSO側の設定に依存します。

このソリューションのポイントとしては、手順1.を実施した後は最大12時間、RoleBのセッションが切れる度に「シェルを一つ実行するだけでよい」ことです。

.aws/credentialにRoleAのCredentialを保存

setSSOCredential.sh
setSSOCredential.sh
#!/bin/bash
aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID --profile SSOCredential
aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY --profile SSOCredential
aws configure set aws_session_token $AWS_SESSION_TOKEN --profile SSOCredential

echo "Finished to set SSO credential to env and .aws/credentials."
  • AWS SSOコンソールからRoleAのCredentialを入手し、ターミナルにペースト
  • bash setSSOCredential.sh を実行

aws configure setコマンドは、.aws/credentialファイルにCredentialを保存するコマンドです。
ここでは、RoleAのCredentialを保存するためのプロファイルを"SSOCredential"という名前に指定して、そこにCredentialを取っておきます。

.aws/credentialに保存したRoleAのCredentialを呼び出してAssume Roleし、得た認証情報を.aws/credentialに保存

setRoleCredential.sh
setRoleCredential.sh
#!/bin/bash
output=$(aws sts assume-role --role-arn arn:aws:iam::999999999999:role/RoleB --duration-seconds 3600 --role-session-name cold-wisteria@works-hi.com --profile SSOCredential)

export AWS_ACCESS_KEY_ID=$(echo $output | jq .Credentials.AccessKeyId -r)
export AWS_SECRET_ACCESS_KEY=$(echo $output | jq .Credentials.SecretAccessKey -r)
export AWS_SESSION_TOKEN=$(echo $output | jq .Credentials.SessionToken -r)

aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID --profile default
aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY --profile default
aws configure set aws_session_token $AWS_SESSION_TOKEN --profile default

echo "Finished to set role credential to env and .aws/credentials."

(assumerole対象のロールやrole-session-name、profileは適宜書き換えてください)

setSSOCredential.sh の実行後は、SSOCredentialのセッション時間中はsetRoleCredential.shを実行するたびにdefaultプロファイルに新しいCredential情報を書き込むことができます。
timeout 36000 watch -n 3500 bash setRoleCredential.sh みたいなコマンドで繰り返し処理にしておいてもいいかもしれません。

この状態になれば、後はdefaultプロファイルに保存されたCredentialを使ってAWS CLIでの作業を行うことが可能です。

最後に

本記事の執筆途中で、aws configure ssoコマンドの存在に気づきました。
が、こちらは以下の理由からそこまで使いやすくない/利用しづらいケースもあるかな、と思います。

  • AWS CLI v2が必要
  • 結構CLIの対話フローが長い
  • 結局CLIのフローの中で、一部ブラウザアクセスとブラウザ上での操作を要求される
  • 以下のように、対話の中で対象のAWSアカウントをCLI上で選択させられる
    SSOコンソールでなら検索が可能だが、CLIではキーボードの上下で選択するしかなく、多くのAWSアカウントがSSO対象になっていると選択が辛い

image.png

3
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?