Identity-Aware Proxy を GKE で利用するコツ
こんにちは，BANK でサーバサイドエンジニア兼インフラエンジニアをやっております，
高橋 (@takutakahashi) といいます．
技術ブログの技術記事第一弾として，管理画面をいい感じにした話をしようと思います！
Identity-Aware Proxy?
さて，GCP では，GAE や Google 提供のHTTPS Loadbalancer を経由する web サービスに対し，
超簡単に Google 認証を付与できる Identity-Aware Proxy (以下 IAP) が提供されています．
Google アカウントによる認証，認可を設定することが可能です．
詳細は以下を参照ください．
https://cloud.google.com/iap/docs/concepts-overview?hl=ja
CASH 管理画面の課題
CASH では，定常運用のために管理画面を持っています．
ActiveAdmin で実装し，アプリケーションのバックエンド API の傍らで動作しています．
この管理画面，もちろん組織の人間でない第三者からのアクセスを防ぐ必要があります．
以前は，アクセス防御のために Basic 認証を利用し，1つのユーザー/パスワードで運用していました．
この状態だと，
- ユーザーとパスワードがわかっていれば誰でもアクセスできる
- インターン生や退職者など，元関係者からのアクセスを防ぐことができない
という課題がありました．
なんとかうまい具合に認証できないか？ということで，
Cloud Identity-Aware Proxy を GKE と組み合わせて使ってみて，そこから得た教訓を共有する．
というのが今回の記事の趣旨です．
GKE と HTTPS Loadbalancer
以下は，kubernetes の用語が多く出てきます．ここでは解説しませんので調べてください．
CASH のバックエンドオーケストレーションには，Google Kubernetes Engine (以下 GKE) を利用しています．
GKE では，アプリケーションを外部公開するための Ingress リソースを作成した際に，
Google HTTPS LoadBalancer と連携しロードバランサを作成してくれる機能があります ．
IAP + GKE
IAP は，HTTPS Loadbalancer に適用できる認証システムです．
GKE で Loadbalancer は自動作成されるため，GKE がどのように Loadbalancer を作成するのかが理解できれば，
IAP と GKE をどのように組み合わせて利用するべきか，理解することができます．
IAP は Service に適用できる
IAP を効果的に使うためには，LoadBalancer と Kubernetes リソースがどうマッピングされているかを知る必要があります．
以下は，機能のマッピング表です．
| 役割 | Cloud LoadBalancer | Kubernetes |
|---|---|---|
| IP や HostHeader によるルーティング | Frontend | Ingress |
| 実際のワークロードへのアクセス | Backend | Service |
| アプリケーション健全性確認 | HealthCheck | Pod (Liveness Probe) |
IAP は，HTTP(S) LoadBalancer の Backend に適用することができます．
つまり，Kubernetes の文脈では Service に適用することとなります．
IAP 適用で気をつけること
CASH 管理画面 の IAP 化でも発生した問題ですが，API と管理画面で同じ Service を経由している場合，
IAP を有効にすると API にも認証がかかってしまうことになります．
これを回避するために，Service はアプリケーションポートごとではなく役割ごとに作成しておくことが望ましいです．
以前の CASH のリソース図はこの様になっており，
この構成を以下のように変更し，
管理画面のアクセス先 svc を分離することでこの問題を解決できました．
ミソは，同一 deployment を向く svc を定義することです．
今後アプリケーションを構築する際も，このように役割分離をしておくことで，
単一役割となりリソース編集コストが減る，マイクロサービス化した際に楽，など，色々とメリットがあります．
ちなみに
現在 IAP を有効にするには，GUI で設定するか，gcloud を利用して CUI で設定するかの方法を取る必要があります．
できれば ingress-gce にやってほしいなあ．．．という気持ちがあるので調べたら，以下の issue で議論されていました．
issue の進みがあまり良くないので，機能が実装されるまで結構時間がかかりそうですね．．．
追記 2019/05/06
BackendConfig Resource で IAP を操作することが可能になりました！*1
reference はこちらで， cloud.google.com
日本語で詳しく解説してくださっている記事が以下となります．
早速手順通り OAuth Client を作成し， BackendConfig と secret を作成したところ，
サービスが ingress-gce の管理対象に入ったタイミングで，指定の Client ID で IAP が有効になることを確認しました．
OAuth 認証画面を利用するためには，適切な Callback URL を指定する必要がありますが，
サービスアカウントによる API 認証に関しては，
Role "IAP-secured Web App User" を持つサービスアカウントで無事認証ができることを確認しました．
Callback URL を動的に挿入する手段がわからないのでモヤッとしますが，一旦良しとします．
終わりに
アプリケーション事業を運営する上で欠かせない管理画面．
ユーザー認証など，ビジネスロジックに影響しない部分はインフラレイヤーで解決し，
節約したリソースで爆速開発していくことが望ましいですね．
宣伝
9/19, 20 で開催される Google Cloud Next '18 in Tokyo にて，BANK インフラストラクチャ事例紹介のセッションを実施いたします！ このブログを読んで，詳しい構成が気になった方は，ぜひお越しいただき，弊社のセッションをご覧ください！
*1:そもそも記事時点で使えていた可能性も
