Google Cloud のアクセス管理をおさらいしよう 2021年版
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2021 の 5日目の記事です。
TL;DR
本記事では Google Cloud でのアクセス管理について、今まで紹介してこなかった Identity-Aware Proxy や IAM Conditions、トラブルシュートに役立つツール群を紹介しています。2021年のアップデートも最後にまとめてあります。
はじめに
Google Cloud Japan Customer Engineer Advent Calendar 2019 で、Google Cloud の IAM をおさらいしよう
Google Cloud Japan Customer Engineer Advent Calendar 2020 で、Google Cloud のアクセス管理をおさらいしよう 2020アップデート版
という記事を書いたのですが、今まで多くの方に読んでいただいております。未だに読んでくださっていることから IAM は奥が深いことがよくわかりますね！今年も、IAMについて書いていきたいと思います。
IAM の考え方は基本的には、変わっていないので基礎の部分に関しては、Google Cloud の IAM をおさらいしよう、Google Cloud のアクセス管理をおさらいしよう 2020アップデート版 を読んでいただければとおもいます。
今回は、過去の記事であまり触れてこなかったアクセス管理系のプロダクトやツールをご紹介していきます。
Identity-Aware Proxy（IAP）は App Engine、Compute Engine、 Google Cloud Load Balancing へのアクセス（HTTP、SSH、TCP）をユーザー単位で許可する仕組みを提供します。また Identity Platform と連携し、管理されているユーザーのみアクセスさせることも可能です（Google アカウントのアクセス許可と共存はできません）。さらに Access Context Manager のアクセスレベルと連携して、アクセスするユーザーの Context を条件にすることが出来ます（デバイス認証は BeyondCorp Enterprise の有料機能となります）。
IAP を利用することで、HTTPS によってアクセスされるアプリケーションの前に、認証と承認のレイヤを設けることが出来ます。つまり、ネットワーク レベルのファイアウォールに頼らずに、アプリケーション レベルのアクセス制御が可能です。
これは BeyondCorp Enterprise のコアの技術の一つでもありますね！例えばApp Engineであれば、
のように、水色のコンポーネントで認証と承認を実施してます。サービス（アプリケーション）ごとに設定が可能なので、企業内で特定の組織やチームのみアプリケーションにアクセスさせたいシーンに有効な機能ではないでしょうか。注意事項は、同一のプロジェクトでは GAE のサービスごとに IAP のオンオフが設定出来ない点です。IAPを、利用するサービスと利用しないサービスが混在する場合、プロジェクトをわけることを推奨します。
IAP は TCP転送もサポートしています。特定の VM に対し SSH や RDP などを行うユーザーの制御が可能です。特定のIP アドレスからのみ FW を許可するような設定も必要ないですし、OS Login を活用すれば管理者権限でのログイン可否も、IAMで制御できてしまいます。便利！
IAP を利用したTCP転送を許可するには、ファイアウォールにIP 範囲 35.235.240.0/20 からの上り（内向き）を許可する必要があります。
とても便利なIAP ですが、Identity-Aware Proxy の以下の機能は BeyondCorp Enterprise の有料機能となっています。
- IAP を内部 HTTP 負荷分散で使用する
- 非 Google Cloud リソースのプロキシ
- IAP のカスタマイズ
- アクセスレベルでのデバイス属性の使用
- カスタム アクセスレベルを定義する
IAM Conditions を利用すると、どのような条件下であればその作業を実行できるか、という更に細かい設定が可能になります。条件を満たす場合のみ権限が付与される、と捉えていただくとわかりやすいかもしれません。
IAM Conditions は、例えば、日中の時間帯の会社のネットワークからのアクセスは管理者権限、それ以外からのアクセスの場合は閲覧者権限で操作を制限するといったことが可能です。
IAM Conditions は Condition Builder とよばれる UI で条件を作っていくか、Condition Editorに Common Expression Language（CEL）を使って記述する方式で条件を設定します。
CEL を使う場合、以下のような表現になります。こちらは指定した接頭辞「exampleco-site-assets-」 で始まる名前の Cloud Storage バケットにのみアクセスを許可する表現になります。（参考）、CEL の構文はこちらを参照してください。
resource.type == “storage.googleapis.com/Bucket” &&
resource.name.startsWith(“projects/_/buckets/exampleco-site-assets-”)さて、IAP、IAM Conditions などを紹介してきましたが、前回の記事も合わせて見てみると IAM は奥が深いということを改めて実感します。 実際ベストプラクティスなどには最小権限を適用しましょう、とあるのですがガチガチに設定して変更に大して柔軟性を失ったりもしますし、変更したらアクセスできなくなってしまった、みたいなこともあるかと思います。さらに、ユーザーが特定のリソースにアクセスできる理由や、API を呼び出す権限がない理由なんかを特定するのは、時間がかかったりもすることも。。。
そんなときに是非試していただきたいのが、 Policy Troubleshooter と Policy Analyzer です。
Policy Troubleshooter は、ユーザーがなぜリソースにアクセスできるのか、なぜAPI を呼び出す権限がないのか、を簡単に調べることができます。Policy Analizer も似たような機能ですが 、どのプリンシパル（ユーザー、サービス アカウント、グループ、ドメイン）が、どの Google Cloud リソースに対して、どのアクセス権を持つかを調べる事ができます。例えば、
- ユーザー Yutty はどの BigQuery データセットに読み取り権限を持っているか
- 組織の課金管理者は誰か
- あるプロジェクトのリソースに対して customer-engineer グループはどのロールと権限を持つか
などです。細かい使い方などは割愛しますが、IAM で困ったらまずは Policy Troubleshooter と Policy Analyzer を利用してみましょう。使い分けは、あくまで個人的な印象になりますが、ユーザー発信の調査は Policy Troubleshooter、リソース発信の調査は、Policy Analyzer なのかなと思います。ちなみに Policy Analyzer は現時点だとConsole では利用できないので、まずは Policy Troubleshooter から使ってみましょう。
Access Context Manager は、Google Cloud のプロジェクトとリソースに対する、属性ベースのアクセス制御を定義するものになります。例えばアクセス元のデバイスやOS、IPアドレス、ユーザーIDなどの属性によって制御することが可能です。
Access Context Manager で定義するルールは、「アクセスレベル」と呼ばれ、IAP や IAM Conditions のアクセス許可の条件の1つとしても利用することが可能です。ですが、上述のとおり、アクセスレベルでのデバイス属性の使用 をIAPで利用したり、後述する VPC Service Controls での利用は、BeyondCorp Enterprise の有料機能です。
VPC Service Controls
Google Cloud のAPIに対して、境界と呼ばれる仮想境界を作りアクセスとデータの流れを制御します。API アクセスに関しては、VPC におけるFirewall みたいなものだとイメージいただくとよいかもしれません。データの流れに関しては、BigQuery や Cloud Storage などに保管されているデータの、プロジェクトからの持ち出し防止や、逆にペリメータの外からのデータ取得の防止も可能です。アクセス制限には、Access Context Manager で定義したアクセスレベルを適用できます。
VPC Service Controls を利用するとき、対象のプロジェクトとプロダクトを選択します。Google Cloud を利用していく中で、「VPC Service Controls によってアクセスが拒否されている」というメッセージが表示されているのですが、どのアクセスレベルで引っかかったことにより拒否されているのか、わからないときがあります。
そんなときは VPC Service Controls Troubleshooter を利用してみましょう。実際の画面で、このような表示をされることがあります。
この画像の、 jEpnInOjCSqW3Z38LCDj7LJGe3skW9O4loAaqeLNLTQYOfM5IJUdhg がVPC Service Controls によって拒否された理由を特定するユニーク ID です。こちらはAudit Logにも記録されています。
Security > VPC Service Controls から TROUBLESHOOT をクリックし、
以下の Unique Identifier に先程の ユニークID を入力してみましょう。
TROUBLESHOOT ボタンをクリックすると、Trobleshooter が該当のユニークIDを含むエントリを見つけてきて分析してくれます。
どうやら、今回のケースではアクセスレベルに引っかかっているのですが、時間とIPアドレスに理由がありそうです。
アップデートまとめ
最後に2021のアクセス管理系プロダクトのアップデートを、こちらにまとめておきます。
Resource Manager（リリースノート）
[6/8] Resource Settings API が GA になりました。リソース設定を使用して、GCP プロジェクト、フォルダ、および組織の設定を一元的に構成できます。
[5/26] ある組織から別の組織にプロジェクトを移行するプロセスが GA になりました。プロジェクトの移行が組織に与える影響を簡単に確認するには、Cloud Asset Inventory Analyze Move API を使用して、移行を実行する前に詳細レポートを取得します。詳細については、プロジェクトの移行およびプロジェクトの移動の分析を参照してください。
[2/9] タグが公開 Preview でリリースされました。タグは、リソースに特定のタグがあるかどうかに基づいて、ポリシーを条件付きで許可または拒否する方法を提供します。
Identity-Aware Proxy関連
[5/3] Cloud Run で Identity-Aware Proxy を使用して、ユーザ ID とコンテキストを使用してアプリケーションへのアクセスを保護できるようになりました｡この機能は Public Preview で利用可能です
[2/3] Identity-Aware Proxy（IAP）は、 内部 HTTP（S）ロード バランシング でサポートされています。このサポートは一般提供で利用できます。また本機能は BeyondCorp Enterprise の購入が必須となります｡詳細は BeyondCorp Enterprise の料金 をご参照ください
Identity and Access Management（ IAM ）（リリースノート）
[10/26] 認証情報のアクセス境界 にて、Go、Java、Node.js、Python の更新された認証ライブラリを使用して、OAuth2.0 アクセストークンをダウン スコープトークンと自動的に交換できるようになりました。詳細については、アクセス トークンを自動的に交換して更新する を参照してください
[10/19] Cloud Console の IAM ページに、ポリシーの洞察に加えて、ラテラル ムーブメントの分析情報の管理 が表示されるようになりました。この機能は Preview です
この機能により、あるプロジェクトのサービス アカウントに別のプロジェクトのサービス アカウントの権限借用を許可しているロールを特定できます
[10/13] SAML 2.0 と互換性のある任意の ID プロバイダで Workload Identity 連携 を使用できるようになりました。この機能は Preview です。
[8/27] Cloud Console での Google Groups 管理 が GA になりました
[8/2] Activity Analyzer を使用して、いつ、サービスアカウントとキーが最後に Google API の呼び出しに使用されたのかを確認できるようになりました。この機能は Preview です
[7/27] Recommender は、ラテラル ムーブメントの分析情報 を生成するようになりました｡ ラテラル ムーブメントとは､あるプロジェクトのサービスアカウントが別のプロジェクトのサービスアカウントとして動作するためのロールを識別します｡ gcloud コマンドライン ツールまたは Recommender REST API を使用して、ラテラル ムーブメントの分析情報を管理 できます。この機能は Preview で利用可能です
[7/22] IAM 用の C++ クライアント ライブラリ が利用可能になりました。クライアントライブラリは、IAM API と Service Account Credentials API（short-lived credentials）をサポートしています
[7/21] 付与・取消ができる Cloud Storage の役割に制限 を設定できるようになりました。これが可能なのは、Cloud Storage が条件として modifiedGrantsByRole API 属性を認識するようになったためです。IAM Conditions と iam.googleapis.com/modifiedGrantsByRole API 属性を使用すると、メンバーが付与および取り消しできるロールに制限を設定できます
[6/10] IAM ロールの推奨事項 のドキュメントに、Policy Insights を使用して推奨事項を生成する方法についての詳細が含まれるようになりました
Cloud Identity（リリースノート）
- [5/14] Google Cloud Console を使用して Workload Identity フェデレーションを管理できます。詳細については、Identity プロバイダーのドキュメントを参照してください
- AWS からのアクセスリソース
- Microsoft Azure からのアクセスリソース
- OIDC identity プロバイダーからの Access リソース
[5/10] 異なるプロジェクトのリソースにサービスアカウントをアタッチする機能（異なるプロジェクトのリソースにサービスアカウントからアクセス出来る機能）が GA です
[4/9] Workload Identity フェデレーション が GA になりました。Workload Identity フェデレーションを使用して、オンプレミスおよびマルチクラウド ワークロード（AWS, Azure）から Google Cloud リソースへのアクセスを許可できます（これまでのようにサービスアカウント キーで Google Cloud へアクセス必要がなくなりました）
[4/7] gcloud コマンドラインツールと REST API を使用して、フォルダーレベルおよび組織レベルのロールバインディングに関する推奨事項を取得できるようになりました。この機能はプレビューです
[4/1] ポリシーシミュレータが GA です。ポリシーシミュレータを使用して、ポリシーの変更を適用する前にシミュレートできます
[3/16] タグが GA です。タグをリソースに添付してから、タグを使用してリソースへのアクセスを管理できます
[2/16] IAM Condition を使用して、メンバーが付与および取り消すことができるロールに制限 を設定できるようになりました。この機能は GA です
[2/24] ポリシーシミュレータ を使用して、ポリシーの変更を適用する前にシミュレート できるようになりました。この機能は Preview です
[2/9] タグをリソースに追加して、タグを使用したリソースへのアクセスを管理できます。（Preview）
[1/20] ポリシーに関するトラブルシューティングを使用すると、ユーザーがリソースにアクセスできる理由や、API を呼び出す権限がない理由を簡単に調べることができます。
さいごに
今回は、Identity-Aware ProxyとIAM Conditions とアクセス管理で役に立つトラブルシュートツールを紹介してきました。明日 2021–12–06 は swacchi さんがFirebase 系の記事を投稿する予定です。乞うご期待を!!
