AWS CLIでIAM Identity Center（AWS SSO）を設定する

これまでの記事で、

AWS Organizations
IAM Identity Center
Permission Set

まで構築しました。

今回は、ローカルPCからAWSを操作するために、AWS CLIをIAM Identity Center（AWS SSO）へ接続します。

これにより、長期アクセスキーを発行せず、安全にAWS CLIやTerraformを利用できるようになります。

なぜアクセスキーを使わないのか

以前はAWS CLIを利用する際、IAM Userを作成し、

Access Key ID
Secret Access Key

を発行していました。

IAM User
    ├── Access Key ID
    └── Secret Access Key

しかし、この方法にはいくつかの課題があります。

アクセスキーの漏洩リスク
定期的なローテーションが必要
GitHub Secretsへ保存する必要がある
退職時の管理が煩雑

現在AWSでは、人によるAWSへのアクセスには**IAM Identity Center（旧AWS SSO）**を利用することが推奨されています。

参考

AWS CLI と IAM Identity Center の設定ガイド

IAM Identity Center ユーザーガイド

IAM Identity CenterとAWS CLIの仕組み

AWS CLIは、IAM Identity Centerへログインし、一時的な認証情報（Temporary Credentials）を取得します。

Developer PC
      │
aws configure sso
      │
      ▼
IAM Identity Center
      │
      ▼
AdministratorAccess
      │
      ▼
Dev Account

つまり、

パスワードを保存しない
Access Keyを保存しない
必要なときだけ一時認証情報を取得する

という、安全性の高い認証方式になります。

aws configure sso を実行

まずAWS CLI v2をインストールします。

インストール後、次のコマンドを実行します。

aws configure sso

すると、対話形式で設定が始まります。

SSO Session Name

SSO session name (Recommended):

ここはローカルPC上だけで利用する設定名です。

今回は

coiai

としました。

好きな名前で問題ありません。

SSO Start URL

SSO start URL

IAM Identity CenterのアクセスポータルURLを入力します。

例

https://d-xxxxxxxx.awsapps.com/start

このURLは

IAM Identity Center
→ Settings

から確認できます。

SSO Region

SSO region

IAM Identity Centerを有効化したリージョンを指定します。

今回は東京リージョンなので

ap-northeast-1

を指定しました。

Registration Scope

SSO registration scopes

デフォルトの

sso:account:access

をそのまま利用します。

通常は変更する必要はありません。

ブラウザ認証

途中でブラウザが自動的に起動し、

IAM Identity Centerへログインします。

認証が成功すると、

AWS CLIが利用可能なAWSアカウントを取得します。

今回は

The only AWS account available to you is:
120896952796

となりました。

さらに

AdministratorAccess

が利用可能なPermission Setとして表示されました。

リージョンと出力形式

続いて

Default client Region

では

ap-northeast-1

を指定しました。

また

CLI default output format

では

json

を選択しています。

JSONはTerraformやスクリプトとの相性が良いため、おすすめです。

Profile Name

最後に

CLI profile name

を設定します。

今回は

coiai-dev

という名前にしました。

この名前でAWS CLIが利用できます。

接続確認

最後に

aws sts get-caller-identity --profile coiai-dev

を実行しました。

結果は次の通りです。

{
  "UserId": "AROAXXXXXXXXX:Hattori",
  "Account": "120896952796",
  "Arn": "arn:aws:sts::120896952796:assumed-role/AWSReservedSSO_AdministratorAccess_xxxxxxxxx/Hattori"
}

ここで重要なのは

assumed-role/AWSReservedSSO_AdministratorAccess

という部分です。

これは、IAM Userではなく、IAM Identity CenterのPermission Setから発行されたIAMロールを引き受けて認証されていることを意味します。

つまり、長期アクセスキーを一切利用せずにAWS CLIへログインできています。

Terraformでもそのまま利用できる

Terraformでは、このプロファイルを指定するだけで利用できます。

provider "aws" {
  profile = "coiai-dev"
  region  = "ap-northeast-1"
}

CLIとTerraformが同じ認証情報を利用するため、アクセスキーをコードへ記述する必要がありません。

今後の構成

ここまでで、人によるAWSアクセスの認証基盤が完成しました。

今後は

Developer
     │
IAM Identity Center
     │
AWS CLI
     │
Terraform
     │
Dev Account

という流れでインフラをコード管理していきます。

その後はGitHub ActionsとOIDCを連携し、人だけでなくCI/CDも安全に認証できる環境を構築する予定です。

まとめ

IAM Identity CenterとAWS CLIを連携することで、

Access Keyを発行しない
一時認証情報を利用する
Terraformとも安全に連携できる
AWSが推奨する認証方式を採用できる

という構成を実現できました。

AWS Organizations、IAM Identity Center、AWS CLIの3つが揃ったことで、今後はTerraformを中心としたInfrastructure as Codeの環境を構築していきます。

参考資料

この記事をシェア

投稿日: 2026年7月23日

カテゴリ: AWS

タグ:

coiai

この記事もおすすめ

AWS IAM Identity Centerとは？IAM Userを使わないAWS認証・権限管理のベストプラクティス

