Anthos clusters on VMware を設定する

このドキュメントでは、Anthos clusters on VMware(GKE On-Prem)の Binary Authorization の設定方法について説明します。その後、Binary Authorization ポリシーのサンプルを構成する方法について説明します。

始める前に

  1. Anthos clusters on VMware 1.4 以降をインストールして構成し、管理クラスタとユーザー クラスタが存在している必要があります。ユーザー クラスタは、Connect に登録されていなければなりません。

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

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

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

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

      API を有効にします

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

Binary Authorization を設定する

このセクションでは、ユーザー クラスタ内に Anthos clusters on VMware 用の Binary Authorization を設定します。

インストール環境変数の指定

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

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

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

    export PROJECT_ID=PROJECT_ID
    

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

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

    export KUBECONFIG=PATH
    

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

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

    export SA_NAME=SERVICE_ACCOUNT_NAME
    

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

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

    export SA_JSON_PATH=SA_KEY_FILE_PATH
    

    SA_KEY_FILE_PATH は、サービス アカウントの JSON キーファイルのパスに置き換えます。

ユーザー クラスタに Binary Authorization モジュールをインストールする

Binary Authorization モジュールのインストール手順は次のとおりです。

  1. gcloud command-line tool ツールのデフォルト プロジェクトを設定します。

    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.yaml ファイルをダウンロードします。このファイルは、Anthos clusters on VMware クラスタに Binary Authorization モジュールをインストールするために使用します。

    gsutil cp gs://gke-on-prem-release/binauthz/manifest-0.2.2.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.2.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 ポリシーを設定して使用する

このセクションでは、Anthos clusters on VMware の Binary Authorization ポリシーを設定して使用する方法について説明します。

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

すべて許可

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

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

Console

  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 ファイルは、次のようになります。

    admissionWhitelistPatterns:
    - namePattern: gcr.io/google_containers/*
    - namePattern: gcr.io/google-containers/*
    - namePattern: k8s.gcr.io/**
    - namePattern: gke.gcr.io/**
    - namePattern: gcr.io/stackdriver-agents/*
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: ALWAYS_ALLOW
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    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
    

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

  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 で次の操作を行います。

Console

  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. デフォルトの 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
    

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

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

Console

  1. Cloud Console で、Anthos クラスタのページに移動します。

    クラスタに移動

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

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

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

gcloud

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

  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 は、クラスタ固有のルールを定義するときに使用します。Cloud Console または gcloud ツールを使用してクラスタ固有のルールを設定する方法を確認してください。

障害ポリシーを更新する

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

フェイル クローズ

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

  1. manifest-0.2.2.yaml を編集して、failurePolicy を fail に設定します。

  2. Webhook を再度有効にします。

    kubectl apply -f namespace.yaml
    

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

    namespace/binauthz-system created
    

フェイル オープン

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

  1. manifest-0.2.2.yaml を編集して、failurePolicy を ignore に設定します。

  2. Webhook を再度有効にします。

    kubectl apply -f namespace.yaml
    

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

    namespace/binauthz-system created
    

詳細については、Webhook 障害ポリシーをご覧ください。

クリーンアップ

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

    kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration
    
  2. 次のコードサンプルでは、Webhook を再度有効にする方法を示します。

    kubectl apply -f manifest-0.2.2.yaml
    
  3. 次のコードサンプルでは、Binary Authorization に関連するすべてのリソースを削除する方法を示します。

    kubectl delete -f manifest-0.2.2.yaml
    kubectl delete namespace binauthz-system
    

次のステップ