Functionキー？Hostキー？―“鍵の世界”をゆるっと理解（内部だけならHostキーも“アリ”）

はじめに

Function/Host/_master の違いを、最小権限の考え方でやさしく整理。
今回、閉域網の内部通信限定の構築だったので、 Host キーで運用がシンプルになりました。その記録を共有します。

1. APIキー種類（Functions）

• Anonymous：**だれでもアクセス可能な公開API ”。
• Function：特定の関数だけに効く“ルームキー”。
• Host：アプリ内の全関数に効く“フロアキー”。内部通信（APIM/同一VNetなど）に限定できるなら、鍵配布点が減って運用が楽。
• master（Admin）：管理APIまで叩ける究極キー。配布禁止が鉄則。

2. 「内部だけなら Host キーでOK」の根拠

• FunctionキーとHostキーの違いはAPIごとにキーを変更するか否か。
• この場合、内部通信で限定し利用者が決まっている状態であるため、Hostキーでリスクなしと判断しました。
• また、運用、保守性に関しても障害時など切り分けが容易となる点もメリットです。

3. 呼び出し方法（2通り）

• HTTPヘッダー x-functions-key で渡す
• またはクエリ ?code= で渡す。

curl -H "x-functions-key: <HOST_KEY>" \
  "https://<app>.azurewebsites.net/api/getUser?id=123"

4. 取得・ローテーション

• CLI：
  • Host/System/Master → az functionapp keys list -g <rg> -n <app>
  • 特定関数 → az functionapp function keys list -g <rg> -n <app> --function-name <fn>
• Key Vault 参照でアプリ設定に秘密を置かない。APIM 側も Named Value を Key Vault 参照にすればローテ自動化しやすい。

5. 実務Tips（ローカル開発時）

• 開発中のFunctionキーは意外と煩わしいもの。環境変数にAPIキー種類を仕込んでおくことで使い勝手がよくなります。これでローカル時はFnctionキー不要で検証ができ、後でキーレベルの変更し忘れも防止できます。

　　・ローカル開発(vscode):local.setting.json に追加
　　HTTP_AUTH_LEVEL：”anonymous”

　・Azure Functions：環境変数に追加
　HTTP_AUTH_LEVEL：function (値）

最後に

あれこれ考えた結果「内部なら Host でええやん」に落ち着いた今回。
意外とこういう“素直な構成”こそ、長生きする気がします。