このドキュメントでは、Google Distributed Cloud の一部として作成されたオンプレミス クラスタの Binary Authorization を設定する方法について説明します。その後、Binary Authorization ポリシーのサンプルを構成する方法について説明します。
始める前に
クラスタにサポートされている Google Distributed Cloud バージョンがあることを確認します。Binary Authorization は次の環境をサポートしています。
ベアメタル
Google Distributed Cloud 1.14 または 1.15。バージョン 1.16 以降の場合は、クラスタの作成時または更新時に Binary Authorization を構成できます。
VMware
VMware 向け Distributed Cloud(Google Distributed Cloud)1.4 以降。
Binary Authorization サービスは、外部 IP アドレスを使用し、通常のインターネット接続を介してアクセスできます。HTTPS でユーザー クラスタがエンドポイント
binaryauthorization.googleapis.com
にアクセスできるように、ファイアウォール ルールを構成します。ベアメタル
VMware
一元化された Cloud Audit Logs を使用して監査ログエントリ(Google Cloud 外部のクラスタ用 Binary Authorization のエントリなど)を表示するには、クラスタ構成で Cloud Audit Logs を構成する必要があります。
ベアメタル
Google Distributed Cloud で Cloud Audit Logs を構成します。
VMware
Google Distributed Cloud で Cloud Audit Logs を構成します。
次のように Binary Authorization API を有効にする必要があります。
Google Cloud コンソールに移動します。
プロジェクトのプルダウン リストで、フリート ホスト プロジェクトを選択します。これは、ユーザー クラスタ構成ファイルの
gkeConnect
セクションで確認できます。これは、ユーザー クラスタを Google Cloud に接続する Google Cloud プロジェクトです。
Binary Authorization を設定する
このセクションでは、オンプレミス クラスタに Binary Authorization を設定します。
インストール環境変数を指定する
環境変数を指定する方法は次のとおりです。
Workload Identity の使用
フリート ホスト プロジェクトを指定します。
export PROJECT_ID=PROJECT_ID
フリート メンバーシップ ID をクラスタ ID に設定します。
メンバーシップ ID は、
gcloud container fleet memberships list
コマンドを実行するとNAME
列に表示されます。export MEMBERSHIP_ID=CLUSTER_NAME
サービス アカウント キーの使用
フリート ホスト プロジェクトを指定します。
export PROJECT_ID=PROJECT_ID
PROJECT_ID は、ユーザー クラスタ構成ファイルの
gkeConnect
セクションに記載されている Google Cloud プロジェクトに置き換えます。ユーザー クラスタの kubeconfig ファイルのパスを指定します。
export KUBECONFIG=PATH
PATH は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。
Binary Authorization API アクセス サービス アカウントの名前を選択します。
export SA_NAME=SERVICE_ACCOUNT_NAME
SERVICE_ACCOUNT_NAME は、任意のサービス アカウント名に置き換えます。Binary Authorization モジュールは、このサービス アカウントを使用して Binary Authorization API にアクセスします。
このガイドで後ほどダウンロードするサービス アカウント キー ファイルのパスを指定します。
export SA_JSON_PATH=SA_KEY_FILE_PATH
SA_KEY_FILE_PATH は、サービス アカウントの JSON キーファイルのパスに置き換えます。
ユーザー クラスタに Binary Authorization モジュールをインストールする
Binary Authorization モジュールのインストール手順は次のとおりです。
Workload Identity の使用
フリートの Workload Identity により、Google Cloud サービス アカウントキーのダウンロード、手動でのローテーション、全般的な管理を行うことなく、クラスタ内のワークロードを Google に認証させることができます。フリートの Workload Identity の仕組みと使用するメリットの詳細については、フリート Workload Identity を使用するをご覧ください。
フリートホスト プロジェクトの Kubernetes サービス アカウントに
binaryauthorization.policyEvaluator
ロールを付与します。gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_ID}.svc.id.goog[binauthz-system/binauthz-admin]" \ --role="roles/binaryauthorization.policyEvaluator"
作業ディレクトリを作成します。
binauthz
というディレクトリを作成します。このディレクトリに移動します。
manifest-wi-0.2.6.yaml.tmpl
ファイルをダウンロードします。このファイルは、ユーザー クラスタに Binary Authorization モジュールをインストールするために使用します。ベアメタル
gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
VMware
gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
テンプレート内の環境変数を置き換えます。
envsubst < manifest-wi-0.2.6.yaml.tmpl > manifest-0.2.6.yaml
ユーザー クラスタに Binary Authorization モジュールをインストールします。
kubectl apply -f manifest-0.2.6.yaml
Deployment が作成されたことを確認します。
kubectl get pod --namespace binauthz-system
次の出力のように、
Status
がRunning
、Ready が 1/1 の Podbinauthz-module-deployment-*
が表示されます。NAME READY STATUS RESTARTS AGE binauthz-module-deployment-5fddf9594f-qjprz 1/1 Running 0 11s
サービス アカウント キーの使用
Google Cloud CLI のデフォルト プロジェクトを設定します。
gcloud config set project ${PROJECT_ID}
Binary Authorization API アクセス サービス アカウントを作成します。
gcloud iam service-accounts create ${SA_NAME}
フリート ホスト プロジェクトの Binary Authorization API アクセス サービス アカウントに
binaryauthorization.policyEvaluator
ロールを付与します。gcloud projects add-iam-policy-binding ${PROJECT_ID}\ --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \ --role="roles/binaryauthorization.policyEvaluator"
作業ディレクトリを作成します。
binauthz
というディレクトリを作成します。このディレクトリに移動します。
manifest-0.2.6.yaml
ファイルをダウンロードします。このファイルは、ユーザー クラスタに Binary Authorization モジュールをインストールするために使用します。ベアメタル
gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .
VMware
gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-0.2.6.yaml .
binauthz-system
Namespace の YAML ファイルを作成します。namespace.yaml
という名前のファイルに次のものをコピーします。apiVersion: v1 kind: Namespace metadata: labels: control-plane: binauthz-controller name: binauthz-system
ユーザー クラスタで Namespace を作成します。
kubectl apply -f namespace.yaml
次のような出力が表示されます。
namespace/binauthz-system created
作成したサービス アカウントの JSON キーファイルをダウンロードします。
gcloud iam service-accounts keys create ${SA_JSON_PATH} --iam-account ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com
サービス アカウント キーを Kubernetes Secret としてユーザー クラスタに保存します。
kubectl --namespace binauthz-system create secret generic binauthz-sa --from-file=key.json=${SA_JSON_PATH}
ユーザー クラスタに Binary Authorization モジュールをインストールします。
kubectl apply -f manifest-0.2.6.yaml
Deployment が作成されたことを確認します。
kubectl get pod --namespace binauthz-system
次の出力のように、
Status
がRunning
、Ready が 1/1 の Podbinauthz-module-deployment-*
が表示されます。NAME READY STATUS RESTARTS AGE binauthz-module-deployment-5fddf9594f-qjprz 1/1 Running 0 11s
Binary Authorization ポリシーを設定して使用する
このセクションでは、オンプレミス クラスタに Binary Authorization ポリシーを設定し、使用する方法を説明します。
それぞれの例でポリシーを構成し、クラスタにコンテナ イメージをデプロイしてテストします。
すべて許可
このセクションでは、成功例について説明します。コンテナ イメージがポリシーを満たしてデプロイされるように、Binary Authorization ポリシーを構成します。
Google Cloud で次の操作を行います。
コンソール
Google Cloud コンソールで [Binary Authorization] ページに移動します。
フリート ホスト プロジェクト ID を選択してください。
[ポリシーの編集] をクリックします。
[プロジェクトのデフォルト ルール] で [すべてのイメージを許可] をオンにします。
[ポリシーを保存] をクリックします。
gcloud
フリート ホスト プロジェクトの
PROJECT_ID
を設定します。このプロジェクト ID は、ユーザー クラスタ構成ファイルのgkeConnect
フィールドで確認できます。export PROJECT_ID=PROJECT_ID
デフォルトの Google Cloud プロジェクトを設定します。
gcloud config set project ${PROJECT_ID}
ポリシー YAML ファイルをローカル システムにエクスポートします。
gcloud container binauthz policy export > policy.yaml
YAML ファイルは、次のようになります。
defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_ALLOW globalPolicyEvaluationMode: ENABLE name: projects/<var>PROJECT_ID</var>/policy
policy.yaml
を編集します。evaluationMode
をALWAYS_ALLOW
に設定します。ファイルに
requireAttestationsBy
ブロックがある場合は、そのブロックを削除します。ファイルを保存します。
次のように
policy.yaml
をインポートします。gcloud container binauthz policy import policy.yaml
除外イメージを許可リストに追加するには、ポリシー ファイルに次の行を追加します。
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
EXEMPT_IMAGE_PATH
は、除外するイメージのパスに置き換えます。除外するイメージを追加するには、- namePattern
エントリを追加します。admissionWhitelistPatterns
の詳細をご確認ください。
管理ワークステーションで、次の操作を行います。
Pod のマニフェスト ファイルを作成します。
以下の行を
pod.yaml
という名前のファイルに保存します。apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: - name: test-container image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
Pod を作成します。
kubectl apply -f pod.yaml
Pod が正常にデプロイされたことがわかります。
Pod を削除します。
kubectl delete -f pod.yaml
すべて禁止
このセクションでは、失敗例について説明します。このセクションでは、コンテナ イメージのデプロイを許可しないように、デフォルトのポリシーを構成します。
Google Cloud で次の操作を行います。
コンソール
Google Cloud コンソールで [Binary Authorization] ページに移動します。
フリート ホスト プロジェクトが選択されていることを確認します。
[ポリシーの編集] をクリックします。
[プロジェクトのデフォルト ルール] で [すべてのイメージを禁止] を選択します。
[ポリシーを保存] をクリックします。
gcloud
PROJECT_ID
をフリート ホスト プロジェクト ID に設定します。export PROJECT_ID=PROJECT_ID
デフォルトの Google Cloud プロジェクトを設定します。
gcloud config set project ${PROJECT_ID}
ポリシーの YAML ファイルをエクスポートします。
gcloud container binauthz policy export > policy.yaml
policy.yaml
を編集します。evaluationMode
をALWAYS_DENY
に設定します。ファイルに
requireAttestationsBy
ブロックがある場合は、そのブロックを削除します。ファイルを保存します。
次のように
policy.yaml
をインポートします。gcloud container binauthz policy import policy.yaml
管理ワークステーションで、次の操作を行います。
Pod のマニフェスト ファイルを作成します。
以下の行を
pod.yaml
という名前のファイルに保存します。apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: - name: test-container image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
Pod を作成します。
kubectl apply -f pod.yaml
Pod がデプロイからブロックされていると表示されます。出力は次のようになります。
Error from server (VIOLATES_POLICY): error when creating "pod.yaml": admission webhook "binaryauthorization.googleapis.com" denied the request: Denied by default admission rule. Overridden by evaluation mode
ユーザー クラスタのリソース ID の取得
このセクションでは、ユーザー クラスタのクラスタ リソース ID を作成する方法について説明します。Binary Authorization ポリシーでは、クラスタ固有のルールを作成できます。これらのルールは、クラスタ ID に基づいてクラスタ固有のリソース ID に関連付けます。
リソース ID は次のように取得します。
コンソール
Google Cloud コンソールで、GKE の [クラスタ] ページに移動します。
クラスタのフリート ホスト プロジェクト ID を選択します。このプロジェクト ID は、ユーザー クラスタ構成ファイルの
gkeConnect
セクションで確認できます。クラスタリストの [名前] 列でクラスタ ID を見つけます。
リソース ID を作成するには、リソース ID が
global.CLUSTER_ID
の形式になるように、クラスタ ID に接頭辞global.
を追加します。
gcloud
SSH を使用して管理ワークステーションに接続します。
管理ワークステーションで、次のコマンドを実行します。
kubectl get membership -o yaml
出力の
spec.owner.id
フィールドからクラスタ ID を取得します。出力例を次に示します。apiVersion: v1 items: - apiVersion: hub.gke.io/v1 kind: Membership ... spec: owner: id: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/my-cluster-id
出力例の中で、クラスタ ID は
my-cluster-id
です。リソース ID を作成するには、クラスタ ID に接頭辞
global.
を追加します。この例で、リソース ID はglobal.my-cluster-id
です。
このリソース ID は、クラスタ固有のルールを定義するときに使用します。Google Cloud コンソールまたは gcloud CLI を使用してクラスタ固有のルールを設定する方法を確認してください。
障害ポリシーを更新する
Binary Authorization モジュールの Webhook には、フェイル オープンまたはフェイル クローズを構成できます。
フェイル クローズ
フェイル クローズするように障害ポリシーを更新するには、次のようにします。
manifest-0.2.6.yaml ファイルを編集して、failurePolicy を
Fail
に設定します。Webhook を再度有効にします。
kubectl apply -f manifest-0.2.6.yaml
次のような出力が表示されます。
serviceaccount/binauthz-admin unchanged role.rbac.authorization.k8s.io/binauthz-role configured clusterrole.rbac.authorization.k8s.io/binauthz-role configured rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged secret/binauthz-tls unchanged service/binauthz unchanged deployment.apps/binauthz-module-deployment unchanged validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured
フェイル オープン
フェイル オープンするように障害ポリシーを更新するには、次のようにします。
manifest-0.2.6.yaml ファイルを編集して、failurePolicy を
Ignore
に設定します。Webhook を再度有効にします。
kubectl apply -f manifest-0.2.6.yaml
次のような出力が表示されます。
serviceaccount/binauthz-admin unchanged role.rbac.authorization.k8s.io/binauthz-role configured clusterrole.rbac.authorization.k8s.io/binauthz-role configured rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged secret/binauthz-tls unchanged service/binauthz unchanged deployment.apps/binauthz-module-deployment unchanged validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured
詳細については、Webhook 障害ポリシーをご覧ください。
クリーンアップ
次のコードサンプルでは、Webhook を無効にする方法を示します。
kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration
次のコードサンプルでは、Webhook を再度有効にする方法を示します。
kubectl apply -f manifest-0.2.6.yaml
次のコードサンプルでは、Binary Authorization に関連するすべてのリソースを削除する方法を示します。
kubectl delete -f manifest-0.2.6.yaml kubectl delete namespace binauthz-system
次のステップ
- ドライランを有効にするで、Pod の作成を実際にブロックせずに、Pod の作成時にポリシーの遵守を確認する方法を確認する。
- ブレークグラスを使用するで、通常であれば Binary Authorization 施行者がブロックする Pod を強制的に作成する方法を確認する。
built-by-cloud-build
認証者を使用して、Cloud Build によってビルドされたイメージのみをデプロイする。- 認証者ベースの Binary Authorization ポリシーを実装するには、以下をご覧ください。
- Google Cloud コンソールまたはコマンドライン ツールを使用してポリシーを構成する。証明書を要求するデフォルト ルールまたはクラスタ固有のルールを設定する。
- Google Cloud コンソールまたはコマンドライン ツールを使用して認証者を作成する。
- 証明書を作成する。
- Cloud Audit Logs のイベントを表示するで、Binary Authorization for Distributed Cloud に関連するログイベントを確認する。
- 指標をモニタリングする。