シンプルな署名証明書チェックを使用する

このページでは、Binary Authorization の継続的検証(CV)のシンプルな署名証明書チェックを使用する方法について説明します。このチェックでは、CV が有効になっている Google Kubernetes Engine(GKE)クラスタで実行されている Pod に関連付けられたコンテナ イメージの証明書を検証します。

費用

このガイドでは、次の Google Cloud サービスを使用します。

  • Binary Authorization。ただし、CV はプレビュー ステージの間は無料です。
  • GKE
  • Cloud Key Management Service

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

始める前に

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
  12. gcloud CLI が最新バージョンであることを確認します。
  13. kubectl コマンドライン ツールをインストールします
  14. Binary Authorization ポリシーと GKE クラスタが別々のプロジェクトにある場合は、両方のプロジェクトで Binary Authorization が有効になっていることを確認します。

必要なロール

このセクションでは、このチェックに必要なロールの設定方法について説明します。

概要

このガイドに記載されているプロダクトをすべて同じプロジェクトで実行する場合、権限を設定する必要はありません。Binary Authorization を有効にすると、ロールが正しく構成されます。複数のプロジェクトでプロダクトを実行する場合は、このセクションの説明に従ってロールを設定する必要があります。

各プロジェクトの Binary Authorization サービス エージェントに CV のシンプルな署名証明書チェックの評価に必要な権限を付与するには、各プロジェクトの Binary Authorization サービス エージェントに次の IAM ロールを付与するよう管理者に依頼します。

  • クラスタ プロジェクトがポリシー プロジェクトと異なる場合: ポリシー プロジェクトにアクセスするために、クラスタ プロジェクトの Binary Authorization サービス エージェントに Binary Authorization ポリシー評価者roles/binaryauthorization.policyEvaluator)ロールが必要です。
  • 証明書プロジェクトがポリシー プロジェクトと異なる場合: 証明書プロジェクトにアクセスするため、ポリシー プロジェクトの Binary Authorization サービス エージェントに Container Analysis のオカレンスの閲覧者roles/containeranalysis.occurrences.viewer)ロールが必要です。

ロールの付与の詳細については、アクセス権の管理をご覧ください。

管理者は、カスタムロールや他の事前定義ロールを使用して、各プロジェクトの Binary Authorization サービス エージェントに必要な権限を割り当てることもできます。

gcloud CLI を使用してロールを付与する

