こんにちは。ベーコンシェフです。
みなさん、GoogleCloudで組織ポリシーを設定したことはありますか？
Google Cloudでは、組織、フォルダ、プロジェクトといった階層構造でリソースを管理できます。組織ポリシーとは、これらのリソースに対する操作やアクセスを制限するための仕組みです。具体的には、「制約」というルールを使って、特定のサービスやリソースに対する許可・禁止を設定します。今回はそんな組織ポリシーを検証してみました。

組織ポリシーとは

Google Cloud の組織ポリシーは、クラウドリソースを一元的に制御するためのサービスです。
リソースの利用方法や設定に対し、一元的なルール（制約）を定義し、強制します。
「何ができて、何ができないのか」を明確にし、意図しない操作や設定ミスを防ぎます。
たとえば、「特定のリージョンでのみリソースを作成可能にする」「特定のAPIの使用を禁止する」といったルールを定めることができます。

組織ポリシーを用いることでGoogle Cloudサービスの特定の動作や設定を制限するための「具体的なルール」を定めることができます。

組織ポリシーを導入すると、
1.セキュリティの強化
「機密データが入ったストレージが、誤って全世界に公開されるのを防ぐ」
「未承認のIPアドレスからVMインスタンスへアクセスされるリスクを低減する」
など、情報漏洩や不正アクセスリスクを大幅に削減します。
2.コストの最適化
「開発環境で高価なGPUインスタンスが無制限に使われるのを制限する」
「テスト目的で作成されたリソースが削除されずに放置されるのを防ぐ」
など、不要な支出を抑制し、予算管理を容易にします。

以上のように様々なことができます。

組織ポリシーを設定するには組織が必要です。

組織ポリシーの設定や編集に必要なIAMとして、組織ポリシー管理者ロールが必要です。このロールは組織の階層にしか付与できず、組織以外の階層には組織ポリシー閲覧者ロールであれば付与できます。
組織無しのプロジェクト、組織有のプロジェクト両方にデフォルトで有効な組織ポリシーはありますが、組織無しのプロジェクトの場合IAMロールで組織ポリシー管理者を付与できないため、デフォルトで有効な組織ポリシーを編集することはできません。

以上のことから組織ポリシーを設定するには組織が必要です。(組織無いと管理者ロールが付与できないため)

※組織無しのプロジェクトではデフォルトで組織ポリシー設定されているが編集はできない以下のような状態

まず組織ポリシーの基本的な設定の手順は以下画像の通りです。

IAMと管理>組織のポリシー

三点リーダーからポリシーの編集

ポリシーのソースで変更したい内容に編集しポリシーを設定

意外と簡単に設定することができますね(^^)

今回の検証では下記の①～④について
・サービス アカウント キーの作成を無効化(iam.managed.disableServiceAccountKeyCreation)
・サービス アカウント キー アップロードの無効化(iam.managed.disableServiceAccountKeyUpload)
を用いて検証していきます。
※サービス アカウント キーの作成を無効化、サービス アカウント キー アップロードの無効化以外の組織ポリシーについては結果が異なる可能性があります
①組織無しプロジェクトのアクティブ表示について
②組織無しのプロジェクトを組織配下に移行し、その組織に設定された組織ポリシーが適用された際の動作確認
③組織に属するプロジェクトにて、組織ポリシーに違反する動きをした場合の動作確認
④別組織にプロジェクトを移行し、移行後の組織ポリシーに違反する動きをした場合の動作確認

①組織無しプロジェクトの組織ポリシーアクティブ表示について

先ほどもありましたが、組織無しのプロジェクトにはデフォルトの組織ポリシーが設定されていますが、編集はできません。
ここで、組織無しプロジェクトでデフォルト有効な組織ポリシーは本当に有効なのか、違反をした場合にどうなるかを検証してみました。

内容としてはデフォルトで有効である制約の
・サービスアカウントの API キー バインディングをブロックする(iam.managed.disableServiceAccountApiKeyCreation)
に違反する動きをしてみようと思います。

作成手順としてAPIとサービスの認証情報から認証情報を作成＞APIキーを選択します

すると、APIキーが作成されました。

次に比較対象として組織有のプロジェクトで組織ポリシーを非アクティブにした場合での実行結果がこのようになっています。
※ここで組織有のプロジェクトを使用する意味として、組織ポリシーを編集し非アクティブにできるからです

「サービスアカウントを介してAPI呼び出しを認証する」というチェックボックスがあるダイアログが表示されます。

次に、組織有のプロジェクトで同じ組織ポリシーをアクティブにした場合、組織無しのプロジェクトの結果と同様にダイアログが表示されずAPIキーが作成されます。

