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 のリソース図はこの様になっており,
f:id:takutakahashi:20180810100238p:plain

この構成を以下のように変更し,
f:id:takutakahashi:20180810100355p:plain

管理画面のアクセス先 svc を分離することでこの問題を解決できました.
ミソは,同一 deployment を向く svc を定義することです. 今後アプリケーションを構築する際も,このように役割分離をしておくことで,
単一役割となりリソース編集コストが減る,マイクロサービス化した際に楽,など,色々とメリットがあります.

ちなみに

現在 IAP を有効にするには,GUI で設定するか,gcloud を利用して CUI で設定するかの方法を取る必要があります.
できれば ingress-gce にやってほしいなあ...という気持ちがあるので調べたら,以下の issue で議論されていました.

github.com

issue の進みがあまり良くないので,機能が実装されるまで結構時間がかかりそうですね...

終わりに

アプリケーション事業を運営する上で欠かせない管理画面.
ユーザー認証など,ビジネスロジックに影響しない部分はインフラレイヤーで解決し,
節約したリソースで爆速開発していくことが望ましいですね.

宣伝

cloud.withgoogle.com

9/19, 20 で開催される Google Cloud Next '18 in Tokyo にて,BANK インフラストラクチャ事例紹介のセッションを実施いたします! このブログを読んで,詳しい構成が気になった方は,ぜひお越しいただき,弊社のセッションをご覧ください!