はじめに

ローカル端末にて実施していたServerless FrameworkによるLambda環境のdeployを、GitHubActionsに移行したけど、AssumeRoleの処理で詰まったので備忘録です。

ローカルでのデプロイ方法

複数のAWSアカウントを持ってるので、以下を参考にIAMユーザーには権限を持たせず、AssumeRoleを利用して各AWS環境のRoleにスイッチロールしてアクセスをしてます。

その為、デプロイする時は対象のAWSアカウント用のProfileを指定してデプロイを実行しています。

$ AWS_PROFILE=aws-test sls deploy --verbose

~/.aws/credentials

 [default]
aws_access_key_id = ****************
aws_secret_access_key = *****************************************
[aws-test]
role_arn = arn:aws:iam::<AcountID>:role/assume-role
source_profile = default

AssumeRoleの実行方法

AWSのブログ「GitHub Actions と AWS CodeBuild テストを使用して Amazon ECS の CI/CD パイプラインを作成する」にも紹介されている、以下の公式のActionを利用してAsume Roleを実行します。

GitHub Actionsの設定

READMEの記載を参考に以下を定義します。
AssumeRoleのARNもsecretsから取得するようにしてます。

- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ap-northeast-1
    role-to-assume: ${{ secrets.AWS_ASSUME_ROLE_ARN }}
    role-duration-seconds: 1200

secretsには~/.aws/credentialsと同じ値を設定します。

workflowの全文はこちら

GitHub Actionsの実行

そのまま実行するとConfigure AWS Credentialsのステップにて以下のエラーで失敗します。

##[error]User: arn:aws:iam::<AcountID>:user/<IAM User Name> is not authorized to perform: sts:TagSession on resource: ***
##[error]Node run failed with exit code 1

原因

Actionの処理を確認すると以下の様にAssumeRoleする際にセッションタグを渡していました。
（普段使ってないのでセッションタグの存在を初めて知りました。）

セッションタグについては以下を参照
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_session-tags.html

対応

セッションタグの説明のセッションタグの追加に必要なアクセス許可に記載の通り、接続先のロールの信頼ポリシーにセッションタグへのアクセスを許可する必要があります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<AcountID>:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"  #　"sts:TagSession"をActionに追加する
      ],
      "Condition": {}
    }
  ]
}

ロールを作成する時に、コンソールから「信頼されたエンティティの種類」で「別のAWSアカウント」を指定して作成すると、sts:AssumeRoleしか許可しない為、一旦作成後に信頼ポリシーを編集して追加する必要があります。

接続元のアカウントではなく、接続先のアカウントのロールに設定が必要なので注意です。
(接続元のアカウント側で対応してて、小一時間ハマってしまいました・・・)