アクセスキーを使ったaws-cliはもうやめよう！

はじめに

アクセスキー発行するのって非推奨なの？

普段、CLI操作はCloudShellや、Cloud9上で行うようにしているのですが（環境構築
したくない。）、デスクトップ上で操作したい時があります。

そこで、一番簡単な方法であるアクセスキーを発行しようとすると、こんな代替案を提案されます。

この警告にモヤモヤしていたので、今回は「IAM Identity Center」を使ってみた。っていう記事です。

実は、アクセスキーは丸見えだったり。

最近、職場の本番リリース中に気づいたのですが、AWS CLIに保存したアクセスキーや、シークレットアクセスキーは丸見えだったりします。
(↓は既に削除しているキーたちです。)

アクセスキーの何がいけないのか？

おおむね以下の理由から、非推奨の模様。

1. 永続的な認証情報だから。
   1. キーが流出すると、攻撃者がリソースにアクセスし放題。
2. キーの管理が面倒。
   1. 複数IDを発行して使い分け等をし始めると、キーを管理する必要が出てくる。
3. キーをチームで共有したりすると、問題発生時に誰が実施したか追えなくなる。
4. アプリケーションに組み込んだりすると、流出等のセキュリティ上の脆弱性になる。
   1. で、誰でも見れるGit等で公開してしまう。
5. 無効化/削除時にシステムに影響でちゃう。

こういった面倒ごとを無くすためにも、必要最低限の権限を、都度、一時的な形で付与するとったことが大切なんだろうな、理解しています。

IAM Identity Centerを早速設定してみよう！

IAM Identity Centerって？

私も全体を知らないので、AIに概要を箇条書きさせてみました！

・以前はAWS Single Sign-On（SSO）として知られていた
・複数のAWSアカウントとアプリケーションへのアクセスを一元管理

主な特徴：

・シングルサインオン（SSO）機能を提供
・ユーザーとグループの中央管理
・多要素認証（MFA）のサポート
・きめ細かなアクセス制御
・クラウドアプリケーションとの統合

メリット：

・セキュリティの向上
・管理の簡素化
・ユーザー体験の改善
・コンプライアンス要件への対応を支援

・・・なるほど、雰囲気だけはわかった！

Organizetionsの設定や、ルートアカウントの設定は必要なのか？

IAM Identity Centerを設定している記事を見させていただくと、
Organizetionsの設定やルートアカウントで実施する必要があるといった記事を見かけましたので、少し試してみました。

実際に、IAM Identity Centerをルートアカウント、IAMアカウントで試してみましたが、以下のような結果でした。

ルートアカウント

だめ？

IAMユーザ

こっちは、こんな選択肢が出た。

今回はIAMユーザをOrganizetionsを有効にして対応しています。

IAM Identity Centerを早速設定。

したことの概要は、以下。

1. MFA認証の有効化
2. グループ、ユーザの作成
3. 権限セットの作成
4. IAMアカウントとIAM Identity Centerのユーザまたはグループの紐付け

MFA認証の有効化

左メニュー「設定」から遷移する画面の、「認証」のところから、MFAの設定ができます。
これは必要に応じて、、ですね。

グループ、ユーザの作成

IAM側のグループ・ユーザと違って、この時点では権限等はなし。

権限セットの作成

許可セットもロールと似ていて、事前定義されたマネージドのものを利用するか、自身で細かく作ることも可能。

今回はマネージドな、AdministerAccessを使います。

IAMアカウントとIAM Identity Centerのユーザまたはグループの紐付け

ここが大切なところだと思うのですが、
既存のOrganizetion上のIAMアカウントに対し、どのグループ、またはどのユーザをどの権限セットで付与するかというところを設定する模様。

このサイトのご説明がとても分かりやすいのですが、動き的にはスイッチロールをするための設定をしているみたい。

実際に対象のIAMアカウントにログインし、ロールを見てみると、AWSReservedSSO_AdministratorAccess_316b483c70a4dc98みたいなロールができてました。

ユーザ側の設定。

あとは、ユーザのメアドに招待メールが届くので、案内の通りに必要な設定をすれば、AWS access portalが表示され、紐付けした通りのアカウント、権限でマネコンにログインできます！

スクリーンショット 2024-09-26 5.12.14

最後にCLI側の設定

CLIの設定は、このサイトの通り。
aws configure ssoで、初期設定するだけ。

$ aws configure sso
SSO session name (Recommended): [任意な名前]<ENTER>
SSO start URL [None]: [招待メールやAWS access portalで確認できるstart URL]<ENTER>
SSO region [None]: ap-northeast-1<ENTER>
SSO registration scopes [None]: sso:account:access(固定)<ENTER>

ここまで入れたタイミングで、ブラウザにリダイレクトしログイン操作を行うことで、認証キーが自動入力されます。

CLI default client Region [None]: ap-northeast-1<ENTER>
CLI default output format [None]: json<ENTER>
CLI profile name [123456789011_ReadOnly]: [任意の名前]<ENTER>

profile名は長いと都度--profileで入力するのが面倒なんで、シンプルな名前がいいかも。
あるいは、環境変数でデフォルト指定しておくのも良いかも。
（業務では誤操作の可能性が出てくるのでやめておいたほうがいいかも。）

$export AWS_PROFILE=your-sso-profile-name

ログアウト

以下コマンド

$aws sso logout

初回以降のログイン

$aws sso login --profile xxx

まとめ

これで都度の認証情報でCLIを扱うことができるようになりました！

CloudShellを基本的には使いつつ、IAM Identity Centerを使ったCLIを使えば安全なのかなと思います！

初の技術系記事で、出来が悪いと思いますが、最後まで読んでいただきありがとうございました！！