Azure Functions で HTTP Trigger や Webhook を使う時に指定する API Key ですが、主に Durable Functions を使う時に悩んだのでメモとして残しておきます。
Portal で適当な関数を選んで URL を取得する時に、どのキーを使うか選べます。
このキーはユーザーが自由に生成したり、削除や作り直しが出来ます。
Host Key を使うとどの関数に対しても同じキーでアクセスが出来るので、便利な反面危険でもあります。なので普通は Function Key を使うことになると思います。
Azure Portal 上では Function Key と Host Key しか確認出来ないですが、Azure Functions は内部で System Key も持っているので、実際には 3 種類のキーが存在していることになります。
ちなみに Azure Functions v2 から Key のデフォルト保存場所が共有ストレージから Blob に移動したので、Storage Explorer などを使うとファイルがあることを確認出来ます。
格納されているキーは暗号化されているので、そのままでは使うことは出来ません。
この辺りの変更に関しては Wiki にまとまっているので参照してください。
Changes to Key Management in Functions V2 · Azure/azure-functions-host Wiki · GitHub
App Settings の値を変えることで、これまで通りに共有ストレージに保存するように出来ます。
ここからが本題ですが、Durable Functions にはステータス確認やイベントを発生させるための API が用意されています。CreateCheckStatusResponse で返されるやつがそれです。
当然ながら管理用の API なので Key が必要になりますが、これら Durable Functions に用意されている各 API を実行するには System Key が必要になります。
このキーは Azure Portal からは確認出来ないため、CreateCheckStatusResponse を実際に叩くか Key Management API を利用して取得します。
ドキュメントには v1 と書かれていますが、今のところ v2 でも動作しました。
Key management API (V1) · Azure/azure-functions-host Wiki · GitHub
ぱっと見では Function Key と Host Key しか取得できなさそうですが、/admin/host/systemKeys にリクエストを投げると System Key の一覧が返ってきます。
当然この API も認証が必要なので、Authorization ヘッダーで Bearer Token を指定することになります。
curl -H "Authorization: Bearer TOKEN" https://***.azurewebsites.net/admin/host/systemKeys
ドキュメントには書かれていないのが罠なのですが、Bearer Token を取得する API が Kudu 側に用意されているのでそっちを先に叩いてトークンを取得後、Key Management API を叩くことになります。
取得方法は /api/functions/admin/token を叩くだけなので簡単です。
SCM 側なのでブラウザで直接アクセスしても取得できますが、コードからアクセスする場合には Basic 認証がこれまで通り使えます。このトークンの有効期限は短いので注意。
これで Key Management API を実行すると、Durable Functions 向けに自動生成されたキーを取得できます。
同じような名前のキーが 2 つあるのは、この間の Breaking Changes が関係しているのだと思いますが、System Key なので両方とも問題なく使えます。
これを利用して Durable Functions の実行状態を確認するためのダッシュボードを作ろうと思ったのですが、一瞬で飽きてしまいました。Rewind API が増えて需要はありそうなのですが残念。
