EB CLIをIAM Identity Centerで実行する

EB CLIの環境をIAM Identity Centerでの実行にリプレイスした時の記録です。

前提条件

• IAM Identity Centerで権限が付与された状態
• EB CLIのインストールが完了している状態
• IAMとIAM Identity Center両方使用するので両方とも使用経験がある方が理解しやすいと思います

EB CLIに必要な権限を確認

EB CLIを実行するためには大きく分けて2つの権限が必要になります。以下IAMでの権限とIAM Identity Centerでの権限が出てきますのでご注意ください。

• EB CLIを実行するための権限｜IAMとIAM Identity Center
• Elastic Beanstalkが他のAWSリソースであるEC2やALB、CloudWatchなどを操作するためのロール｜IAM

具体的には以下の権限が必要になります。

EB CLIを実行するための権限｜IAMとIAM Identity Center

EB CLIを実行するユーザーには、Elastic Beanstalk環境を作成・更新・削除するための権限が必要です。

IAM Identity Centerを利用する場合は、これらの権限をIAM Identity Centerの許可セットに設定します。許可セットには、AWS管理ポリシー、カスタマー管理ポリシー、インラインポリシーなどを設定できます。

許可セットを対象のAWSアカウントとユーザー、またはグループに割り当てることで、IAM Identity Center経由でEB CLIを実行できるようになります。

AWS管理ポリシーとしては、たとえば以下を利用できます。

• AdministratorAccess-AWSElasticBeanstalk

このポリシーは、IAMのコンソールから確認できるものです。
Elastic Beanstalkアプリケーション、環境、および関連する基盤リソースを管理するための権限を付与します。

ただし、このポリシーは最小権限のポリシーではありません。環境や運用方針に応じて、必要であればカスタムポリシーで権限を絞ってください。

IAM Identity Centerの許可セットにポリシーをアタッチ

IAM Identity Centerの許可セットに、EB CLIを実行するための権限を付与するポリシーとして以下のポリシーをアタッチします。

• AdministratorAccess-AWSElasticBeanstalk

IAM Identity Centerを使ったことがない方は以下のように設定してみてください。

Elastic Beanstalk環境が使用するロール｜IAM

Elastic Beanstalkは、環境作成時にEC2、ALB、Auto Scaling、CloudWatchなどのAWSリソースを操作します。

そのため、主に以下のロール、ポリシー、またはインスタンスプロファイルが必要になります。

• Elastic Beanstalkのサービスロール
• EC2インスタンスプロファイル用のロール

既存環境では、以下のような名前のロールが使われていることがあります。

• aws-elasticbeanstalk-service-role
• aws-elasticbeanstalk-ec2-role

ただし、現在は aws-elasticbeanstalk-ec2-role が必ず自動作成されるわけではありません。

以前は、Elastic Beanstalkが初回環境作成時に aws-elasticbeanstalk-ec2-role というデフォルトのEC2インスタンスプロファイルを作成していました。しかし、現在はAWSのセキュリティガイドラインにより、Elastic Beanstalkはこのデフォルトロールを自動作成しません。

そのため、新規アカウントや新規環境でエラーが出る場合は、IAMコンソールでElastic Beanstalk用のサービスロールやEC2インスタンスプロファイルが存在するか確認してください。

使用されているポリシー

Elastic Beanstalk Compute用のロールを作成する場合、通常以下のAWS管理ポリシーがアタッチされます。

• AWSElasticBeanstalkEnhancedHealth
• AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy
• AWSElasticBeanstalkWebTier
• AWSElasticBeanstalkWorkerTier
• AWSElasticBeanstalkMulticontainerDocker

ただし、Worker環境やECS managed Docker環境を使わない場合は、用途に応じて一部のポリシーを含めない構成も可能です。

ローカルPCでの設定と実行手順

初期設定（初回のみ）と実際にebコマンドを実行するまでを整理してみます。

1. aws configure sso --profile test-beans-prod
   ※test-beans-prodは任意の値です。
2. すると以下の項目について対話形式で入力を求められます。
   SSO session name（任意の値）: prod-sso
   SSO start URL: https://xxxxxxxx.awsapps.com/start
   SSO region: ap-northeast-1 など
   SSO registration scopes [sso:account:access]:そのままエンター
   ここでURLが表示されブラウザが起動するのでログインします。
   最後に「アクセスを許可」をクリックします。
   ブラウザでRequest approvedと表示されたらターミナルに戻ります。
   Default client Region [None]: ap-northeast-1 など
   AWS account: 対象アカウント
   Permission set / role: 対象の許可セット
   Default output format（任意の値）: json
   ※任意の値以外は事前に設定してあるIdentity Centerの値を入力します。
   ※SSO start URLはIPv4とデュアルスタックURLのどちらかを設定します。このURLはIAM Identity Centerのコンソールから確認できます。
