CI パイプラインでの Policy Controller の使用

このページでは、Git リポジトリと同期されたポリシー検証を確認する継続的インテグレーション(CI)パイプラインを作成して、Policy Controller を Cloud Build と統合する方法について説明します。

デベロッパーが会社のポリシーに照らしてアプリを検証する場合は、継続的インテグレーション パイプラインにおける会社のポリシーに対するアプリの検証をご覧ください。

はじめに

Policy Controller を使用して CI パイプラインを作成すると、次のことが可能になります。

  • 定義されたポリシー構成を適用し、開発者にできるだけ早くフィードバックを提供します。ポリシーにより、プラットフォーム管理者はアクセスをロックダウンできます。その場合、開発チームは、それらのポリシーを削除または回避するのではなく、これらのポリシーを遵守する必要があります。

  • 常に存在する必要がある Kubernetes オブジェクトのデフォルト フィールドを設定します。たとえば、所有者やコストセンターのラベルを自動的に追加できます。

このページでは、GitHub 構成リポジトリを使用した Cloud Build CI パイプラインに重点を置いています。同じパターンを使用して、Anthos Config Management でサポートされている他の CI ツールまたはバージョン管理システムをセットアップできます。

このパイプラインは KPT 関数で構築されています。KPT 関数を使用すると、クライアント側のコンテナ イメージを開発して、Kubernetes 構成を検証、変換、生成できます。

このトピックでは、KPT 関数カタログから事前に作成された KPT 関数を使用します。カタログ内の関数のサブセットは、Google がサポートする Container Registry にミラーリングされており、すべてのプロジェクトで利用可能です。

始める前に

  • Anthos Config Management を使用して Policy Controller をインストールするには、Anthos の使用権が必要です。

  • Config Sync がすでにインストールされているクラスタが必要です。

  • Policy Controller を設定します。

  • Google Cloud プロジェクトに対する serviceusage.services.enable 権限と、Cloud Build API に対する servicemanagement.services.bind 権限を持ちます。これらの権限は、Cloud Build サービス アカウントを有効にするために必要です。詳細については、API を有効にするをご覧ください。

  • プロジェクトで Cloud Build を有効にします。これは、Google Cloud Console を使用して操作できます。

非構造化リポジトリの使用

このチュートリアルには、非構造化リポジトリを使用するオプションが含まれています。非構造化リポジトリでは、デフォルトの Anthos Config Management ディレクトリ構造は必要ありません。

Cloud Build の構成

パイプラインを構成する各プロジェクトの Cloud Build サービス アカウントに Kubernetes Engine デベロッパーのロールを付与する必要があります。

  1. Cloud Build 設定ページを開く

    [サービス アカウントの権限] ページが表示されます。

  2. [Kubernetes Engine] を含む行を見つけ、[ステータス] を [有効] に設定します。

詳細については、サービス アカウントの権限の設定をご覧ください。

環境設定

Cloud Build と連携するように Policy Controller を構成するには、Git リポジトリの例をご覧ください。

git を使用してリポジトリのクローンを作成します。

git clone git@github.com:GoogleCloudPlatform/anthos-config-management-samples.git

階層リポジトリを使用している場合は、Cloud Build を設定してから、このリポジトリの構成ファイルを編集する必要があります。

ディレクトリ構造

リポジトリ anthos-config-management-samples には、階層リポジトリ(ci-pipeline/)用と非構造化リポジトリ(ci-pipeline-unstructured/)用の構成ファイルを含む 2 つのディレクトリがあります。クラスタタイプに適したディレクトリを選択します。

