IAPを学ぶとき、SSO、IdP、SAML、OIDC、Google Workspace、Cloud Identity、IAM が一緒に出てきて混乱しがちです。
IAPはIdPそのものではありません。ログイン基盤でもありません。IAPは、認証済みユーザーをWebアプリやVMの前段で通すかどうかを制御する門番です。
本記事では、IAPをGCPのアプリ入口制御として理解するために、SSO / IdP / SAML / OIDC / IAMとの位置関係を整理します。
まず役割を分ける
| 用語 | 役割 |
|---|---|
| IdP | ユーザーが誰かを認証する基盤 |
| SSO | 一度のログインで複数サービスに入れる仕組み |
| SAML / OIDC | IdPとサービスをつなぐ認証連携プロトコル |
| Google Workspace / Cloud Identity | Google Cloudで使うユーザー・グループの土台 |
| IAP | 認証済みユーザーをアプリ入口で通すか制御する門番 |
| IAM | IAPやGCPリソースに対する権限を指定する仕組み |
- IdP / SAML / OIDC = 誰であるかを証明する
- IAP = そのユーザーをアプリ入口で通すか決める
- IAM = GCPリソースやIAPに対する権限を設定する
IAPの位置づけ
IAPは、アプリの前段に置かれるアクセス制御です。
flowchart LR user["User"] idp["IdP<br/>Google Workspace / Cloud Identity / Okta / Entra ID"] protocol["SSO連携<br/>SAML / OIDC"] googleId["Google側のidentity"] iap["IAP"] iam["IAM policy<br/>IAP-secured Web App User など"] app["Web app<br/>Cloud Run / GKE / App Engine / VM"] user -->|"login"| idp idp --> protocol --> googleId user -->|"app request"| iap iap -->|"who is this user?"| googleId iap -->|"is this user allowed?"| iam iap -->|"allowed request"| app
この図で重要なのは、IAPがユーザー管理の本体ではないことです。
ユーザーの認証はIdPやGoogle側のidentity基盤で行われます。IAPは、その認証済みユーザーに対して、対象アプリへ入れてよいかを判定します。
同じ流れをシーケンスで見ると、IAPはログイン処理そのものではなく、認証済みユーザーとIAM設定を見てアプリへ転送するかを判断していることが分かります。
sequenceDiagram participant user as User participant idp as IdP participant iap as IAP participant iam as IAM policy participant app as Web app user->>iap: Access app iap->>idp: Redirect to login if unauthenticated user->>idp: Login idp-->>iap: Authenticated user iap->>iam: Check whether user is allowed iam-->>iap: Allow or deny iap->>app: Forward allowed request
IAPはログイン機能をアプリの外に出す
たとえば、Cloud Runで社内管理画面を作ったとします。
要件は、社内ユーザーだけ管理画面にアクセスできるようにしたい、アプリ内にログイン機能を作り込みたくない、VPNなしでユーザー単位に制御したい、というものです。
この場合、IAPが候補になります。
flowchart LR user["社員ユーザー"] iap["IAP"] run["Cloud Run<br/>管理画面"] user -->|"HTTPS request"| iap iap -->|"許可ユーザーだけ転送"| run
アプリは、IAPを通過したリクエストだけ受け取る構成にします。
SSO / IdP / SAML / OIDCは前提の認証基盤
会社のユーザー管理がOktaやEntra IDにある場合、Google Cloud側と外部IdPを連携することがあります。
会社のIdPとGoogle Cloud側をSAML / OIDCで認証連携すると、Google Cloud上ではそのユーザーとして扱えるようになります。
この連携は、IAPそのものではありません。
IAPは、連携後にGoogle Cloud側で認識できるユーザーやグループを使って、アプリ入口のアクセス可否を判定します。
IAMはIAPを通ってよい人を指定する
IAPでは、対象アプリに対して「誰を通すか」をIAMで設定します。
たとえば、user:tanaka@example.com や group:admin@example.com に IAP-secured Web App User のようなIAP用の権限を付与します。
このIAM設定は、GCSやBigQueryの読み書き権限とは別です。
| IAM設定の対象 | 意味 |
|---|---|
| IAP | このWebアプリ入口を通ってよいか |
| GCSやBigQuery | GCPリソースを操作してよいか |
たとえば、管理画面に入れることと、BigQueryを直接読めることは別の権限です。
IAPとIAMの違い
IAPとIAMはセットで使われますが、役割が違います。
| 観点 | IAP | IAM |
|---|---|---|
| 何か | アプリ入口のアクセス制御 | 権限管理の仕組み |
| 見る対象 | WebアプリやVMへの入口 | GCPリソース操作やIAP権限 |
| 典型要件 | 社内ユーザーだけアプリに通す | 誰がGCSを読めるか、誰がIAPを通れるか |
| 混同しない点 | IdPではない | アプリ前段のプロキシではない |
IAPは、IAMポリシーを使って許可ユーザーを判定します。ただし、IAMそのものがアプリ入口のプロキシになるわけではありません。
IAPではないもの
以下はIAPの役割ではありません。
| 要件 | 主役 |
|---|---|
| Google Cloudリソースの操作権限を制御したい | IAM |
| アプリからGCSへアクセスしたい | Service Account + IAM |
| APIキーやDBパスワードを保存したい | Secret Manager |
| WAFやDDoS対策をしたい | Cloud Armor |
| 会社のSSO基盤を構成したい | IdP / SAML / OIDC / Cloud Identity |
| private接続でVPCからサービスへ到達したい | Private Service Connect / Private Google Access / Private Service Access |
まとめ
- IAPはIdPではなく、アプリ入口の門番
- IdP / SAML / OIDCは、ユーザーが誰かを認証するための前提基盤
- IAPは認証済みユーザーをアプリに通すかどうかを判定する
- IAPを通ってよいユーザーやグループはIAMで指定する
- GCPリソース操作権限のIAMと、IAP入口の許可は分けて考える
- WAFやDDoS対策はCloud Armor、private接続はPSC/PGA/PSAで見る