GKE クラスタを設定する

注: このドキュメントは、GKE on Bare Metal 1.15 以前のユーザーのみを対象としています。GKE on Bare Metal 1.16 以降の場合は、クラスタの作成時または更新時に Binary Authorization を構成できます。

注: このドキュメントでは、Google が不快感を与えるコンテンツまたは不適切なコンテンツと見なす用語が使用されています。これらの用語は、ドキュメントで説明するソフトウェアでキーワードとして使用されているため、こうした用語について言及しています。

キーワード: whitelist

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

このドキュメントでは、GKE クラスタ用に Binary Authorization を設定する方法について説明します。その後、Binary Authorization ポリシーのサンプルを構成する方法について説明します。

始める前に

1. Connect に登録された GKE クラスタが必要です。Binary Authorization は次の環境をサポートしています。

   GKE on Bare Metal

   GKE on Bare Metal 1.14 以降。

   GKE on VMware

   GKE on VMware 1.4 以降

2. Binary Authorization サービスは、パブリック IP アドレスを使用し、通常のインターネット接続を介してアクセスできます。HTTPS でユーザー クラスタがエンドポイント binaryauthorization.googleapis.com にアクセスできるように、ファイアウォール ルールを構成します。

   GKE on Bare Metal

   GKE on Bare Metal ファイアウォール ルールを構成します。

   GKE on VMware

   GKE on VMware ファイアウォール ルールを構成します。

3. 一元化された Cloud Audit Logs を使用して監査ログエントリ（GKE クラスタ用 Binary Authorization のエントリなど）を表示するには、クラスタ構成で Cloud Audit Logs を構成する必要があります。

   GKE on Bare Metal

   GKE on Bare Metal で Cloud Audit Logs を構成します。

   GKE on VMware

   GKE on VMware で Cloud Audit Logs を構成します。

4. 次のように Binary Authorization API を有効にする必要があります。

   1. Google Cloud Console に移動します。

      API を有効にします。

   2. プロジェクトのプルダウン リストで、Connect プロジェクトを選択します。この Google Cloud プロジェクトは、ユーザー クラスタ構成ファイルの gkeConnect セクションにあります。これは、ユーザー クラスタを Google Cloud に接続する Google Cloud プロジェクトです。

Binary Authorization を設定する

このセクションでは、クラスタ内に GKE クラスタ用 Binary Authorization を設定します。

インストール環境変数を指定する

環境変数を指定する方法は次のとおりです。

Workload Identity の使用

1. Connect プロジェクトを指定します。

   export PROJECT_ID=PROJECT_ID
   

2. クラスタのフリート メンバーシップ ID を指定します。

   export MEMBERSHIP_ID=MEMBERSHIP_ID
   

サービス アカウント キーの使用

1. Connect プロジェクトを指定します。

   export PROJECT_ID=PROJECT_ID
   

   PROJECT_ID は、ユーザー クラスタ構成ファイルの gkeConnect セクションに記載されている Google Cloud プロジェクトに置き換えます。

2. ユーザー クラスタの kubeconfig ファイルのパスを指定します。

   export KUBECONFIG=PATH
   

   PATH は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。

3. Binary Authorization API アクセス サービス アカウントの名前を選択します。

   export SA_NAME=SERVICE_ACCOUNT_NAME
   

   SERVICE_ACCOUNT_NAME は、任意のサービス アカウント名に置き換えます。Binary Authorization モジュールは、このサービス アカウントを使用して Binary Authorization API にアクセスします。

4. このガイドで後ほどダウンロードするサービス アカウント キー ファイルのパスを指定します。

   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 を使用するをご覧ください。

1. Connect プロジェクトの 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"
   

2. 作業ディレクトリを作成します。

   1. binauthz というディレクトリを作成します。

   2. このディレクトリに移動します。

3. manifest-wi-0.2.6.yaml.tmpl ファイルをダウンロードします。このファイルは、GKE クラスタのユーザー クラスタに Binary Authorization モジュールをインストールするために使用します。

   GKE on Bare Metal

   gsutil cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
   

   GKE on VMware

   gsutil cp gs://gke-on-prem-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .
   

4. テンプレート内の環境変数を置き換えます。

   envsubst < manifest-wi-0.2.6.yaml.tmpl > manifest-0.2.6.yaml
   

5. ユーザー クラスタに Binary Authorization モジュールをインストールします。

   kubectl apply -f manifest-0.2.6.yaml
   

