Lookerの個人API資格情報管理に残るセルフホスト版の例外

Lookerは、標準ユーザーの個人API資格情報を管理者が代理管理できなくなる変更について、セルフホスト版のLooker originalにはまだ適用されないと補足しました。

要点

• Looker管理者は、標準ユーザー個人のAPI資格情報を作成・管理できなくなります。
• 標準ユーザーはAccountページから自分のキーを管理し、管理者はセルフサービスの許可だけを制御します。
• 7月22日の補足により、セルフホスト版のLooker originalは現時点で変更対象外だと明確になりました。

今回の更新で変わること

Looker 26.8で案内された変更では、Looker originalの管理者が標準ユーザーに代わって個人のAPI資格情報を作成、表示、管理する方式が廃止されます。標準ユーザーは自分のAccountページからキーを管理します。管理者に残るのは、利用者によるセルフサービスのAPIキー管理を許可するか禁止するかという制御です。管理者が別ユーザーとして「sudo」操作している場合も、そのユーザーのAPIキーは表示されません。個人の秘密情報を管理者からも見えにくくし、資格情報の所有者と利用者を一致させる変更です。

一方、API専用サービスアカウントは扱いが異なります。人の標準ユーザーではなく、APIアクセスだけに使うサービスアカウントについては、管理者が引き続き資格情報を管理できます。自動処理を個人ユーザーのキーで動かしている環境は、この区別を踏まえてサービスアカウントへの移行を検討する必要があります。担当者の退職や異動で個人アカウントを停止したときに、連携処理まで予期せず止まる構成を残さないためです。

7月22日の補足で重要なのは、変更の適用範囲です。公式リリースノートは、この制限がセルフホスト版のLooker originalにはまだ適用されないと明記しました。したがって、セルフホスト環境で従来どおり管理者が個人API資格情報を扱えるとしても、クラウドホスト環境と同じ挙動だと決めつけることはできません。反対に、将来セルフホスト版へ同じ制限が展開される時期も今回の補足からは確定できません。ホスト形態、Lookerのバージョン、APIキーの発行主体を分けて現状を記録し、公式情報の更新を追う必要があります。

移行確認では、標準ユーザーのキーとAPI専用サービスアカウントのキーを棚卸しし、各キーを使うジョブ、失効責任者、ローテーション方法を対応付けます。本人管理へ移ったキーは、IdPでアカウントを停止する手順だけでなく、Looker側でのキー失効確認も退職・異動手順に含めると安全です。セルフホスト環境では、現時点の例外を恒久仕様として運用文書へ固定せず、将来の適用に備えて個人キーへの依存を減らしておく方が移行しやすくなります。

対象になりそうなユーザー・チーム

Looker管理者、ID管理者、API連携を運用するチーム、セルフホスト版Looker originalの保守担当に関係します。

今すぐ対応が必要か

クラウドホスト環境で管理者が個人キーを代理発行していた場合は、本人管理またはAPI専用サービスアカウントへ移す手順を確認してください。セルフホスト環境は直ちに挙動が変わるわけではありませんが、現在の依存関係を棚卸ししておく価値があります。

結局、この更新をどう見るべきか

個人のAPI資格情報を本人管理へ寄せる方針と、セルフホスト版に残る適用差を明確にした補足です。導入形態ごとの違いを把握し、個人キーに依存する自動処理を減らす契機として捉えるのが適切です。