![[アップデート] Kiro で管理者がサインイン方法を制限できるようになったので試してみた](https://images.ctfassets.net/ct0aopd36mqt/4uTbTE9O9jUJCOs80dZ0Ao/e2da592b5eaaad0f5993d6ff64a12467/aws-kiro.png?w=3840&fm=webp)
[アップデート] Kiro で管理者がサインイン方法を制限できるようになったので試してみた
いわさです。
Kiro には IAM Identity Center や AWS Builder ID、Google、GitHub といった複数のサインイン方法があります。
これまでは、組織として IAM Identity Center での利用を求めていても、ユーザーが個人の Google アカウントや Builder ID でサインインするのを組織側で統制することが出来ませんでした。
先日の Kiro ブログで紹介されていましたが、現在はガバナンス機能として管理者がサインイン方法を制限する機能が提供されています。
こちらを実際に使ってみたので紹介します。
統制しなかった場合の従来の挙動
まず、今回の機能を使わなかった場合の流れを Kiro IDE で確認してみます。
次のように Kiro IDE 側ではサインインボタンが表示され、ボタンを押すとブラウザが開いてどの認証オプションを使うかユーザーが自由に選択し、ブラウザで認証が完了すると IDE にリダイレクトされる感じです。
Kiro Enterprise を使わせたい組織でも次のように個人の AWS Builder ID でサインイン出来てしまいます。
Kiro CLI の場合でも概ね同様で、ブラウザ側でサインインしてクライアントアプリケーションにリダイレクトされる感じです。
実際に確認してみる
ではここから統制機能を使ってみます。
使い方ですが、Kiro の管理コンソールで設定するのではなくmanaged-settings.json というファイルを作成し、それをクライアント端末に配信する必要があります。
そのため組織として活用する場合は MDM などの仕組みが前提になりそうです。Kiro 公式ドキュメントでも次のように触れられています。
You can also deploy this file via MDM (e.g., Jamf, Kandji) to manage it at scale.
この設定ファイルが配信されているクライアント端末では、Kiro IDE と Kiro CLI どちらもこのルールにしたがってサインインの挙動が変更されます。
Kiro IDE の場合は1.2 以降、Kiro CLI の場合は2.25.0 以降で利用できるとのことです。
They apply to Kiro IDE (version 1.2 and later) and Kiro CLI (version 2.25.0 and later) on the device where the file is deployed.
今回は「IAM Identity Center だけ許可し、個人アカウントは使わせない」設定を試します。おそらくこれが一番多いパターンだと思います。
公式ドキュメントによると、macOS の場合は/Library/Application Support/Kiro/managed-settings.json にファイルを配置する必要があるようです。
{
"rules": [
{
"capability": "signin_method",
"match": ["*"],
"exclude": ["idc"],
"effect": "deny"
}
],
"settings": {
"idc_start_url": "https://my-org.awsapps.com/start",
"idc_region": "us-east-1",
"signin_help_url": "https://it.example.com/kiro-help"
}
}
ルールは "capability": "signin_method" で、effect は常に deny です。
match に ["*"] を指定して全方法を拒否し、exclude に残したい方法を書いてます。idc（IAM Identity Center）だけ除外してます。
settings の 3 つはサインイン画面に反映される値みたいです。
idc_start_url と idc_region は IAM Identity Center のフォームに事前入力され、signin_help_url はヘルプリンクとして表示されます。
URL は https:// である必要があります。
なおmethod 名は大文字小文字を区別するとのことです。使えるのは idc external_idp builder_id google github social で、画面ラベル（Your organization）や内部 ID（awsidc）は受け付けないそうです。
先ほどの managed-settings.json を配置後、Kiro IDE からサインアウトしてから起動してみます。
Kiro IDE のサインイン画面がこちら、若干変わったのですが気づきますかね。
「Need help signing in?」のリンクが追加されています。こちらを押すと設定ファイルで設定した signin_help_url に遷移しました。
そのまま「Sign in」を押すと、方法を選ぶ画面を飛ばして直接 IAM Identity Center のフォームが開きました。
start URL とリージョン（us-east-1）が事前入力された状態です。
そもそもこの Start URL の入力を指示するのも若干面倒だったので、直接ここまで行ってくれるのありがたいな。
許可した方法が IAM Identity Center 1 つだけだったので、選択画面が出ずに直接フォームに進んだようです。
画面下の「Show all options」を押しても、出てくるのは「Your organization」だけでした。
このとき Kiro IDE が開くサインインURLには signin_methods=awsidc というパラメータが入っていました。
許可された方法だけを URL に乗せてサインインページを開く作りのようで、選択画面にも許可外の方法は出ませんでした。
無事に組織ユーザーでサインインでき、アカウント表示は「Kiro Enterprise」、プランは「Kiro Pro+」になりました。
配置前の個人 Builder ID（Kiro Free）とは別のアカウントです。
ちなみにこれはブラウザの表示が変わっただけで、URL パラメータを書き換えるとどうにかできるのでしょうか。
Kiro IDE がブラウザ用に発行した URL が今回の機能でコントロールされているように見えます。次の部分です。
こちらのサインイン方法に「builderid」も追加してみるとブラウザ上で次のように選択できるようになりました。
このまま AWS Builder ID でブラウザ上はサインインが可能です。しかしリダイレクトされた Kiro IDE 側では次のように認証に失敗しました。
公式ドキュメントによると、ブラウザから結果が戻ってきたときにクライアントがサインイン方法などを再チェックし、トークン発行前に拒否するので URL 編集では回避できない、と記載があります。
When the browser hands the result back, the client checks the method again and refuses a denied method before a token is issued, so editing the sign-in URL does not get around the rule.
URL を手で編集しても回避できないことが確認できましたね。これは良い。
さいごに
本日は Kiro で管理者がサインイン方法を制限できるようになったので確認してみました。
Kiro Enterprise を導入したい多くの組織では、この個人アカウントでのサインインなど統制できないアカウントの利用を制限したい方も多いと思います。
MDM での配布が難点ではありますが、制限できる方法が加わったのはありがたいですね。
なお、公式ドキュメントに注意事項として記載されていましたが、この制御はクライアント（インストールされた Kiro）が適用するものです。
Kiro Web や設定ファイルの無い端末では制限がかからず、対応バージョンより古いクライアントはルールを無視するとのこと。
Sign-in controls are enforced by the installed client. They do not restrict sign-in in Kiro Web or on devices without the file, and a client version that predates them ignores the rule.[1]