以上の検証結果から、
・デフォルトで有効の組織ポリシーも実際には有効である
という結果が得られました。

②組織無しのプロジェクトを組織配下に移行し、移行先組織に設定された組織ポリシーが適用された際の動作確認

移行前のプロジェクトでは以下の
・サービスアカウントキーの作成を無効化する(iam.managed.disableServiceAccountKeyCreation)
制約は非アクティブのため、組織にサービス アカウントキー作成を無効化の制約をアクティブにしている状態で、プロジェクトが組織に移行した場合、組織内で移行前に作成したサービスアカウントキーを利用できるか、を検証しました。

事前にサービスアカウントキーを作成し、プロジェクトを組織に移動させました。
その後CloudShell上で

gcloud auth activate-service-account SERVICE_ACCOUNT@DOMAIN.COM --key-file=/path/key.json --project=PROJECT_ID

コマンドを実行しサービスアカウントキーが利用できるかの判断をしました。(コマンド情報)

青枠の部分では利用可能なサービスアカウントは1つですが、
コマンドで移行前に作成したサービスアカウントキーを利用すると
赤枠の部分で2つのサービスアカウントが利用可能になっていることがわかりますね。
よって組織に移動する前に作成したサービスアカウントキーであれば利用可能でした。
以上の検証結果から、
・組織ポリシー適用前に作成されたサービスアカウントキーについては利用可能
という結果が得られました。

③組織に属するプロジェクトにて、組織ポリシーに違反する動きをした場合の動作確認

組織ポリシーに違反した場合どのようなエラーが出るのか、また、本当に組織ポリシーは適用されているのかを検証しました。
プロジェクトにて以下の
・サービスアカウントキーの作成を無効化する(iam.managed.disableServiceAccountKeyCreation)
制約をアクティブにしました。
そこでサービスアカウントキーを作成しようとすると、

以上のように違反した場合にはブロックされますね。
また、「サービスアカウントキーの作成をブロックする組織ポリシーが組織に適用されています。」とIDまで記載されていて、具体的にどの組織ポリシーについての違反なのかがわかりやすいですね！
以上の検証結果から、
・違反した場合具体的な制約まで表示される
・組織ポリシーは実際に適用されている
という結果が得られました。

なお、違反した場合にはログエクスプローラにエラーとして残ります。

ログエクスプローラはログ閲覧者ロールがあれば閲覧できます。

④別組織にプロジェクトを移行し、移行後の組織ポリシーに違反する動きをした場合の動作確認

④では②の検証に似ていますが、組織から組織への移行の場合にどのような動きをするのかを検証しました。
プロジェクトにて以下の
・サービスアカウントキーの作成を無効化する(iam.managed.disableServiceAccountKeyCreation)
組織ポリシーをアクティブにしました。
今回の検証では以下の状態です

また、実行結果は以下の通りです

サービスアカウントキーを用いてコマンドを実行すると、赤枠の部分で利用可能なサービスアカウントが増えていることがわかりますね！
以上の検証結果から、②と同様に
・組織ポリシー適用前に作成されたものについては利用可能
という結果が得られました。

ちなみに・・・組織間のプロジェクト移行はコマンドでしか実行できず、デフォルトで組織ポリシーが有効です。(resourcemanager.allowedExportDestinations、resourcemanager.allowedImportSources)
移行するには移行先と移行元の組織ポリシーでそれぞれの組織IDを指定して許可してあげる必要があります。

組織ポリシーを編集、設定をするのが不安な場合、組織ポリシーにはドライランモードが導入されており、組織ポリシーの編集でどんな影響を与えるんだろう、と悩んでいる人にもポリシーが適用される前にどんな影響を与えるかを確認できます！
ドライランモードの設定と確認方法は以下画像の通りです。

組織ポリシーの編集から、ドライランに遷移しドライランポリシーを管理を選択

新しいルールから適用したいルールを設定し、ドライランポリシーを設定

ドライランで設定した制約で違反をした場合には、ログエクスプローラーで警告としてログが残ります。

これで事前に、組織ポリシーを設定した際に違反になってしまう動作がわかりますね。

今回は組織ポリシーについて検証してみました。
検証結果から
・既存のリソースは、移動した後の組織ポリシー適用後も引き続き利用ができる(検証時に利用した組織ポリシーについて)
・組織ポリシーに違反した場合にはログとして出力される
ことがわかりました。
組織ポリシーの制約の数は153個もあり(2025/6/4時点)、適用するまでが大変ではありますが、組織を運用する際には重要な要素になりそうですね！
適用が難しい場合はドライランモードでまず試してみるのも良いですね。

最後まで読んでいただきありがとうございました。