GCPの組織ポリシーと(プレビュー版)拒否ポリシー

日本情報通信の中根です。

今回は組織ポリシーとプレビュー版で提供されている拒否ポリシーについて私の経験も踏まえサービスといくつかのポリシーについて紹介したいと思います。

組織ポリシー

組織ポリシーはResource Managerの機能として提供されておりリソース構造に従い制約をかけることが可能となります。
つまり「xxxさせない」といった内容を組織やフォルダ、プロジェクトといったリソースに対して適用します。
こういった表現をするとIAMと似ているように感じますが、IAMは誰にに重点が置かれている一方組織ポリシーは何にが重要となります。
この考え方は重要になってくるため意識が必要となります。

また組織ポリシー自体は利用するためには組織に属している必要があります。
エンタープライズな環境では権限的な観点で気軽に試すことができないのですが非常に便利な機能です。

リソース階層と継承

はじめに組織ポリシーを適用するリソースについて触れたいと思います。
前述の通り組織ポリシーは組織やフォルダ、プロジェクトといったリソースに適用します。
ここまではIAMと同じようなイメージですが組織ポリシーとIAMの大きな違いとして組織ポリシーは継承されるポリシーを上書きや打ち消しができます。
GCPに関する権限ですが基本的に上位継承、和集合のイメージがありますが組織ポリシーは違います。

[階層評価について | Resource Manager のドキュメント | Google Cloud](https://cloud.google.com/resource-manager/docs/organization-policy/understanding-hierarchy?hl=ja#example_hierarchy)

打ち消すことができるということはより柔軟な設定やリソース階層に振り回されることがなくなるメリットがある一方、管理の面で煩雑になります。
組織ポリシーにて制約できるポリシーは粒度として大きなものが多いです。

個別のプロジェクトやアプリケーションの観点で見るとあれもこれもとなりがちですが、名前の通り組織としてどうするべきか、原理原則といったレベルのポリシーのみを選択することが重要となります。

エンタープライズ用途にて利用されることのあるポリシー

組織のポリシーの制約 | Resource Manager のドキュメント | Google Cloudよりご自身の組織にて利用されるものをご確認いただければと思いますが今回は私の経験上よく使われるものをいくつかピックアップしたいと思います。

全体: Google Cloud Platform – リソース ロケーションの制限

このポリシーはGCPサービスのロケーションを制限することができます。
特定のリージョンにのみ利用を限定したい場合に利用することが多いです。
注意点としてはロケーションベースのGCPサービスに対して適用となるためロケーションを指定することのできないグローバルな環境でのサービス(e.g. Pub/Sub)については制限をかけることができません。

全体: リソース サービスの使用を制限する

このポリシーは利用できるGCPを制限できます。
利用者へプロジェクトを払い出す際に利用してほしくないサービスというのはままあります。
例えば使い方によってはセキュリティに懸念のあるサービスや、コスト的な観点で利用してほしくないものです。
利用者へIAM制御を行うことでも実現できますがそもそも触らせないといった選択をする場合はこちらのほうがより強力に制限できます。
ポリシーで制限できないGCPサービスもあるためで確認が必要となります。
ただし制限できないものは共通な機能なのであまり困ることは無いかと思います。

GCS: 公開アクセスの防止を適用する

このポリシーはセキュリティ観点でよく利用されるポリシーになります。
組織単位ですとプロジェクト毎にオーナーがおり適切に管理されることが前提となるかと思います。
セキュリティについてはもっとも最初に啓蒙する項目でありますが利便性とのトレードオフで一時的に、なんてことも考えられます。
このポリシー適用することでそんな管理側が意図しないような挙動も制限できます。

話がそれてしまいますがSecurity Command Centerでは制限ではなく公開バケットの検知もできますので用途として使いわけができます。

GCE: VM インスタンス用に許可される外部 IP を定義する

このポリシーもセキュリティ観点でよく利用されるポリシーとなります。
社内システムとしてVPNや専用線を介したオンプレミス環境とGCPサービスのみで完結するようなデザインやサンドボックス環境などに利用されることが多いかと思います。
Googleサービスとの通信は限定公開の Google アクセスを利用したり、Cloud NATを前提とした場合は外部IPが不要となることがあります。
そういった場合にこのポリシーとしてそもそも構成できなようにすることができます。

注意点としてはこのポリシーはインスタンス名とゾーンを指定する必要があります。
インスタンスの作成とポリシー作成どちらから行うか開発プロセスと相談してフローを考える必要があります。

(プレビュー版)拒否ポリシー

さてここまでResource Managerの一機能である組織ポリシーについて説明しましたが、ここからはIAMの機能である拒否ポリシーについて説明します。
組織ポリシーがある程度の粒度の制約だったのに対しこちらはIAMの権限レベルにて利用できないように拒否することができます。

この拒否ポリシーはユーザーに付与されているロールに関係なく特定のプリンシパルの権限を使用できないようにします。
例えばIAM管理者を付与されているプリンシパルに対してiam.googleapis.com/serviceAccounts.createのみを使用できないようにすることができます。
IAMの画面からはIAM管理者付与されているように見えますが実際は拒否ポリシーにて指定された権限が除外された形になります。

同じことはカスタムロールでも利用可能ですが特定のプリンシパルを指定することが大きな違いとなります。
前述のIAMの特性である誰がに着目しており、カスタムロールが必要な権限を足し算的に設定することに比べ特定の権限のみ引き算的に除外する拒否ポリシーというイメージになります。
現在は拒否ポリシーはgcloudコマンドのみがI/Fとなるためコンソールからは設定有無自体確認できずカオスのもととなる可能性がありますがこのような使い方をしたい、というお客様は多くいらっしゃいました。

現在はプレビュー版となりますが管理しやすいI/Fや拒否できる権限が増えることに期待したいです。

まとめ

今回は組織ポリシーと拒否ポリシーと名前が似ていますがもととなるサービスが異なる2つを紹介しました。
クラウドを管理する立場の方は非常に気を揉むことが多い部分に対して効果があるサービスですのでぜひ検討してみてはいかがでしょうか。