G-gen の又吉です。当記事では、 Google Cloud（旧称 GCP）リソースのプロビジョニングとオーケストレーションができるサービスである Config Controller で組織ポリシーを定義してみました。

前提知識

Config Connector

Config Connector とは、 Kubernetes を使用して Google Cloud リソースを管理できる open source の Kubernetes アドオンサービスです。

Kubernetes を使用するため、Kubernetes のマニフェストファイルで定義したオブジェクトを「理想の状態」として定義し、「実際の環境」に差分が生じたときに理想の状態を維持(自動修復) することができます (Reconciliation Loop) 。

その他 Kubernetes の基本については、以下のブログでも解説しています。

blog.g-gen.co.jp

Config Controller

Config Controller とは、Config Connector のマネージドサービスであり、実体は 限定公開の標準 GKE クラスタ が使われております。

尚、Config Controller インスタンスには Config Connector の他に、Policy Controller と Config Sync がプリインストールされていますが、今回の検証では使用しないため説明を詳細させていただきます。

検証概要

今回は、Config Controller を用いて組織ポリシーを定義していきたいと思います。尚、実行環境は Cloud Shell となります。

事前準備

API の有効化

必要な API を有効化します。

gcloud services enable krmapihosting.googleapis.com \
    container.googleapis.com \
    cloudresourcemanager.googleapis.com \
    serviceusage.googleapis.com

Config Controller インスタンスの作成

以下のコマンドを実行し、Config Controller インスタンスを作成します。

CONFIG_CONTROLLER_NAME={Config Controller 名を入力}
LOCATION={ロケーション名を入力}
  
gcloud anthos config controller create ${CONFIG_CONTROLLER_NAME} \
    --location=${LOCATION}

Config Controller インスタンスの確認

Config Controller インスタンスのリストを表示し、Config Controller インスタンスが作成されたことを確認します。

gcloud anthos config controller list \
    --location=${LOCATION}

STATE が RUNNING になれば、無事作成できています。

NAME: <CONFIG_CONTROLLER_NAME>
LOCATION: <LOCATION>
STATE: RUNNING

認証情報の取得

Config Controller インスタンスの認証情報とエンドポイント情報を取得します。

gcloud anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \
    --location ${LOCATION}

サービスアカウントに権限を付与

Config Controller が Google Cloud リソースを管理するため、Config Controller のサービスアカウントに権限を付与します。

PROJECT_NO={プロジェクト番号を入力}
PROJECT_ID={プロジェクト ID を入力}
ORG_ID={組織 ID を入力}
SA_EMAIL="service-${PROJECT_NO}@gcp-sa-yakima.iam.gserviceaccount.com"
  
# プロジェクトに対してのオーナーロールをサービスアカウントに付与
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member "serviceAccount:${SA_EMAIL}" \
    --role "roles/owner" \
    --project ${PROJECT_ID}
  
# 組織に対しての組織ポリシー管理者ロールをサービスアカウントに付与
gcloud organizations add-iam-policy-binding ${ORG_ID} \
    --role=roles/orgpolicy.policyAdmin \
    --condition=None \
    --member="serviceAccount:${SA_EMAIL}"

マニフェストファイルの作成

Cloud Shell 環境に org_policy.yaml という名前のファイルを作成し、以下のコードを記入。尚、${ORG_ID} 部分は組織 ID に置き換えて入力して下さい。

apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: ResourceManagerPolicy
metadata:
  name: resourcemanagerpolicy-sample-org
spec:
  organizationRef:
    external: ${ORG_ID}
  constraint: "constraints/iam.disableServiceAccountCreation"
  booleanPolicy:
    enforced: true

以下に、マニフェストファイルの説明を記載します。

apiVersion や kind フィールドで作成対象となるリソースを指定します。今回は組織ポリシーを作成したいので、apiVersion に resourcemanager.cnrm.cloud.google.com/v1beta1 に kind に ResourceManagerPolicy を指定します。

metadata フィールドでは、リソースのメタデータを定義します。今回は name でリソースの名前を定義します。

spec フィールドでは、Kubernetes オブジェクトの理想状態を定義します。今回は、サービスアカウントの作成を禁止する組織ポリシーを、組織レベルで適用するよう記述しています。

マニフェストファイルの記述方法については、以下をご参照下さい。

参考：Config Connector resources

参考：ResourceManagerPolicy

マニフェストファイルの適用

以下のコマンドでマニフェストファイルを適用します。

kubectl apply -f org_policy.yaml

リソースのステータスを確認します。

KIND={マニフェストの kind で定義したリソースの種類を入力}
NAME={マニフェストの metadata.name で定義したリソースの名前を入力}

kubectl get ${KIND} ${NAME}

以下のように、STATUS のイベントタイプが UpToDate となっていれば成功です。

NAME                               AGE   READY   STATUS     STATUS AGE
resourcemanagerpolicy-sample-org   33m   True    UpToDate   33m

参考：Config Connector 固有のイベント

動作確認

コンソールから [IAM と管理] > [組織ポリシー] を選択し、フィルタに [constraints/iam.disableServiceAccountCreation] を入力すると対象のポリシーがソートされます。

Config Controller のリソースとして定義したため、組織ポリシーのステータスが適用になっていることがわかります。

次に、この組織ポリシーのステータスを手動で [未適用] に変更し保存します。

Config Connector は、平均 10 分間隔で各リソースを調整するためしばらく待機した後、再度組織ポリシーを確認してみます。

自動修復されていることが確認できました。

クリーンアップ

組織ポリシーリソースを削除

kubectl delete -f org_policy.yaml

Config Controller を削除

gcloud anthos config controller delete \
    --location=${LOCATION} ${CONFIG_CONTROLLER_NAME}