[アップデート] Amazon Verified Permissions で API Gateway を使う場合に、Open ID connect (OIDC) でもポリシーストアの自動セットアップが出来るようになりました

いわさ

2024.06.10

いわさです。

先日以下のアップデートアナウンスがありました。
Verified Permissions で API Gateway を簡単にセキュリティ保護出来るようになったという内容です。

こちらどういうことなのかというと、Verified Permissions はアプリケーションの認可部分を受け持つマネージドサービスとなっています。
Cognito や OIDC など様々な IdP をサポートしており、認可ロジックも AWS API を呼び出すだけなのでどういったアプリケーションにも適用することが可能です。

ただし、構成するためには認可ポリシーを構築しつつ認可ロジック部分も一定の実装が必要だったりと、ワンクリックで実装出来るようなものではありませんでした。

しかし 2024 年 4 月に、アプリケーションが API Gateway で IdP が Cognito の場合であれば、ポチポチっとしてやるだけで認可ポリシーストアや認可コードを自動で構築して設定までしてくれるセットアップ機能が登場しました。

上記は API Gateway + Cognito 限定の機能だったのですが、今回のアップデートでは API Gateway + OIDC でも上記の簡単セットアップ機能が使えるようになったというものです！

やってみた

実際に試してみたので使い方などを紹介します。

結果としては認可ロジックの実行時になぜか失敗してしまっています。
今回私は Microsoft Entra を IdP に使ったのですが、アップデートアナウンスでは CyberArk、Okta、Transmit Security と提携していると記載がされており、もしかするとひと手間必要なのかもしれないです。まぁそれは後日改めて対応してみます。
今日はとりあえずセットアップ方法まで紹介したいと思います！

準備として次のような適当な API Gateway (REST) と、Microsoft Entra ID アプリケーションをセットアップしています。

% curl https://85h8tlpgsc.execute-api.ap-northeast-1.amazonaws.com/hoge0610stage/hoge
{
    "val": "hoge"
}
% curl https://85h8tlpgsc.execute-api.ap-northeast-1.amazonaws.com/hoge0610stage/hogeadmin
{
    "val": "admin"
}

IdP (Microsoft Entra) のトークン取得方法

今回の機能を使うと自動で Lambda オーソライザーが作成され API Gateway の認可コンポーネントとして使われます。
その認可ロジックの中で Verified Permissions API を呼び出しているような仕組みとなっています。

検証方法ですが、次の記事のような方法で事前にブラウザ経由で Microsoft Entra ID の認証エンドポイントにアクセスし、ID トークンを取得しておきます。

Entra 側でグループクレームを含むように追加設定してありまして、sub と groups が確認出来ますね。
Verified Permissions の自動セットアップではグループ指定が必要なようなので、これらの情報を使いたいと思います。

Verified Permissions のセットアップ

Verified Permissions で新規ポリシーストアの作成を選択し、次の「API Gateway と ID プロバイダーによるセットアップ - 新品です」を選択します。そう新品なのです。
ちなみに今回のアップデート前は「コグニートと API ゲートウェイによるセットアップ - 新品です」という表記でした。

Verified Permissions を使う API Gateway とステージを指定しインポートを行います。
自動でリソースやアクションが取得され、それがそのまま Verified Permissions の Cedar で指定するアクションになります。これは便利。

続いて ID ソースを選択する画面が表示されました。
ここは以前は無かったですね。Cognito のみでしたからね。
外部 OIDC プロバイダーを指定しましょう。

後は OIDC のトークン検証に必要な情報を入力します。
先ほど検証した JWT あるいは、Azure ポータルから Issuer やクライアント ID を入手します。
トークンの種類は ID トークンとアクセストークンが選択出来るようで、今回は ID トークンを選択しました。アクセストークンのほうが良いんですが、ID トークン手軽なのでつい使ってしまう...

トークンの構成を設定したら、次はグループを定義し、どのグループがどの API アクションにアクセス出来るのかを定義します。
ここでグループ名に何を設定すればよいかわからなかったので ID を指定したのですが、後から検証値だけ変更出来るようなのでわかりやすいグループ名を設定しても良さそうでした。

どのグループに何を許可するか決めたら、最後にデプロイ操作の確定を行います。
後ろで CloudFormation スタックがデプロイされています。
デフォルトでは Lambda オーソライザーの API へのアタッチは手動で行う方式になっています。運用環境への影響などを避けるためですね。

あるいは検証環境などであればこのステップでそのまま Lambda オーソライザーのアタッチまで実行も可能です。

最大 1 時間かかるような記述がされていますが、スタックのデプロイ状況を確認してみると数秒で完了していました。

デプロイされたリソースを確認してみる

デプロイされたリソースを確認してみましょう。

まず、API Gateway には Lambda オーソライザーがアタッチされています。

そして、その Lambda オーソライザーが実行する Lambda 関数は次のようなものになっています。
このあたりは Cognito 版と同様に Verified Permissions の API を呼び出してトークンクレームを評価するような動きをしています。
細かい認可ロジックは実装されておらず、Verified Permissiosn のポリシーストアに任せていることがわかります。

そして Lambda 関数の環境変数でポリシーストアが指定されているのですが、もちろんポリシーストアも自動で作成されています。
以下はセットアップで指定した、各グループにどのアクションを許可するのかというポリシーです。

実行してみたが...

セットアップでこれで終わり！と思ったのですが実行してみたところ失敗しました。
冒頭記載したように提携している IdP 以外の場合はもうひと手間必要な雰囲気を感じます。このあたりは次回以降見直してみます。

% curl -H "Authorization: eyJ0eXAiOi...jnPqFBzxA" https://85h8tlpgsc.execute-api.ap-northeast-1.amazonaws.com/hoge0610stage/hoge
{"Message":"User is not authorized to access this resource with an explicit deny"}