3. これで設定は完了です。ここで設定した内容はローカルPCの~/.aws/configに書き込まれます。
   今回設定した内容はおそらく以下のようになっています。
   変更したい際はこのファイルを編集しても良いですし、sso-sessionとprofileのセクションを削除した後、また対話形式で設定することも可能です。

[sso-session prod-sso]
sso_start_url = https://xxxxxxxx.awsapps.com/start
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

[profile test-beans-prod]
sso_session = prod-sso
sso_account_id = 123456789012
sso_role_name = test-beans-cli
region = ap-northeast-1
output = json

sso login

実際に設定したユーザーでsso loginを実行してみます。

1. ローカルPCのeb initしてあるディレクトリに移動します。
2. aws sso login --profile test-beans-prodを実行します。
3. ブラウザが起動するのでログインします。
4. ログインが成功するとブラウザに「リクエストが承認されました」と表示されるのでターミナルに戻ります。
5. ターミナルでもSuccessfully logged into Start URL〜と表示されていればCLIのセッションでもログインが完了しています。試しに以下のコマンドを実行してみます。

$ eb list --all --profile test-beans-prod

既存のBeanstalk上の環境がある場合、上記コマンドで環境が表示されれば設定は完了です。環境がない場合はeb createなどで環境を作成するなどして確認してみてください。

遭遇したエラー

以下遭遇したエラーの解説をします。

古いprofileがプロジェクトに残っていた

既存の環境の場合、以下のようにエラーが出ることもあります。

ERROR: InvalidProfileError - The config profile (eb-pro-before) could not be found

これは実行したディレクトリの元のプロジェクトのプロファイルeb-pro-beforeが見つからないというものです。既存の設定ファイルに設定が残っているので以下の部分を修正してください。

.elasticbeanstalk/config.yml

global:
- profile: eb-pro-before
+ profile: test-beans-prod

権限の不足

私の環境では、eb create 実行時に以下のエラーが出ました。

ERROR: NotAuthorizedError - Operation Denied. User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSReservedSSO_xxxxxxxxxxxxx is not authorized to perform: s3:ListBucketMultipartUploads on resource: "arn:aws:s3:::elasticbeanstalk-ap-northeast-1-xxxxxxxxxxxx" because no identity-based policy allows the s3:ListBucketMultipartUploads action

エラーの主体が AWSReservedSSO_... になっているため、Elastic BeanstalkのサービスロールやEC2インスタンスプロファイルではなく、IAM Identity Centerの許可セット側の権限不足です。

AdministratorAccess-AWSElasticBeanstalk だけでは s3:ListBucketMultipartUploads が不足する場合があるため、私の環境では以下をインラインポリシーとして、EB CLI用の許可セットに追加しました。（IAM Identity Centerコンソールの許可セットから設定）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowElasticBeanstalkListBucketMultipartUploads",
      "Effect": "Allow",
      "Action": "s3:ListBucketMultipartUploads",
      "Resource": "arn:aws:s3:::elasticbeanstalk-ap-northeast-1-123456789012"
    }
  ]
}

123456789012 の部分は、使用しているAWSアカウントIDに置き換えてください。

この権限はバケットに対する権限なので、Resourceには末尾に /* を付けないバケットARNを指定します。

今回のようにEB CLI用許可セットへ小さな不足権限を追加するだけであれば、インラインポリシーで十分です。複数の許可セットや複数アカウントで同じポリシーを使い回す場合は、カスタマー管理ポリシーとして管理することも検討できます。

コンソールログイン用の許可セットもある場合

今回EB CLI用に許可セットを設定しました。ただ人間がログインする用の許可セット、広くAWS CLIを利用する許可セットも多くの場合あると思います。その場合はPowerUserAccessという許可セットを今回と同じユーザーに設定することでxxxxxxxx.awsapps.com/startからブラウザでアクセスして実行することができます。このように一つのユーザーにEBCLI用、コンソールログイン用という形で2つの許可セットを付与することで権限を絞った運用＆操作した人間に紐づく運用が可能となります。