概要
今年出くわして意外に思ったことを紹介します。
- 面白いリージョン構成ですね：Amazon Q Developer
- そっちが優先なんですか：AWS CLI の認証情報
- ユーザにその権限必要なんですね：AWS IAM MFA ディバイス設定
- CSVというフォーマットとは、問題：AWS IAM初期生成パスワード
の4本でお送りします。
Amazon Q Developer(AWS Chatbot) 設定に普段使わないリージョン許可が必要だった
一時的にインフラ構築を担当する方の IAM Policy には aws:RequestedRegion で以下のリージョンのみの操作を許可するようにしていました。
-
us-east-1※グローバルサービス用途 -
ap-northeast-1
※他リージョンもリクエストがあれば検討の上追加
ある日、「社内のメッセージサービスに通知を送るために AWS Chatbot を設定したいがエラーになる」というお問い合わせが来ました。
調べてみると公式ドキュメントに提供リージョンが記載されており
以下いずれかのリージョンの許可が必要でした
US East (Ohio) - us-east-2
US West (Oregon) - us-west-2
Asia Pacific (Singapore) - ap-southeast-1
Europe (Ireland) - eu-west-1
また、コンソールからの利用は Ohio (us-east-2) のみとあるので
The Amazon Q Developer in chat applications console can only be used in US East (Ohio). Your configuration data however, is stored in each of the relevant available Regions.
これと揃えて us-east-2 を許可することにしました。
AWS CLI が認証情報をどの優先順位で読み込んでいるのか
のような話になります。
アドベントカレンダーの4日目
に書いた AWS Organizations への移行を検討している環境は Jump アカウントに IAM ユーザでログインしてメンバーアカウントに Switch Role する形式のユーザ管理をしています。
AWS CLI の利用は Long-term credentials を使っており、ここを何とかしたいという課題感がありました。AWS Organizations への移管検討中な状態で中期では全社の IdP + Identity Center を使う予定があります。AWS + 外部 IdP によるユーザ管理自体は Auth0 での対応経験があったので、導入や運用、切り替えのコスト感を鑑みてなかなか手を打てない状態でした。
そこへ aws login コマンドがリリースされました。
ブラウザでの認証を元に一時トークンが払い出される仕組みです。
コマンドを実行すると ~/.aws/config のプロファイルの項目に
login_session = ${IAM_ISER_ARN}
の項目が追加されます。
AWS 公式ドキュメントを参照すると
AWS CLI がこの認証情報を参照する優先順位は
- 設定ファイル
と大分後ろの方(ドキュメントにある優先順位は10までです)でした。
これ以前は
- コマンドラインオプション
- 環境変数
- ロールの継承
- ウェブ ID によるロールの継承
- AWS IAM Identity Center
- 認証情報ファイル
- カスタムプロセス
となります。
Long-term credentials は ~/.aws/credentials に設定されているため「6. 認証情報ファイル」になります。
つまり
aws login で認証を取得していても Long-term credentials の方が優先される
ということになります。
私の感覚的には現状 aws sso login が先行して存在してログイン統合されていないので、「5. AWS IAM Identity Center」よりは後ろかなと思っていたのですが、「6. 認証情報ファイル」よりは前だと思っていたので引っかかりました。
元々 Long-term credentials は廃止していきたかったので ~/.aws/credentials の設定を削除して作業をしています。
AWS IAM User が自分で MFA ディバイスを設定できる IAM ポリシーの権限
これは2022年末からの仕様で、私が今年気付いた話ですが。
MFA ディバイスを自身で設定できる IAM ポリシーは
なのですが、この中に iam:ListMFADevices, iam:ListVirtualMFADevices があります。
少し考えれば MFA ディバイスの名称がアカウント内で一意になる必要があるので、名前入力時、他に入力の名前を使っているディバイスがあるかを調べるために必要なのだなという推測になるのですが、パッと見たときは少し不思議でした。
また、MFAディバイスの一意制約に対応しつつ、業務端末交換などのタイミングでOTP発行アプリの入れ替えをユーザに対応してもらいたいのですが、今できていません(管理者が消してる)。 Create/Delete を Resource arn:aws:iam::*:user/${aws:username}* で付与するのが無難そうなのですが、それでいいのかなぁ、とちょっと疑問になっています。途中で仕様が変わったものの対応は少し不思議な感じな箇所があるなと思いました。
AWS IAM User のパスワードにカンマが入っていても credentials.csv はクォートされてなかった(たまたま？)
IAM User を新規作成したさいにAWSアカウントのパスワードポリシーでカンマが入ることもあるのですが、初回ダウンロードの credentials.csv はカンマが入ったフィールドをクォートしてませんでした(利用者からのお問い合わせで知りました)。
CSV自体バリエーションがあるものではありますが、ちょっと驚きました。