各プロジェクトの Binary Authorization サービス エージェントに CV のシンプルな署名証明書チェックの評価に必要な権限を付与するには、各プロジェクトの Binary Authorization サービス エージェントに次の IAM ロールを付与します。

  1. クラスタ プロジェクトのポリシーにアクセスするための権限をクラスタ プロジェクトの Binary Authorization サービス エージェントに付与します。

    1. クラスタ プロジェクトの Binary Authorization サービス エージェントを取得します。

      PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      CLUSTER_PROJECT_ID は、クラスタのプロジェクト ID に置き換えます。

    2. CV にクラスタのポリシーの評価を許可します。

      gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
          --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
          --role='roles/binaryauthorization.policyEvaluator'
      

      POLICY_PROJECT_ID は、ポリシーを含むプロジェクトの ID に置き換えます。

  2. ポリシー プロジェクトの Binary Authorization サービス エージェントに、証明書プロジェクト内の証明書へのアクセスを許可します。

    1. ポリシー プロジェクトの Binary Authorization サービス エージェントを取得します。

      PROJECT_NUMBER=$(gcloud projects list \
        --filter="projectId:POLICY_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
      

      POLICY_PROJECT_ID は、ポリシーを含むプロジェクトの ID に置き換えます。

    2. ロールを付与します。

      gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \
          --member="serviceAccount:$SERVICE_ACCOUNT" \
          --role='roles/containeranalysis.occurrences.viewer'
      

      ATTESTATION_PROJECT_ID は、証明書を含むプロジェクトの ID に置き換えます。

鍵ペアを作成する

このセクションでは、楕円曲線デジタル署名アルゴリズム(ECDSA)の非対称鍵ペアを作成します。

秘密鍵を使用してイメージに署名します。これにより、証明書が作成されます。公開鍵は、プラットフォーム ポリシーに含まれています。CV は証明書を確認するときに、公開鍵を使用して証明書を検証します。

Cloud Key Management Service またはローカル鍵のいずれかを使用できますが、本番環境には Cloud KMS 鍵を使用することをおすすめします。

PKIX Cloud KMS

Cloud KMS で鍵ペアを作成する手順は次のとおりです。

  1. 鍵ペアの作成に必要な環境変数を設定します。これを行うには、次のプレースホルダを入力して、コマンドを実行することをおすすめします。

    KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
    KMS_KEYRING_NAME=KMS_KEYRING_NAME
    KMS_KEY_NAME=KMS_KEY_NAME
    KMS_KEY_LOCATION=global
    KMS_KEY_PURPOSE=asymmetric-signing
    KMS_KEY_ALGORITHM=ec-sign-p256-sha256
    KMS_PROTECTION_LEVEL=software
    KMS_KEY_VERSION=1
    KEY_FILE=KEY_FILE
    

    次のように置き換えます。

    • KMS_KEY_PROJECT_ID: プロジェクト ID
    • KMS_KEYRING_NAME: Cloud KMS キーリングの名前
    • KMS_KEY_NAME: Cloud KMS 鍵の名前
    • KEY_FILE: Cloud KMS 鍵を保存するローカルパス
  2. キーリングを作成します。

    gcloud kms keyrings create ${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --project=${KMS_KEY_PROJECT_ID}
    
  3. 鍵を作成します。

    gcloud kms keys create ${KMS_KEY_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --keyring=${KMS_KEYRING_NAME}  \
        --purpose=${KMS_KEY_PURPOSE} \
        --default-algorithm=${KMS_KEY_ALGORITHM} \
        --protection-level=${KMS_PROTECTION_LEVEL} \
        --project=${KMS_KEY_PROJECT_ID}
    
  4. 公開鍵マテリアルをファイルにエクスポートします。

    gcloud kms keys versions get-public-key ${KMS_KEY_VERSION} \
        --key=${KMS_KEY_NAME} \
        --keyring=${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --output-file=${KEY_FILE} \
        --project=${KMS_KEY_PROJECT_ID}
    

ローカル鍵

鍵ペアをローカルで作成する手順は次のとおりです。

  1. 秘密鍵を作成します。

    PRIVATE_KEY_FILE="/tmp/ec_private.pem"
    openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
    
  2. 秘密鍵から公開鍵を取得します。

    PUBLIC_KEY_FILE="/tmp/ec_public.pem"
    openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
    

プラットフォーム ポリシーを作成する

シンプルな署名証明書チェックを使用して CV プラットフォーム ポリシーを作成するには、次の操作を行います。

  1. シンプルな署名証明書チェックのプラットフォーム ポリシーの YAML ファイルを作成します。

    PKIX Cloud KMS

    cat > /tmp/my-policy.yaml << EOF
    gkePolicy:
      checkSets:
      - checks:
        - simpleSigningAttestationCheck:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
            attestationAuthenticators:
              pkixPublicKeySet:
                pkixPublicKeys:
                  publicKeyPem: |
    $(awk '{printf "                %s\n", $0}' ${KEY_FILE})
                  signatureAlgorithm: ECDSA_P256_SHA256
                  keyId: |
                    projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}/cryptoKeyVersions/${KMS_KEY_VERSION}
    EOF
    

    ATTESTATION_PROJECT_ID は、この Cloud KMS 鍵を使用して作成された証明書を保存するプロジェクトの ID に置き換えます。

    ローカル鍵

    cat > /tmp/my-policy.yaml <<EOF
    gkePolicy:
      checkSets:
      - checks:
        - simpleSigningAttestationCheck:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
            attestationAuthenticators:
              pkixPublicKeySet:
                pkixPublicKeys:
                  publicKeyPem: |
    $(awk '{printf "                %s\n", $0}' /tmp/ec_public.pem)
                  signatureAlgorithm: ECDSA_P256_SHA256
                  keyId: |
                    PUBLIC_KEY_ID
    EOF
    

    次のように置き換えます。

    • ATTESTATION_PROJECT_ID: ローカル鍵を使用して作成された証明書を保存するプロジェクトの ID
    • PUBLIC_KEY_ID: ローカル鍵を一意に識別する ID
  2. プラットフォーム ポリシーを作成します。

    後述のコマンドデータを使用する前に、次のように置き換えます。

    • POLICY_ID: 選択したプラットフォーム ポリシー ID。ポリシーが別のプロジェクトにある場合、完全なリソース名 projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID を使用できます。
    • POLICY_PATH: ポリシー ファイルのパス。
    • POLICY_PROJECT_ID: ポリシー プロジェクト ID。

    次のコマンドを実行します。

    Linux、macOS、Cloud Shell

    gcloud beta container binauthz policy create POLICY_ID \
        --platform=gke \
        --policy-file=POLICY_PATH \
        --project=POLICY_PROJECT_ID
    

    Windows(PowerShell)

    gcloud beta container binauthz policy create POLICY_ID `
        --platform=gke `
        --policy-file=POLICY_PATH `
        --project=POLICY_PROJECT_ID
    

    Windows(cmd.exe)

    gcloud beta container binauthz policy create POLICY_ID ^
        --platform=gke ^
        --policy-file=POLICY_PATH ^
        --project=POLICY_PROJECT_ID
    

  3. 後で使用するために ID 値を保存します。

    PUBLIC_KEY_ID="PUBLIC_KEY_ID"
    

    PUBLIC_KEY_ID は、このガイドの前半でプラットフォーム ポリシー ファイルの keyId フィールドで指定した ID に置き換えます。

    秘密鍵は、このガイドで後述するように、証明書の作成時に使用されます。

CV を有効にする

チェックベースのプラットフォーム ポリシーで CV モニタリングを使用するように、新しいクラスタを作成するか、既存のクラスタを更新します。

CV モニタリングを使用するクラスタを作成する

このセクションでは、チェックベースのプラットフォーム ポリシーで CV モニタリングのみを使用するクラスタを作成します。

後述のコマンドデータを使用する前に、次のように置き換えます。

  • CLUSTER_NAME: クラスタ名。
  • LOCATION: ロケーション。例: us-central1asia-south1
  • POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID。
  • POLICY_ID: ポリシー ID。
  • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID。

次のコマンドを実行します。

Linux、macOS、Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows(PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows(cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

適用と CV モニタリングを使用するクラスタを作成する

このセクションでは、プロジェクト シングルトン ポリシーの適用と、チェックベースのプラットフォーム ポリシーを使用した CV モニタリングの両方を使用するクラスタを作成します。

後述のコマンドデータを使用する前に、次のように置き換えます。

  • CLUSTER_NAME: クラスタ名。
  • LOCATION: ロケーション。例: us-central1asia-south1
  • POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID。
  • POLICY_ID: ポリシー ID。
  • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID。

次のコマンドを実行します。

Linux、macOS、Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows(PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows(cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

CV モニタリングを使用するようにクラスタを更新する

このセクションでは、チェックベースのプラットフォーム ポリシーでのみ CV モニタリングを使用するようにクラスタを更新します。クラスタでプロジェクトのシングルトン ポリシーの適用がすでに有効になっている場合、このコマンドを実行すると、クラスタの適用が無効になります。代わりに、適用と CV モニタリングを有効にしてクラスタを更新することを検討してください。

後述のコマンドデータを使用する前に、次のように置き換えます。

  • CLUSTER_NAME: クラスタ名
  • LOCATION: ロケーション(例: us-central1asia-south1
  • POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID
  • POLICY_ID: ポリシー ID
  • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

次のコマンドを実行します。

Linux、macOS、Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows(PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows(cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

適用と CV モニタリングを使用するようにクラスタを更新する

このセクションでは、チェックベースのプラットフォーム ポリシーを使用して、プロジェクト シングルトン ポリシーの適用と CV モニタリングの両方を使用するようにクラスタを更新します。

後述のコマンドデータを使用する前に、次のように置き換えます。

  • CLUSTER_NAME: クラスタ名
  • LOCATION: ロケーション(例: us-central1asia-south1
  • POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID
  • POLICY_ID: ポリシー ID
  • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

次のコマンドを実行します。

Linux、macOS、Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows(PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows(cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Artifact Analysis メモを作成する

このセクションでは、証明書をリンクするサンプルの Artifact Analysis メモを作成します。メモを作成する手順は次のとおりです。

  1. メモの変数を作成します。

    NOTE_PROJECT_ID=NOTE_PROJECT_ID
    NOTE_ID="test-note"
    NOTE_URI="projects/${NOTE_PROJECT_ID}/notes/${NOTE_ID}"
    DESCRIPTION="CV test note"
    

    NOTE_PROJECT_ID は、メモを含むプロジェクトの ID に置き換えます。

  2. メモのコンテンツ ファイルを作成します。

    cat > /tmp/note_payload.json << EOM
    {
      "name": "${NOTE_URI}",
      "attestation": {
        "hint": {
          "human_readable_name": "${DESCRIPTION}"
        }
      }
    }
    EOM
    
  3. メモを作成します。

    curl -X POST \
        -H "Content-Type: application/json" \
        -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
        -H "x-goog-user-project: ${NOTE_PROJECT_ID}" \
        --data-binary @/tmp/note_payload.json "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/notes/?noteId=${NOTE_ID}"
    

    NOTE_PROJECT_ID は、メモを含むプロジェクトの ID に置き換えます。

  4. 省略可: メモが作成されたことを確認するには:

    curl \
        -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
        -H "x-goog-user-project: NOTE_PROJECT_ID" \
    "https://containeranalysis.googleapis.com/v1/projects/NOTE_PROJECT_ID/notes/"
    

    NOTE_PROJECT_ID は、メモを含むプロジェクトの ID に置き換えます。

CV をテストする

このセクションでは、証明書を作成したイメージをデプロイして CV をテストします。この場合、CV のシンプルな署名証明書チェックで証明書が検証され、ログエントリは生成されません。

次に、証明書のない別のイメージをデプロイします。この場合、CV チェックで証明書が検出されないため、違反が Cloud Logging に記録されます。

CV のテストに使用する変数を作成するには、次のコマンドを実行します。

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST="${IMAGE_PATH}@${IMAGE_DIGEST}"

証明書を作成する

シンプルな署名証明書チェックを行うには、イメージに有効な証明書が必要です。

証明書は、gcloud CLI または REST API で作成できます。

PKIX Cloud KMS

gcloud

gcloud CLI を使用して証明書を作成するには、次の操作を行います。

  1. イメージに署名し、事前認証のエンコード(PAE)を使用して証明書を作成します(推奨)。

    gcloud beta container binauthz attestations sign-and-create \
        --artifact-url=${IMAGE_TO_ATTEST} \
        --keyversion=${KMS_KEY_VERSION} \
        --keyversion-key=${KMS_KEY_NAME} \
        --keyversion-keyring=${KMS_KEYRING_NAME} \
        --keyversion-location=${KMS_KEY_LOCATION} \
        --note=${NOTE_URI} \
        --pae-encode-payload \
        --dsse-type=DSSE_TYPE
    

    DSSE_TYPE は、PAE エンコードの DSSE タイプに置き換えます。このフラグのデフォルトは application/vnd.dev.cosign.simplesigning.v1+json です。

REST API

REST API を使用して証明書を作成するには、次の操作を行います。

  1. 署名ペイロード ファイルを作成します。

    cat > /tmp/generated_payload.json << EOM
    {
      "critical": {
        "identity": {
          "docker-reference": "${IMAGE_PATH}"
        },
        "image": {
          "docker-manifest-digest": "${IMAGE_DIGEST}"
        },
        "type": "Google Cloud BinAuthz container signature"
      }
    }
    EOM
    
  2. ペイロードに署名します。

    gcloud kms asymmetric-sign \
        --version=${KMS_KEY_VERSION} \
        --key=${KMS_KEY_NAME} \
        --keyring=${KMS_KEYRING_NAME} \
        --location=${KMS_KEY_LOCATION} \
        --digest-algorithm=sha256 \
        --input-file=/tmp/generated_payload.json \
        --signature-file=/tmp/ec_signature \
        --project=${KMS_KEY_PROJECT_ID}
    
  3. 証明書の内容を作成します。

    cat > /tmp/attestation.json << EOM
    {
    "resourceUri": "${IMAGE_TO_ATTEST}",
    "note_name": "${NOTE_URI}",
    "attestation": {
      "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
      "signatures": [{
        "public_key_id": "${PUBLIC_KEY_ID}",
        "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
      }]
    }
    }
    EOM
    
  4. 証明書を作成します。

    curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
      -H "Content-Type: application/json" \
      -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      --data-binary @/tmp/attestation.json
    

    NOTE_PROJECT_ID は、メモを含むプロジェクトの ID に置き換えます。

ローカル鍵

gcloud

  1. 署名ペイロード ファイルを作成します。

    cat > /tmp/generated_payload.json << EOM
    {
      "critical": {
        "identity": {
          "docker-reference": "${IMAGE_PATH}"
        },
        "image": {
          "docker-manifest-digest": "${IMAGE_DIGEST}"
        },
        "type": "Google Cloud BinAuthz container signature"
      }
    }
    EOM
    
  2. 署名ペイロード ファイルを作成します。

    openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
    
  3. 証明書を作成します。

    gcloud container binauthz attestations create \
        --project=ATTESTATION_PROJECT_ID \
        --artifact-url=${IMAGE_TO_ATTEST} \
        --note=${NOTE_URI} \
        --signature-file=/tmp/ec_signature \
        --public-key-id=PUBLIC_KEY_ID
    

REST API

  1. 署名ペイロード ファイルを作成します。

    cat > /tmp/generated_payload.json << EOM
    {
      "critical": {
        "identity": {
          "docker-reference": "${IMAGE_PATH}"
        },
        "image": {
          "docker-manifest-digest": "${IMAGE_DIGEST}"
        },
        "type": "Google Cloud BinAuthz container signature"
      }
    }
    EOM
    
  2. 署名ペイロード ファイルを作成します。

    openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
    
  3. 証明書の内容を作成します。

    cat > /tmp/attestation.json << EOM
    {
    "resourceUri": "${IMAGE_TO_ATTEST}",
    "note_name": "${NOTE_URI}",
    "attestation": {
      "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
      "signatures": [{
        "public_key_id": "${PUBLIC_KEY_ID}",
        "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
      }]
    }
    }
    EOM
    
  4. 証明書を作成します。

    curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
      -H "Content-Type: application/json" \
      -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
      -H "Authorization: Bearer $(gcloud auth print-access-token)" \
      --data-binary @/tmp/attestation.json
    

証明書を含むイメージをデプロイする

証明書が作成されていないイメージをデプロイするには、次の操作を行います。

  1. kubectl を構成します。

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=LOCATION \
        --project=CLUSTER_PROJECT_ID
    

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前
    • LOCATION: クラスタのロケーション
    • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID
  2. サービスをデプロイして、Binary Authorization ポリシーとデプロイを確認します。

    kubectl run hello-app-with-attestation --image=$IMAGE_PATH@$IMAGE_DIGEST
    

    Pod がデプロイされました。イメージに証明書があるため、CV はこの Pod に関連するログエントリを生成しません。

証明書なしでイメージをデプロイする

このセクションでは、証明書が関連付けられていないイメージをデプロイします。

ポリシーでは証明書が必須になっていますが、このイメージには証明書がないため、CV はコンテナの実行中に定期的に違反を記録します。

イメージをデプロイするには、次のコマンドを実行します。

kubectl run hello-app-without-attestation \
    --image=gcr.io/google-samples/hello-app@sha256:845f77fab71033404f4cfceaa1ddb27b70c3551ceb22a5e7f4498cdda6c9daea

Pod がデプロイされました。イメージに証明書がないため、CV は Pod の実行中にログエントリを生成します。

CV エントリのログを表示する

Cloud Logging のエントリを検索して、CV 構成エラーCV プラットフォーム ポリシーの検証違反を確認できます。

CV は、エラーと違反を 24 時間以内に Cloud Logging に記録します。通常は数時間以内にエントリを確認できます。

CV 構成エラーログを表示する

CV 構成エラーログを表示するには、次のコマンドを実行します。

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'

次の出力は、CV プラットフォーム ポリシーが見つからない構成エラーを示しています。

{
  "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
    "configErrorEvent": {
      "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
    }
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "cluster_name": "my-cluster",
      "location": "us-central1-c",
      "project_id": "my-project"
    }
  },
  "timestamp": "2024-05-28T15:31:03.999566Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}

CV プラットフォーム ポリシーの検証違反を表示する

有効にしたプラットフォーム ポリシーに違反するイメージがない場合、ログエントリは表示されません。

過去 7 日間の CV ログエントリを表示するには、次のコマンドを実行します。

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

CLUSTER_PROJECT_ID は、クラスタ プロジェクト ID に置き換えます。

チェックの種類

CV では、チェックの違反情報が checkResults に記録されます。エントリで、値 checkType はチェックを示します。各チェックの値は次のとおりです。

  • ImageFreshnessCheck
  • SigstoreSignatureCheck
  • SimpleSigningAttestationCheck
  • SlsaCheck
  • TrustedDirectoryCheck
  • VulnerabilityCheck

サンプルログ

次の CV ロギング エントリの例は、信頼できるディレクトリ チェックに違反する非遵守のイメージを示しています。

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

クリーンアップ

このセクションでは、このガイドの前半で構成した CV モニタリングをクリーンアップする方法について説明します。

クラスタで CV モニタリングを無効にするか、Binary Authorization と CV の両方を無効にできます。

クラスタで Binary Authorization を無効にする

クラスタで CV と Binary Authorization の両方を無効にするには、次のコマンドを実行します。

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前
  • LOCATION: クラスタのロケーション
  • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

クラスタでチェックベースのポリシー モニタリングを無効にする

クラスタでチェックベースのポリシーを使用して CV を無効にし、Binary Authorization 適用ポリシーを使用して適用を再度有効にするには、次のコマンドを実行します。

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前
  • LOCATION: クラスタのロケーション
  • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE は、古いフラグ --enable-binauthz と同じです。

ポリシーを削除する

ポリシーを削除するには、次のコマンドを実行します。チェックベースのポリシー監査を無効にするために、チェックベースのプラットフォーム ポリシーを削除する必要はありません。

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

次のように置き換えます。

  • POLICY_ID: ポリシーの ID
  • POLICY_PROJECT_ID: ポリシー プロジェクト ID

次のステップ