数日前に Azure Container Apps でも App Service / Azure Functions と同様の組み込み Authenticationがサポートされました。App Service Authentication はかなりの高頻度で使っている機能なので、Container Apps でも間違いなく便利に使えるはずです。
App Service と同様のアプリケーション側に近い機能が実装されたということは、Container Apps の開発方針も透けて見えるようで今後にも期待が高まります。
ちなみに App Service と同様と書きましたが、内部で利用されているモジュールは全く同じものらしいです。Sidecar で実現しているのは Linux の App Service と同様ですね。*1
No. I really wish they called that project something else. Container Apps is using the same "EasyAuth™️" middleware component that is used by App Service / Functions. When enabled, each replica is injected the EasyAuth™️ sidecar that handles the /.auth endpoints.
— Anthony Chu (@nthonyChu) 2022年4月27日
モジュールが同じということは、当然ながら App Service で利用出来た機能は使えるはずですし、問題もそのまま受け継いでいることになります。
例外的に Token Store は非対応の機能となっているようです。Token Store 自体が App Service の共有ファイルを利用している事情もあるので、Container Apps でのサポートは SWA と同様に望み薄かもしれません。
Azure AD 認証を有効化して試す
とりあえずいつも通り Azure AD 認証を Azure Portal から有効化してみます。見て分かるように Azure Portal での画面は App Service / Azure Functions と同じです。
なので詳しい説明はしませんが、Azure AD アプリケーション周りも全く同じ設定で作成されます。つまり Hybrid Flow が必要になるので手動作成時には注意が必要です。
設定を追加してしまえば、後は App Service と全く同じ挙動です。Azure AD 認証が自動的に行われて、テナントに存在するユーザーであればページが表示されます。
Authentication の機能とは関係なく App Service でも同様なのですが、Azure Portal から Azure AD 認証を追加すると Issuer URL が sts.windows.net
になるのでログイン時にリダイレクトが 1 回増えます。Issuer URL を login.microsoftonline.com
に変更することで無駄なリダイレクトを排除できます。
ログインしているユーザー情報は X-MS-CLIENT-PRINCIPAL-NAME
などの HTTP リクエストヘッダーで渡されるので、アプリケーションでの処理は App Service で行っていたものと同じで良いです。あと Token Store が存在しないので /.auth/me
は 404 になっています。
ARM Template や Bicep で利用可能な定義は以下のリポジトリで公開されています。
項目自体は App Service とほぼ同じなので、ARM Template を書いたことがある人ならすんなり理解できるはずです。認証エンドポイントが /.auth
から始まるのが気に食わない場合は変更できます。
Front Door などを前段に置いた際の注意点
Container Apps は App Service と同様に自動生成されたホスト名が提供されていますが、通常はカスタムドメインを割り当てることになるので Front Door を置いて確認しておきます。
Front Door の作成時に Container Apps は出てこないので Custom を選択して、ホスト名を手動で入力すると問題なく利用できるようになります。将来的には対応されるでしょう。
作成後に Front Door のホスト名で Authentication 設定済みの Container Apps にアクセスすると、以下のようなエラーが出ることがあります。
あるいはログインが成功してもホスト名が Container Apps のものに戻ってしまっているはずです。
既に知っている方も多いと思いますが、この問題は X-Forwarded-Host
がデフォルトでは無視されることに起因していて、もちろん App Service Authentication でも発生します。
もちろん回避方法は用意されているので、ARM Template や ARM Explorer から設定を変更することで対応可能です。詳しくは以下のエントリを参照してください。
ARM Explorer で forwardProxy
の設定を変更すると、Front Door のホスト名でアクセスした場合でもそのホスト名が維持されたままリダイレクトされます。
割とはまる部分なので頭の片隅に置いておきたい設定になります。Azure Portal から設定できると良いのですが、今のところは隠し機能みたいになっていてあまり良くないです。