Google Cloud Binary Authorization 徹底調査

Ryo Tozawa

2022.10.27

Binary Authorization とは

概要

コンテナベースのアプリケーションに ソフトウェアサプライチェーンのセキュリティを提供する Google Cloud のサービスです。

補足

目的

  • 信頼できるコンテナイメージのみをデプロイしたい

アプローチ

基本機能

  • パイプライン (Cloud Build)
    コンテナイメージのビルドが終わったタイミングで証明書を作成します。
  • コンテナ基盤
    Binary Authorization のポリシーに基づいて、証明書を検証します。

+α

  • パイプライン (Cloud Build)
    コンテナイメージのビルドが終わり コンテナイメージスキャン (ContainerAnalysis) の結果をもとに、証明書を作成します。
    「脆弱性の検証」と「証明書の作成」は、grafeas/kritis というツールが担っていて Shopify/voucher というのも同じことをやってくれるそうです。
  • コンテナ基盤
    先と同様です。

仕組みを整理

パイプライン編

フロー

  • (1) イメージビルド
  • (2) イメージプッシュ (Artifact Registry のみ対応)
  • (3) イメージスキャン (Artifact Registry の Container Analysis にてイメージスキャン)
  • (4) 結果ポーリング
  • (5) 証明書作成

パイプラインのサンプル (cloudbuild.yaml)

timeout: 3600s
steps:
# build と push 省略
  - name: gcr.io/$PROJECT_ID/kritis-signer
    entrypoint: /bin/bash
    args:
      - '-e'
      - '-c'
      - >-
        echo gcr.io/$PROJECT_ID/kritis-signer &&
        /bin/cat image-digest.txt &&
        /kritis/signer -mode check-and-sign -image $(/bin/cat image-digest.txt) -policy infrastructure/gcp/cloudbuild/binauthz/kritis-policy.yaml -vulnz_timeout 60m -kms_key_name ${_KMS_KEY_NAME} -kms_digest_alg ${_KMS_DIGEST_ALG} -note_name ${_NOTE_NAME}
waitFor: ['push']
    id: vulnsign
substitutions:
  _APPNAME: APPNAME
  _DOCKER_FILE_PATH: DOCKER_FILE_PATH
  _ARTIFACT_REGISTRY_BASE_URL: ARTIFACT_REGISTRY_BASE_URL
  _KMS_KEY_NAME: KMS_KEY_NAME
  _KMS_DIGEST_ALG: KMS_DIGEST_ALG
  _NOTE_NAME: NOTE_NAME

kritis を深掘り

/kritis/signer \
	-mode check-and-sign \
  -image $(/bin/cat image-digest.txt) \
  -policy infrastructure/gcp/cloudbuild/binauthz/kritis-policy.yaml \
  -vulnz_timeout 60m \
  -kms_key_name ${_KMS_KEY_NAME} \
  -kms_digest_alg ${_KMS_DIGEST_ALG} \
  -note_name ${_NOTE_NAME}

重要そうなコマンドフラッグ

  • mode:string
    このツール実行時の振る舞いを3種類から選択します。
    １．check-and-sign : ポリシーチェック & 署名
    ２．check-only : ポリシーチェックのみ
    ３．bypass-and-sign : 署名のみ
  • image
    証明書を作成したいコンテナイメージの指定します。
    イメージタグではなくダイジェストを指定することが注意点です。
  • vulnz_timeout
    Artifact Registry の Container Analysis の結果が出るまでポーリングする時間です。
    注意点としては、イメージサイズが大きい場合イメージスキャン（ContainerAnalysis）にも時間がかかるため、調整が必要になります (パイプライン自体のタイムアウトも考慮する必要があります)。
    ※ デフォルトは5分
    その他、コマンドフラッグ何があるか知りたい方は実装の方見てみてください
    ・addBasicFlags
    ・addCheckFlags
    ・addSignFlags

証明書作るところはどのようなロジックか
grafeas/kritis/cmd にエントリーポイント (main関数のいるところ) があります (こちら)
ここの kritis/signer から追います

フロー

１．下準備 (フラッグのパースや外部クライアントの初期化等)

２．ポリシーチェック

３．署名

(参考) kritis の Policy はこのような感じになります (フォーマットは YAML)
API 定義は こちら

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: kritis-policy
spec:
  imageVulnerabilityRequirements:
    # コンテナイメージに発見された脆弱性に対する許容度
		# ENUM: BLOCK_ALL/LOW/MEDIUM/HIGH/CRITICAL/ALLOW_ALL
    maximumFixableSeverity: CRITICAL
    # 見つかった脆弱性のうち、修正プログラムが存在しないものに対する許容範囲
		# ENUM: BLOCK_ALL/LOW/MEDIUM/HIGH/CRITICAL/ALLOW_ALL
    maximumUnfixableSeverity: ALLOW_ALL
    # フィルタにかけないCVEのリスト
    allowlistCVEs: []

コンテナ基盤編

フロー

  • Kubernetes Admission Webhook にて、マニフェスト適用時に Validation が行われる
  • Admission Controller がコンテナイメージとダイジェストをもとに、Container Analysis へ問い合わせ検査