AWS Organizationsによるマルチアカウント環境を構築した後、次に設定したのがAWS IAM Identity Centerです。以前はAWSへログインするためにIAM Userを作成することが一般的でしたが、現在AWSでは、人がAWSへログインする場合はIAM Identity Centerの利用を推奨しています。今回は、IAM Identity Centerを導入した理由と、実際の設定内容についてまとめます。 IAM Identity Centerとは IAM Identity Center（旧 AWS Single Sign-On）は、複数のAWSアカウントやAWSアプリケーションへの認証・認可を一元管理するサービスです。従来のように各AWSアカウントへIAM Userを作成する必要はなく、というメリットがあります。 AWS Organizationsと組み合わせることで、マルチアカウント環境の運用が大幅に容易になります。なぜIAM UserではなくIdentity Centerなのか以前は、このような構成が一般的でした。しかし、この方法ではといった課題があります。 Identity Centerを利用すると、ユーザー情報は一元管理され、各AWSアカウントには必要な権限だけを割り当てる運用になります。 AWS Well-Architected Frameworkでも、人によるアクセスにはフェデレーション認証を利用し、長期認証情報（IAM Userのアクセスキーなど）をできる限り利用しないことが推奨されています。今回の構成今回は次のようなシンプルな構成にしました。グループ Administrators AWS環境全体を管理するメンバーです。現在はを所属させる予定です。 Developers アプリケーションやインフラ開発を行うメンバー向けです。今回はまだ利用していませんが、開発メンバーが増えた際に使用します。将来的にはなどを割り当てる予定です。 ReadOnly 閲覧専用グループです。監査やレビュー、外部アドバイザー向けとして利用します。今回は技術メンターにReadOnly権限を付与することを想定しています。 Permission […]

AWS Organizationsで始めるマルチアカウント設計 ― 小規模開発チーム向けのベストプラクティス

サービスの開発を進めるにあたり、AWSの初期構築を行いました。今回は、AWS Organizationsを利用してマルチアカウント環境を構築し、今後TerraformによるIaC（Infrastructure as Code）やGitHub Actionsを利用したCI/CDを前提とした設計を採用しています。この記事では、実際に構築した構成と、その設計意図をまとめます。なぜ最初にAWS Organizationsを導入するのか AWSでは1つのアカウントにすべてのリソースを作成することもできます。しかし、開発が進むにつれて次のような問題が発生します。 AWSではこのような課題に対応するため、マルチアカウント構成を推奨しています。AWS Organizations ユーザーガイド Organizationsとは AWS Organizationsは、複数のAWSアカウントをまとめて管理するためのサービスです。 OrganizationsにはOU（Organizational Unit）という概念があります。 OUはEC2やS3を配置する場所ではなく、AWSアカウントを整理するためのフォルダのような存在です。例えば、というようにOUを作成し、その中へAWSアカウントを配置していきます。 OUを利用することで、将来的にSCP（Service Control Policies）などのポリシーをまとめて適用できるようになります。AWS Organizations のベストプラクティス今回採用した構成今回はAWS Security Reference Architecture（AWS SRA）の考え方を参考にしつつ、小〜中規模の開発チーム向けにシンプルな構成を採用しました。AWS Security Reference Architecture (AWS SRA) Infrastructure OU インフラ運用に必要なAWSアカウントを配置します。 Log CloudTrailをはじめとする監査ログを集約するためのアカウントです。 AWSではCloudTrailのイベント履歴は標準で90日間参照できますが、長期間保持する場合はS3へ保存する構成が推奨されています。さらに、一定期間経過後はS3 Glacierへ移行することで保管コストを抑えることができます。今後はCloudTrailだけでなく、各種監査ログもこのアカウントへ集約する予定です。 Security Security HubやGuardDuty、AWS Configなどのセキュリティサービスを配置するためのアカウントです。今回はまだ構築していませんが、を集約する予定です。 AWS SRAでも、ログ管理アカウントとセキュリティアカウントを分離する構成が推奨されています。 […]

.env ファイルをやめて Bitwarden Secrets Manager に移行した話

この記事はなに？私たちcoiaiはモックアップの作成業務がメインで今までの開発は１－２名程度でした。しかし、６名以上で開発を進めていく案件が増えてきたため、開発環境を見直す必要に迫られました。今まで環境変数は .env ファイルで管理していました。しかしこれからは、平文として秘密情報が確認できない状態にすること、チームで環境変数の共有の際にセキュアな共有方法を確保することを目的とし、環境整備を行いました。 Bitwarden 導入の目的と意義背景: .env の何が問題かローカル開発の秘密情報は .env + .gitignore が定番だが、いくつか弱点がある。 1 と 2 を解決するのがシークレット管理サービスで、Bitwarden Secrets Manager はその中でも安価(Password Manager とは別契約)かつ CLI が単体バイナリで導入が軽い。 Bitwarden Secrets Manager で抑えて起きたい概念注意点としてPassword Manager(個人のパスワード保管)とは別プロダクトです！Password Manager は弊社でも利用していますが、今回Secret Manager を追加で契約した形になります。概念は3つだけです。概念役割プロジェクトシークレットの入れ物。今回は 1 リポジトリ = 1 プロジェクトシークレット KEY / VALUE / メモの3つ組。.env の 1 […]

Claude Code Fable 5 を /model から選択できない

これは何？ Terminalから操作を行う Claude Code から、をすると Fable 5 が選択肢に出てこない。という問題の対処法についてです。実際にclaude code を起動して /model を打つと Opus, Sonnet, Haiku の３つの選択肢しか出ていないのが確認できます。環境対処法直接モデルの選択を実行してください。 Terminalにこのように Set model to claude-fable-5 and saved as your default for new sessions と表示されていれば成功です。参考