リポジトリ内の ci-pipeline/ および ci-pipeline-unstructured/ ディレクトリは、次の階層を使用します。

  • config-root/ はリポジトリのルートであり、この例のすべての構成ファイルが含まれています。

  • config-root/.../*-constraint.yaml*-template.yaml は、config-root/ のすべての構成ファイルが渡す必要がある Policy Controller の制約とテンプレートを定義します。

    例:

    • ファイル ci-pipeline/config-root/cluster/required-labels-constraint.yaml には、各名前空間に cost-center ラベルが必要です。

    • ファイル ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml は、ConfigMap オブジェクトに private-key という名前のフィールドを含まないことを強制します。

    詳細については、制約の作成をご覧ください。

  • cloudbuild.yaml は、ビルドステップを定義する Cloud Build 構成ファイルです。これらのビルドステップは、リポジトリへの commit によってトリガーされます。

    階層リポジトリを使用して、パイプラインは nomos hydrate でリポジトリの内容をビルドし、それらを連結して、Policy Controller で検証します。

    非構造化リポジトリでは、Policy Controller は nomos の使用、またはクラスタへの接続を使用せずに構成をビルドします。

    構成ファイルの内容について詳しくは、基本構成の作成をご覧ください。

Cloud Build の構成

このセクションでは、Cloud Build をソース リポジトリに接続して、Cloud Build がそのリポジトリでコードをビルドできるようにします。

ビルドトリガーの作成

Cloud Build は、commit がブランチに push されると、ビルドトリガーを実行します。Google Cloud Console でビルドトリガーを構成するには、次の手順を行います。

  1. Google Cloud Console で [トリガー] ページを開きます。

    [トリガー] ページを開く

  2. ページの上部にあるプロジェクト セレクタのプルダウン メニューからプロジェクトを選択します。

  3. [開く] をクリックします。

  4. [トリガーを作成] をクリックします。

  5. トリガーの名前を作成します。

  6. [イベント] で [ブランチに push する] を選択します。

  7. [リポジトリ] を選択します。リポジトリに接続していない場合は、次の手順を行います。

    1. [リポジトリを接続] をクリックします。

    2. ソースコードを保存したリポジトリを選択します。

      ソース リポジトリとして [GitHub(ミラーリング済み)] または [Bitbucket(ミラーリング済み)] を選択すると、Cloud Build は Cloud Source Repositories でリポジトリをミラーリングし、ミラーリングされたリポジトリを使用します。

    3. [続行] をクリックします。

    4. ユーザー名とパスワードを使用して、ソース リポジトリに対する認証を行います。

    5. 使用可能なリポジトリのリストからリポジトリを選択して、[リポジトリを接続] をクリックします。

  8. 使用可能なリポジトリのリストから、リポジトリ anthos-config-management-samples を選択します。

  9. ブランチmaster を選択します。

  10. [ビルド構成] の下で、[Cloud ビルド構成ファイル] を ci-pipeline/cloudbuild.yaml または ci-pipeline-unstructured/cloudbuild.yaml に設定します。

  11. [作成] をクリックして、ビルドトリガーを保存します。

gcloud を使用してビルドトリガーを作成することもできます。詳細については、ビルドトリガーの作成と管理をご覧ください。

リポジトリを構成する

Cloud Build がリポジトリに接続するように構成されたら、Anthos Config Management の構成を完了します。

  1. ファイル anthos-config-management-samples/CODEOWNERS を編集して、@OWNERGitHub のユーザー名またはプラットフォーム管理チームのメール エイリアスに置き換えます。CODEOWNERS 構文の詳細については、codeowners についてをご覧ください。

以下の階層リポジトリ(デフォルト)と非構造化リポジトリのどちらを使用するかを選択します。

  1. 構成ファイルを編集します。

    階層

    anthos-config-management-samples/ci-pipeline/cloudbuild.yaml ファイルを編集します。

    CLUSTER_NAMEZONE を、Anthos Config Management と Policy Controller がインストールされている GKE クラスタのクラスタ名とゾーンに置き換えます。

    非構造化

    この例では、非構造化リポジトリの構成を変更する必要はありません。Anthos Config Management と Policy Controller は、クラスタに接続せずにリポジトリを検証します。

  2. 変更をリポジトリに追加して commit します。

    階層

    cd ci-pipeline
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    非構造化

    cd ci-pipeline-unstructured
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    commit 後、Cloud Build はリポジトリでポリシー検証を行います。

  3. [Cloud Build の履歴] を開き、最新の [ビルド] をクリックします。

    [ビルドの詳細] ページが表示されます。

  4. anthos-config-management-samples リポジトリのサンプルにエラーが含まれています。

    リストの一番上から、 アイコンを含む最新のビルドを選択します。

  5. Cloud Build が実行する最後のステップがエラーで終了します。エラーは以下のとおりです。

    階層

    Error: Found 1 violations:
    [1] All namespaces must have a cost-center label that points to your division
    name: "shipping-prod"
    path: namespace_shipping-prod.yaml

    非構造化

    Step #2: Error: Found 1 violations:
    [1] The following banned keys are being used in the config map: {"private_key"}
    name: "super-secret"
    path: configmap.yaml

  6. 次に、リポジトリ内のファイルを編集してエラーを修正します。

    階層

    ファイル /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml を編集して、metadata.labels.cost-center の値を設定します。namespace.yaml は次のようになります。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: shipping-prod
      labels:
        env: prod
        cost-center: "shipping.foo-corp.com"
      annotations:
        audit: "true"
    

    非構造化

    /ci-pipeline-unstructured/config-root/configmap.yaml ファイルを編集します。data.private_key という名前のフィールドを data.public_key に変更します。編集した YAML は次のようになります。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: super-secret
      namespace: default
    data:
      public_key: no secrets here
    

    次に、変更を commit して push します。

    git add .
    git commit -m "[COMMIT_MESSAGE]"
    git push origin [BRANCH]
  7. [Cloud Build の履歴] を開き、最新の [ビルド] をクリックします。

    [ビルドの詳細] ページが表示されます。

  8. 新しいビルドは成功するはずです。

トラブルシューティング

問題: Cloud Build ビルドが失敗し、履歴に次のエラーが含まれています。

  [1] KNV1021: No CustomResourceDefinition is defined for the type "ConstraintTemplate.templates.gatekeeper.sh" in the cluster.
  Resource types that are not native Kubernetes objects must have a CustomResourceDefinition.

解決策: Policy Controller のインストールを確認してください。

次のステップ