6. Deployment が作成されたことを確認します。

   kubectl get pod --namespace binauthz-system
   

   次の出力のように、Status が Running、Ready が 1/1 の Pod binauthz-module-deployment-* が表示されます。

   NAME                                          READY   STATUS    RESTARTS   AGE
   binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s
   

サービス アカウント キーの使用

1. Google Cloud CLI のデフォルト プロジェクトを設定します。

   gcloud config set project ${PROJECT_ID}
   

2. Binary Authorization API アクセス サービス アカウントを作成します。

   gcloud iam service-accounts create ${SA_NAME}
   

3. Connect プロジェクトの 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"
   

4. 作業ディレクトリを作成します。

   1. binauthz というディレクトリを作成します。

   2. このディレクトリに移動します。

5. manifest-0.2.6.yaml ファイルをダウンロードします。このファイルは、GKE クラスタのユーザー クラスタに Binary Authorization モジュールをインストールするために使用します。

   anthos_clusters_on_bare_metal

   gsutil cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .
   

   anthos_clusters_on_vmware

   gsutil cp gs://gke-on-prem-release/binauthz/manifest-0.2.6.yaml .
   

6. binauthz-system Namespace の YAML ファイルを作成します。

   namespace.yaml という名前のファイルに次のものをコピーします。

   apiVersion: v1
   kind: Namespace
   metadata:
     labels:
       control-plane: binauthz-controller
     name: binauthz-system
   

7. ユーザー クラスタで Namespace を作成します。

   kubectl apply -f namespace.yaml
   

   次のような出力が表示されます。

   namespace/binauthz-system created
   

8. 作成したサービス アカウントの JSON キーファイルをダウンロードします。

   gcloud iam service-accounts keys create ${SA_JSON_PATH} --iam-account ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com
   

9. サービス アカウント キーを Kubernetes Secret としてユーザー クラスタに保存します。

   kubectl --namespace binauthz-system create secret generic binauthz-sa --from-file=key.json=${SA_JSON_PATH}
   

10. ユーザー クラスタに Binary Authorization モジュールをインストールします。

    kubectl apply -f manifest-0.2.6.yaml
    

11. Deployment が作成されたことを確認します。

    kubectl get pod --namespace binauthz-system
    

    次の出力のように、Status が Running、Ready が 1/1 の Pod binauthz-module-deployment-* が表示されます。

    NAME                                          READY   STATUS    RESTARTS   AGE
    binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s
    

Binary Authorization ポリシーを設定して使用する

このセクションでは、GKE クラスタに Binary Authorization ポリシーを設定し、使用する方法を説明します。

それぞれの例でポリシーを構成し、GKE クラスタにコンテナ イメージをデプロイしてテストします。

すべて許可

このセクションでは、成功例について説明します。コンテナ イメージがポリシーを満たしてデプロイされるように、Binary Authorization ポリシーを構成します。

注意: このポリシーでは、すべてのコンテナ イメージのデプロイが許可されます。

Google Cloud で次の操作を行います。

コンソール

1. Google Cloud Console で [Binary Authorization] ページに移動します。

   Binary Authorization に移動

2. 必ず Connect プロジェクト ID を選択してください。

3. [ポリシーの編集] をクリックします。

4. [プロジェクトのデフォルト ルール] で [すべてのイメージを許可] をオンにします。

5. [ポリシーを保存] をクリックします。

gcloud

1. Connect プロジェクトの PROJECT_ID を設定します。このプロジェクト ID は、ユーザー クラスタ構成ファイルの gkeConnect フィールドで確認できます。

   export PROJECT_ID=PROJECT_ID
   

   デフォルトの Google Cloud プロジェクトを設定します。

   gcloud config set project ${PROJECT_ID}
   

2. ポリシー 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
   

3. policy.yaml を編集します。

4. evaluationMode を ALWAYS_ALLOW に設定します。

5. ファイルに requireAttestationsBy ブロックがある場合は、そのブロックを削除します。

6. ファイルを保存します。

7. 次のように policy.yaml をインポートします。

   gcloud container binauthz policy import policy.yaml
   

除外イメージを許可リストに追加するには、ポリシー ファイルに次の行を追加します。

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

EXEMPT_IMAGE_PATH は、除外するイメージのパスに置き換えます。除外するイメージを追加するには、- namePattern エントリを追加します。admissionWhitelistPatterns の詳細をご確認ください。

