coiai Logo
ホーム記事コラムPodcast会社情報
お問い合わせ
Featured

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の環境を構築していきます。


参考資料

  • AWS CLI – IAM Identity Center (SSO) の設定
  • IAM Identity Center ユーザーガイド
  • AWS CLI v2 ユーザーガイド
  • AWS STS GetCallerIdentity API リファレンス
  • AWS Well-Architected Framework – Security Pillar
投稿日: 2026年7月23日
カテゴリ: AWS
タグ:
coiai

coiai

この記事もおすすめ

デフォルトサムネイル

GMKtec EVO-X2にUbuntuを入れたら有線LANが認識されなかった話

オンプレミスAIサーバー(ローカルLLM + 社内文書RAG)の構築を始めました。機材はGMKtec EVO-X2、AMD Ryzen AI Max+ 395搭載のミニPCです。128GBのユニファイドメモリをGPUに大きく割り当てられるので、ローカルLLM用途では今いちばん面白いマシンだと思っています。 この記事は初日の作業ログです。結論から言うと「インストールUSBが起動しない」「有線LANが認識されない」という2つの罠を踏んだので、同じ構成を組む方のために記録しておきます。 OSはLinuxかWindowsか 最初に迷うのがここですが、サーバー用途ならUbuntu Server一択でした。 日常操作はすべてブラウザ(Open WebUI)経由なので、サーバーOSにGUIは不要です。管理画面が欲しければCockpitを入れれば、Webブラウザからメトリクス確認・サービス再起動・ターミナルまで使えます。「CUIのサーバー + Web管理画面」が現代の標準形だと思います。 BIOS設定 ― EVO-X2で一番大事なのはVRAM割り当て 電源ON直後にDel連打でBIOS(AMI)へ入ります。設定したのは3つです。 罠その1: インストールUSBが起動しない Ubuntu Server 24.04のISOをMacから dd でUSBメモリに書き込み、いざブート……しません。Boot Overrideに出てくる「UEFI OS」を選んでもWindowsが立ち上がってしまいます。 切り分けの過程が学びでした。 原因はおそらく、dd の書き込みが完全に終わる前に抜いてしまったことです。dd は進捗表示が止まってからもバッファの書き出しが続くので、完了統計が表示されるまで待たなければいけません。パーティションテーブルはディスク先頭に書かれるため、途中で切れていても一見正常に見えるのが厄介なところです。 教訓: インストールUSB作成はbalenaEtcherを使いましょう。 書き込み後に自動でベリファイ(照合)まで走るので、「書けたつもり」が原理的に起きません。Etcherで書き直したら一発で起動しました。 インストール時の選択 罠その2: 有線LANが認識されない インストール完了、ログイン成功。しかし ip a を見ると有線LANにIPがありません。それどころか、よく見ると有線のインターフェース自体が存在しません。 カーネルログを見て原因が確定しました。 EVO-X2の2.5GbEチップ(Realtek RTL8125D)が新しすぎて、Ubuntu 24.04の標準カーネル6.8のドライバが知らないチップだったのです。インストール中にネットに繋がらなかったのもこれが原因でした。ケーブルを何度挿し直しても無駄だったわけです。 教訓: 「繋がらない」時はケーブルを疑う前に dmesg を読みましょう。 カーネルログには大抵、答えがそのまま書いてあります。 解決: HWEカーネル 新しいチップに対応するには、新しいカーネルを入れれば解決します。Ubuntuには**HWE(Hardware […]

FSD v2.1 Feature-Sliced Design を導入する

FSD v2.1 Feature-Sliced Design を導入する

この記事は何? 公式のドキュメントやチュートリアル、exsample を読んで理解するのが一番いいですが、備忘録として残しておきます。特に後述の Skills, Steiger については開発する際にあった方が便利なので、それについても記事にします。 FSDとは? FSD (Feature-Sliced Design) はフロントエンドのアーキテクチャの一つです。 FSDとは責務で分けていくアーキテクチャと違い、ページやエンティティで分けていくアーキテクチャというとわかりやすいと思います。 コードの分離の仕方について話す前に、FSDで前提となる この3つについて理解する必要があります。 レイヤー より細かく分けていく方法がありますが、この記事では導入だけ触れたいので、3つのレイヤーのみ説明します。 です。この流れは上(app)に向かえば向かうほどアプリケーション固有、下(shared)に向かうほど汎用的になります。 原則として上位レイヤーは下位レイヤーを利用できるが、下位レイヤーから上位レイヤーへ依存できません。 始め方としては小さく初めて、必要になったらレイヤーを増やしてくようです。 スライス ブログアプリであればレイヤーの pages には といったページに分けられるため、このような構成になります。このblog-list, blog-detail, user がスライスです。これらはページやエンティティによって分けられます。 セグメント これらのmodel, ui といった部分がエンティティです。これらは責務にあたります。sharedに関しては直下にスライスではなくセグメントが入ります。 FSD 2.1 で重要なのは Pages First です。とにかくPagesから作って、細分化の必要ができたら、下位レイヤーに抽出します。 Steiger Steiger とはアーキテクチャリンターです。以下でインストールできます。 AIコーディングのために Claude Skills https://github.com/feature-sliced/skills?utm_source=chatgpt.com このリポジトリが公式に公開されています。 これで Skills を追加できるので、claude にFSDの設計知識を共有できます。

フロントエンドのアーキテクチャについて最初から考える

フロントエンドのアーキテクチャについて最初から考える

これは何? この記事は基本に立ち戻りアーキテクチャの選定を試みた際の備忘録です。Feature-Sliced Design(FSD)や Vertical Slice Architecture など、モダンなアーキテクチャがありますが、どのような判断をもとに選定するのかを考え直します。 アーキテクチャの地図 アーキテクチャを理解するために、以下のような学習のための地図を作りました。設計原則、アーキテクチャ、個別の設計パターンへと詳細になっていきます。 そもそも、、、 このコードは何を担当しているのかを考えるのが最初の問です。 商品一覧画面を作るときに といったタスクを書き出します。 これら全てを一つの巨大なコンポーネントとして作ることもできますが、管理が大変になるのは皆さんもお分かりだと思います。参考:https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html?utm_source=chatgpt.com ここからどこまでを同じモジュールとして管理するのか?という設計の問題が始まります。 Cohesion と Coupling CohesionとCouplingはそれぞれ、凝集度、結合度というようです。https://qiita.com/dsudo/items/ee3fee1f558c7f1b359f Cohesionは関係するコードがまとまっているか? Couplingは別のコードにどれだけ依存しているか? です。 例えば以下のようなコードがあります。 技術的な種類ごとに整理されていますが、商品一覧のコーディングをするのにそれぞれ別のディレクトリを行き来する必要があります。一方で、以下のように書いた場合はどうでしょうか? この書き方なら、商品に依存するコードがまとまっています。 この書き方が Feature-based Architecture, Vertical Slice Architecture に繋がっていきます。 コロケーションについて colocation Place code as close to where it’s relevant as possible 同じ種類のコードを集めることではなく、一緒に変更されるコードを近くに置くことです。 https://kentcdodds.com/blog/colocation?utm_source=chatgpt.com Layered Architecture について ここからアーキテクチャの話です。 Layered Architectureでは、技術的責務でアプリケーションを分離します。 これのメリットは責務がわかりやすいところです。 しかし、この方法では前述までとは変わり、機能を変更するときに、横断して変更する可能性があります。 つまり、技術的には分かれている一方で、機能は複数に分散するわけです。 […]

デフォルトサムネイル

【WSL入門】Ubuntu on WSL2 に開発ツールを一式そろえる — Git / nvm / pnpm / AWS CLI / Terraform

前回の記事では、Windows に WSL2 を導入して Ubuntu が動くところまでを扱いました。ただ、素の Ubuntu はあくまで「まっさらな Linux」です。ここから実際に開発を始めるには、バージョン管理・ランタイム・クラウド操作のツールを自分で入れていく必要があります。 この記事では、すべて公式ドキュメントに載っている手順だけを使って、次のツールを順番にセットアップします。 各セクションの末尾に出典 URL を置いてあるので、手順が古くなったと感じたらそこを見に行ってください。記事末尾には出典一覧もまとめています。 検証環境Windows 11 / WSL2 / Ubuntu 24.04 LTS(x86_64)確認日:2026年7月28日 バージョン番号は執筆時点のものです。インストールコマンド自体は基本的に「常に最新を取ってくる」形になっているので、そのまま実行して問題ありません。 はじめに:WSL開発の大原則 コマンドに入る前に、ひとつだけ。Microsoft の公式ドキュメントが繰り返し書いている重要な原則があります。 使う予定のツールと同じ OS 側にファイルを置く。Linux ツールで Linux コマンドラインから作業しているなら、最速のパフォーマンスを出すためにファイルは WSL ファイルシステムに格納します。 具体的には、プロジェクトは次の場所に置きます。 /mnt/c/ 配下はファイルシステムをまたぐため、npm install や git status が体感でわかるほど遅くなります。第2弾でこれから入れるツールも、すべて Linux 側のホームディレクトリを前提に使ってください。 出典:WSL 開発環境を設定する — Microsoft Learn 1. まずは基本ツール Ubuntu を起動したら、最初にやることはパッケージの更新です。Microsoft の公式ドキュメントにもこう書かれています。 ディストリビューションの優先パッケージ マネージャーを使用して、パッケージを定期的に更新およびアップグレードすることをお勧めします。Windows […]

この記事を書いた会社

株式会社coiaiは、「想像できることを美しく実現」を掲げ、XR・Web・アプリ・システム開発およびDX支援を行う会社です。 創業2022年、東京都練馬区に本社を置き、要件のヒアリングからPoC(概念実証)、本番運用まで一貫して伴走します。 まずはお気軽にご相談ください。

商号株式会社 coiai創業2022年1月設立2025年1月23日資本金1,500,000円(設立時点)本社所在地東京都練馬区関町北 3-6-9代表者代表取締役 竹村 啓佑 / 代表取締役 服部 陽良

主なご相談内容

  • Webサイト・Webアプリの設計・開発
  • スマートフォンアプリ(iOS / Android)の開発
  • XR・AR・VRを活用した体験設計・開発
  • DX推進・業務システムの企画・開発
  • PoC(概念実証)から本番運用までの伴走支援
  • マーケティング・コンサルティング
会社概要・役員紹介を見る

詳しい会社情報は会社概要ページでご覧いただけます。

資料請求・無料相談

導入要件のヒアリングからPoC、本番運用まで伴走します。まずはお気軽にご相談ください。

フォームで問い合わせメールで相談

お問い合わせの前に 個人情報保護方針 をご確認ください。

株式会社coiai株式会社coiai

XR, Web, システム開発, DX — 想像できることを美しく実現

メールでお問い合わせ

サービス

on-premise AI

基幹システム Anchor

XR開発

会社情報

会社概要

ブログ

お問い合わせ

法務

プライバシーポリシー


所在地

〒177-0051 東京都練馬区関町北3-6-9

営業時間

平日 10:00-18:00

土日祝 休み

info@coiai.net

© 2023–2026 株式会社coiai. All rights reserved.