オンプレミス クラスタを設定する

このドキュメントでは、Google Distributed Cloud の一部として作成されたオンプレミス クラスタの Binary Authorization を設定する方法について説明します。その後、Binary Authorization ポリシーのサンプルを構成する方法について説明します。

始める前に

  1. クラスタにサポートされている 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 以降。

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

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

    ベアメタル

    Google Distributed Cloud で Cloud Audit Logs を構成します。

    VMware

    Google Distributed Cloud で Cloud Audit Logs を構成します。

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

    1. Google Cloud コンソールに移動します。

      API を有効にします

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

Binary Authorization を設定する

このセクションでは、オンプレミス クラスタに Binary Authorization を設定します。

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

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

Workload Identity の使用

  1. フリート ホスト プロジェクトを指定します。

    export PROJECT_ID=PROJECT_ID
    
  2. フリート メンバーシップ ID をクラスタ ID に設定します。

    メンバーシップ ID は、gcloud container fleet memberships list コマンドを実行すると NAME 列に表示されます。

    export MEMBERSHIP_ID=CLUSTER_NAME
    

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

  1. フリート ホスト プロジェクトを指定します。

    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. フリートホスト プロジェクトの 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 ファイルをダウンロードします。このファイルは、ユーザー クラスタに 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 .
    
  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
    

    次の出力のように、StatusRunning、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. フリート ホスト プロジェクトの 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 ファイルをダウンロードします。このファイルは、ユーザー クラスタに 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 .
    
  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
    

    次の出力のように、StatusRunning、Ready が 1/1 の Pod binauthz-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 で次の操作を行います。

コンソール

  1. Google Cloud コンソールで [Binary Authorization] ページに移動します。

    [Binary Authorization] に移動

  2. フリート ホスト プロジェクト ID を選択してください。

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

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

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

gcloud

  1. フリート ホスト プロジェクトの 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. evaluationModeALWAYS_ALLOW に設定します。

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

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

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

    gcloud container binauthz policy import policy.yaml
    

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

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

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

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

  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 コンソールで [Binary Authorization] ページに移動します。

    [Binary Authorization] に移動

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

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

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

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

gcloud

  1. PROJECT_ID をフリート ホスト プロジェクト 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. evaluationModeALWAYS_DENY に設定します。

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

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

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

    gcloud container binauthz policy import policy.yaml
    

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

  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. クラスタのフリート ホスト プロジェクト ID を選択します。このプロジェクト ID は、ユーザー クラスタ構成ファイルの gkeConnect セクションで確認できます。

  3. クラスタリストの [名前] 列でクラスタ ID を見つけます。

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

gcloud

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

  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
    

次のステップ