設置できるプラットフォーム

  • GKE (Google Kubernetes Engine)
    設定は、Addon を ON にしてあげるだけです。
    クラスタ作成後でも再作成なしに設定可能で、管理コンポーネントは見えません。
    GKEの設定ドキュメント
  • Cloud Run
    GKE と同様になります。
    CloudRun設定ドキュメント
  • Anthos clusters on VMWare (Preview)
    ドキュメントでは Anthos は VMWare のみの案内ですが Admission Controller が Google API にアクセスできる環境ならどこでもできるはずです。
    ValidatingWebhookConfiguration と Controller のマニフェストを手動でデプロイする必要があります。
    マニフェストの場所
    gsutil cp gs://gke-on-prem-release/binauthz/manifest-0.2.2.yaml .
  • Anthos Service Mesh
    「おまっどうやってやるんやサービスメッシュが…」 というのが最初の感想でしたが、概要には情報はありませんでした。
    GKE 以外で ASM が使える環境が Anthos ではありますので、それ向けかもしれません。
    Anthos のバージョンとアップグレードのサポート

最後に、BinaryAuthorization の Policy を入れてあげて終了になります。

参考リンク

フロー

認証者 (Attestor) の公開鍵作成

Admission Controller が証明書の検証ために使います。
Cloud KMS で 証明書を作っている方向けへのコマンド例 (terraform でも可) 

gcloud --project="" container binauthz attestors public-keys add \
  --attestor="" \
  --keyversion-project="" \
  --keyversion-location="" \
  --keyversion-keyring="" \
  --keyversion-key="" \
  --keyversion=""

Binary Authorization Policy の読み込み (terraform でも可)

  • 読み込み：gcloud container binauthz policy export > /tmp/policy.yaml
  • 書き込み：gcloud container binauthz policy import /tmp/policy.yaml

(参考) BinaryAuthorization の Policy はこのような感じになります (フォーマットは YAML)
evaluationMode: REQUIRE_ATTESTATION にすると、証明書の検査をします。
1枚のポリシーがプロジェクト全体に適用されます。下記の 5つで範囲を絞れます。

  1. クラスタ単位
  2. デフォルト
  3. ASM (Service Identity ID)
  4. Kubernetes Service Account
  5. Kubernetes Namespace
# 用語
# Attestor: 認証者 (証明書作ったり許可したりする人)
---
# パラメータ
# defaultAdmissionRule.enforcementMode
# -> イメージがルールに違反している場合に施行者がどのように応答するか
# defaultAdmissionRule.evaluationMode
# -> デプロイ時に Binary Authorization 施行者が適用する制約のタイプ
# globalPolicyEvaluationMode
# -> Google 管理のシステムイメージを許可リストに登録するかどうか
# admissionWhitelistPatterns
# -> 特定のイメージのみ署名がなくても許可する

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: REQUIRE_ATTESTATION
  requireAttestationsBy:
    - projects/hallo-ai-pf-pjt/attestors/built-by-cloud-build
globalPolicyEvaluationMode: ENABLE
# 形式: projects/${PROJECT_ID}/policy
name: projects/hallo-ai-pf-pjt/policy 
admissionWhitelistPatterns:
  - namePattern: quay.io/argoproj/**
  - namePattern: ghcr.io/dexidp/**
  - namePattern: public.ecr.aws/docker/library/**

注意
globalPolicyEvaluationMode: true にすると、 Google 管理のコンテナイメージに対しての検査をスキップしてくれるのですが、 たまに含み忘れているものも出てきます。その場合、ホワイトリストに追加する必要があります。

まとめ

  • BinaryAuthorization を使うことで 認証・認可したイメージのみワークロードとして使うことができる
    気軽に検証イメージをデプロイできないというのもあるので、使う環境は考慮する必要がありそうでした。
    気軽にOFFにできるし、AUDIT_LOG だけ出すこともでき、許可していないものは軒並みデプロイできないので Kubernetes 管理者としては安心感もあると感じました。
  • この機能を使って、何をどこまで担保したいのかは組織ごとに決めていく必要がある
    例えば、
    ・本番環境デプロイまでのパイプラインがあり、様々なテスト(試験) をパスしたイメージだけをデプロイしたい
    ・一定以上の脅威のある脆弱性を含んだイメージをデプロイしたくない など
  • 気になる料金
    ・Cloud Run：無料
    ・Anthos：無料
    ・GKE：無料枠 ($12) / $0.016 per クラスタ
  • Container Analysis は今の所、OS Package / Go Package / Java Package の検査をしてくれる

関連記事

ShellScriptで自動化を楽にしたい時に知っておいても良いこと

nwiizo

2024.7.15

SREの中核を担うモニタリングの必要性とその戦略について理解する

nwiizo

2022.5.18

CPU Resource limit に思いを馳せてみた

Kouhei Nagase

2022.9.27

ブログ一覧へ戻る

お気軽にお問い合わせください

SREの設計・技術支援から、
SRE運用内で使用する
ツールの導入など、
SRE全般についてご支援しています。

資料請求・お問い合わせ