このページでは、Binary Authorization が有効になっている GKE クラスタ(Google Cloud または Google Distributed Cloud 上)にコンテナ イメージをデプロイする方法について説明します。イメージのデプロイに使用する kubectl
コマンドは、Binary Authorization を使用しないクラスタにイメージをデプロイする場合と同じです。
始める前に
プロジェクトで Binary Authorization API が有効になっていることと、Binary Authorization が有効になっている GKE クラスタがあることを確認します。Google Kubernetes Engine での設定または Distributed Cloud での設定をご覧ください。
GKE を操作するために kubectl
をインストールします。
kubectl
を構成する
kubectl
のインストール用にローカルの kubeconfig
ファイルを更新する必要があります。これにより、GKE または Distributed Cloud でクラスタにアクセスするために必要な認証情報とエンドポイント情報が提供されます。
kubectl
を構成するには、次の gcloud
コマンドを実行します。
GKE
gcloud container clusters get-credentials \ --zone ZONE \ CLUSTER_NAME
次のように置き換えます。
- ZONE: クラスタが実行されている GKE ゾーンの名前(例:
us-central1-a
) - CLUSTER_NAME: クラスタの名前。
Distributed Cloud
gcloud container fleet memberships get-credentials \ --location LOCATION \ MEMBERSHIP_NAME
次のように置き換えます。
- LOCATION: GKE クラスタのフリート メンバーシップの場所(たとえば、
global
) - MEMBERSHIP_NAME: GKE クラスタのフリート メンバーシップの名前
コンテナ イメージをデプロイする
次のようにコンテナ イメージをデプロイします。
環境変数を構成します。
POD_NAME=POD_NAME IMAGE_PATH=IMAGE_PATH IMAGE_DIGEST=IMAGE_DIGEST
次のように置き換えます。
- POD_NAME: GKE ワークロードに使用する名前。
- IMAGE_PATH: Artifact Registry、Container Registry、または別のレジストリ内のイメージのパス。
IMAGE_DIGEST: イメージ マニフェストのダイジェスト。次に例を示します。
- Artifact Registry:
- パス:
us-docker.pkg.dev/google-samples/containers/gke/hello-app
- ダイジェスト:
sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
- パス:
- Container Registry:
- パス:
gcr.io/google-samples/hello-app
- ダイジェスト:
sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
- パス:
Artifact Registry 内のイメージのダイジェストを取得する方法については、イメージの管理をご覧ください。Container Registry のイメージの場合は、イメージのバージョンの一覧表示をご覧ください。
- Artifact Registry:
kubectl run
コマンドを使用してイメージをデプロイします。Binary Authorization はダイジェストを使用して証明書を検索するため、
1.0
やlatest
などのタグではなく、ダイジェストを使用してイメージをデプロイする必要があります。イメージをデプロイするには、次の
kubectl
コマンドを実行します。kubectl run ${POD_NAME} \ --image ${IMAGE_PATH}@${IMAGE_DIGEST}
次に、Binary Authorization でデプロイがブロックされたことを確認します。
kubectl get pods
一覧表示された Pod を確認します。
フェイル オープン
なんらかの理由で GKE が Binary Authorization サーバーにアクセスできない場合や、サーバーがエラーを返した場合、GKE は、Binary Authorization がイメージを許可するかどうか判断できません。この場合、GKE はフェイル オープンします。デフォルトではイメージのデプロイを許可しますが、Cloud Audit Logs にログエントリを作成し、イメージが許可された理由を記録します。
信頼性とセキュリティのトレードオフにより、GKE の適用はフェイル オープンになります。GKE は、Pod が作成または更新されるたびに Binary Authorization にリクエストを送信します。これには、Pod が ReplicaSet や StatefulSet などの上位レベルの Kubernetes ワークロード コントローラによって自動的に作成または更新されるシナリオが含まれます。GKE がフェイル オープンではなくフェイル クローズした場合、Binary Authorization の停止により、これらの Pod の実行が停止します。さらに、Pod が拒否されると、リダイレクトされたトラフィックにより、実行中の Pod が過負荷状態にあるため、フェイルオーバーによりカスケード障害が発生する可能性があります。Binary Authorization が停止すると、新しいイメージをデプロイしなくても、クラスタが完全に停止する可能性があります。
ポリシーに違反するイメージをデプロイする
Binary Authorization では、ポリシーに違反する場合でもイメージをデプロイできるブレークグラスという機能がサポートされています。
詳しくは、ブレークグラスの使用をご覧ください。
クリーンアップ
クリーンアップするには、次のコマンドを実行して Pod を削除します。
kubectl delete pod ${POD_NAME}
次のステップ
- ドライラン モードについて確認する。
- CV の使用方法を確認する。
- 以前の継続的検証を使用する(非推奨)方法を確認する。
- Kubernetes マニフェストでイメージ ダイジェストを使用する方法を確認する。