GKE クラスタの管理ワークステーションで、次の操作を行います。

1. 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
   

2. Pod を作成します。

   kubectl apply -f pod.yaml
   

   Pod が正常にデプロイされたことがわかります。

3. Pod を削除します。

   kubectl delete -f pod.yaml
   

すべて禁止

このセクションでは、失敗例について説明します。このセクションでは、コンテナ イメージのデプロイを許可しないように、デフォルトのポリシーを構成します。

注意: このポリシーでは、すべてのコンテナ イメージのデプロイが許可されません。

Google Cloud で次の操作を行います。

コンソール

1. Google Cloud Console で [Binary Authorization] ページに移動します。

   Binary Authorization に移動

2. Connect プロジェクトが選択されていることを確認します。

3. [ポリシーの編集] をクリックします。

4. [プロジェクトのデフォルト ルール] で [すべてのイメージを禁止] を選択します。

5. [ポリシーを保存] をクリックします。

gcloud

1. PROJECT_ID は、実際の Connect プロジェクト ID に設定します

   export PROJECT_ID=PROJECT_ID
   

2. デフォルトの Google Cloud プロジェクトを設定します。

   gcloud config set project ${PROJECT_ID}
   

3. ポリシーの YAML ファイルをエクスポートします。

   gcloud container binauthz policy export  > policy.yaml
   

4. policy.yaml を編集します。

5. evaluationMode を ALWAYS_DENY に設定します。

6. ファイルに requireAttestationsBy ブロックがある場合は、そのブロックを削除します。

7. ファイルを保存します。

8. 次のように policy.yaml をインポートします。

   gcloud container binauthz policy import policy.yaml
   

注: ポリシーが有効になるまでに数分かかる場合があります。

GKE クラスタの管理ワークステーションで、次の操作を行います。

1. 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
   

2. 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 は次のように取得します。

コンソール

1. Google Cloud コンソールで、GKE の [クラスタ] ページに移動します。

   [クラスタ] に移動

2. GKE クラスタの Connect プロジェクト ID を選択します。このプロジェクト ID は、ユーザー クラスタ構成ファイルの gkeConnect セクションで確認できます。

3. [Anthos マネージド クラスタ] の [名前] 列で、クラスタ ID を見つけます。

4. リソース ID を作成するには、リソース ID が global.CLUSTER_ID の形式になるように、クラスタ ID に接頭辞 global. を追加します。

gcloud

1. SSH を使用して GKE クラスタの管理ワークステーションに接続します。

2. 管理ワークステーションで、次のコマンドを実行します。

   kubectl get membership -o yaml
   

3. 出力の 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 です。

4. リソース ID を作成するには、クラスタ ID に接頭辞 global. を追加します。この例で、リソース ID は global.my-cluster-id です。

このリソース ID は、クラスタ固有のルールを定義するときに使用します。Google Cloud コンソールまたは gcloud CLI を使用してクラスタ固有のルールを設定する方法を確認してください。

障害ポリシーを更新する

Binary Authorization モジュールの Webhook には、フェイル オープンまたはフェイル クローズを構成できます。

フェイル クローズ

フェイル クローズするように障害ポリシーを更新するには、次のようにします。

1. manifest-0.2.6.yaml ファイルを編集して、failurePolicy を Fail に設定します。

2. 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
   

フェイル オープン

フェイル オープンするように障害ポリシーを更新するには、次のようにします。

1. manifest-0.2.6.yaml ファイルを編集して、failurePolicy を Ignore に設定します。

2. 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 障害ポリシーをご覧ください。

クリーンアップ

1. 次のコードサンプルでは、Webhook を無効にする方法を示します。

   kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration
   

2. 次のコードサンプルでは、Webhook を再度有効にする方法を示します。

   kubectl apply -f manifest-0.2.6.yaml
   

3. 次のコードサンプルでは、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 Console またはコマンドライン ツールを使用してポリシーを構成する。証明書を要求するデフォルト ルールまたはクラスタ固有のルールを設定する。
  • Google Cloud Console またはコマンドライン ツールを使用して認証者を作成する。
  • 証明書を作成する。
• GKE クラスタ用の Binary Authorization に関連するログイベントを表示する。Cloud Audit Logs のイベントを表示するをご覧ください。
• 指標をモニタリングする。