はじめに

前回の記事でIAPの環境はできたので、それを受けて実際のユースケースに即してどのような事が可能かを検証してみました。

私達が今実装しているアプリケーションにおいて、IAPに求める要件には以下のようなものがあります。それぞれについて確認をしていきました。

ユーザーをなんらかのまとまりで認可させたい

ユーザー個々に対してIAPへのプリンシパル登録をしていくのは煩雑なので、なんらかのグループ的なものにユーザを所属させる・抜くというだけで認可対象を切り替えていきたいと考えていました。

要件を満たせるか？

満たせる。

やりかた

Google Groupでやればよい。例えばこんな感じです。

このようにグループを作っておき、それをIAPに対して登録します。

IAP-secured Web App User として、先ほど作成したGoogle Groupのメールアドレスを登録している状態です。

こうしておけば、このグループに登録したGoogleアカウントならIAPを通過して画面を表示することが出来ますし、それ以外のアカウントはアクセスが抑止されます。

IAPを通過したユーザーの情報を後段のアプリケーションに渡したい

認証・認可に使用するという用途もあるが、それ以外にも実作業者の情報をログにを残す等の監査目的で仕様が考えられるためです。

要件を満たせるか？

満たせる。

やりかた

こちらに書かれています。

実際に試しに作ったこんなコードをデプロイすると、IAP通過時に以下のように結果が取得できます。

res.send(`userEmail: ${userEmail}, userID: ${userID}`)

expressで上記のように出力しているのですが、それぞれの冒頭に accounts.google.com が固定でつくのは、グループにも所属しているからなのですかね。ちょっとこのあたりは調査が必要かもしれないなと思いました。

IAPが停止した場合のヘッダ偽造に対応したい

IAPで保護するということは、逆に言えばIAPが停止してしまえばだれでも素通りできてしまうということです。
しかもその場合ヘッダの偽造などいくらでも可能です。
なので、IAPを通過した場合にのみ付与される情報をしっかりと検証して、NGの場合は強制的に通常ページへのアクセスを遮断するような手法が必要です。

要件を満たせるか？

満たせる。（と思いますが未検証）

やりかた

未検証ですが、こちらに書かれています。
x-goog-iap-jwt-assertion ヘッダを検証すれば良いようですね。

IAPの画面からだと、

まずメニューを選択すると、 JWTオーディエンスコードの取得 というものが出るのでそれをクリックします。で、

それがこのように表示されると。

で何かしらこれを使って署名検証するのだろうと推測しています。
まだ未検証ですがこれは出来るのだろうと踏んでます。

同一クラスタ内のサービス個々にIAPの適用有無をon/off可能としたい

自分たちのユースケースだと、１つのクラスタに複数のGUIをデプロイし、それぞれについてIAPのon/offを制御したいと考えています。それができるかどうかです。

要件を満たせるか？

満たせる。

やりかた

deploymentのexpose、ingressの作成(w/ TLS)までを含めてもう一式立ち上げます。
そうすると以下のような状態になります。

ここで2つめのINGRESSはIAPがOFFになっていますが、こちらにはIAP制御無しでアクセスできることが確認できてます。
もちろんIAPをonすれば両方ともアクセス制限をかけることも出来ました。

まとめ

とりあえずおおよその要件には対応できるように見えます。
現時点で確認できたのはここまでなのですが、追加で URL単位での認可が出来ること を確認しようと思っています。

この意図は例えば以下のようなことをやりたいためです。

デプロイしたアプリケーションを2つの部門が使用する
部門ごとにアクセス可能なURLをコントロールする
- 例えば部門Aは /site-a のみ接続できる
- 例えば部門Bは /site-b のみ接続できる

ただこれは普通に公式手順に基づいてIAP構築をするだけでは無理そうに見えているので一旦調査しようと思います。

また次の記事にでも。