IAP と Anthos Service Mesh の統合

このチュートリアルでは、Identity-Aware Proxy（IAP）を Anthos Service Mesh と統合する方法について説明します。IAP を Anthos Service Mesh と統合すると、Google の BeyondCorp の原則に基づいて、サービスに安全にアクセスできるようになります。IAP は、ユーザー ID とリクエストのコンテキストを確認し、ユーザーにアプリケーションまたはリソースへのアクセスを許可するかどうかを決定します。IAP を Anthos Service Mesh と統合すると、次のメリットがあります。

  • Anthos Service Mesh で実行されるワークロードに対するコンテキストアウェア アクセスの制御。発信元リクエストの属性（ユーザー ID、IP アドレス、デバイスの種類など）に基づいて、きめ細かいアクセス ポリシーを設定できます。リクエスト URL のホスト名とパスに基づいて、アクセス ポリシーと制限を組み合わせることができます。

  • Anthos Service Mesh 認証におけるコンテキストアウェア クレームのサポート。

  • Google Cloud ロードバランサを介したアプリケーションに対する、スケーラブルで安全かつ可用性の高いアクセス。高パフォーマンスの負荷分散では、組み込みの保護機能で分散型サービス拒否（DDoS）攻撃を防ぎ、グローバルなエニーキャスト IP アドレスを使用できます。

目標

  • 設定を行う。
    1. Google Cloud プロジェクトを設定し、権限を付与して、IAP で必要な Google API を有効にする。
    2. 外部静的 IP アドレスを予約し、ロードバランサで必要となる IP アドレスを使用するようにドメイン名を構成する。
    3. IAP と Anthos Service Mesh の統合に必要なオプションを使用して、新しい Google Kubernetes Engine（GKE）クラスタを設定する。
    4. 統合に必要なオプションを使用して Anthos Service Mesh をインストールする。
    5. サンプル アプリケーションをデプロイする。
    6. ロードバランサをデプロイする。

  • IAP を有効にする。

  • サービス メッシュで RCToken サポートを有効にする。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

要件

  • Anthos の試用版ライセンスまたはサブスクリプションが必要です。詳細については、Anthos 料金ガイドをご覧ください。

  • GKE クラスタは次の要件を満たす必要があります。

  • サービス メッシュに含めるには、サービスポートに名前を付ける必要があります。名前には、name: protocol[-suffix] の構文でポートのプロトコルを含める必要があります。角かっこは、ダッシュで始まるオプションの接尾辞です。詳細については、サービスポートの命名をご覧ください。

  • Anthos Service Mesh を限定公開クラスタにインストールする場合に、自動サイドカー インジェクションを使用するには、ポート 15017 を開くファイアウォール ルールを追加する必要があります。ファイアウォール ルールを追加せず、自動サイドカー インジェクションを有効にすると、ワークロードのデプロイでエラーが発生します。ファイアウォール ルールの追加方法については、特定のユースケースに対するファイアウォール ルールの追加をご覧ください。

  • 組織にサービス境界を作成した場合は、Mesh CA サービスを境界に追加する必要があります。詳細については、サービス境界へのメッシュ CA の追加をご覧ください。

環境設定

Google Kubernetes Engine へのインストールは、インストール ガイドに沿って行います。インストールは、Cloud Shell、Google Cloud リソースに対するブラウザ内コマンドライン インターフェース、Linux または macOS を実行している独自のコンピュータを使用して行うことができます。

オプション A: Cloud Shell を使用する

Cloud Shell は、Debian ベースの Linux オペレーティング システムを実行している g1-small Compute Engine 仮想マシン（VM）をプロビジョニングします。Cloud Shell を使用する利点は次のとおりです。

  • Cloud Shell には、必要な gcloud、kubectl、helm コマンドライン ツールが含まれています。

  • Cloud Shell の $HOME ディレクトリには 5 GB の永続ストレージ スペースがあります。

  • テキスト エディタを選択できます。

    • コードエディタ。Cloud Shell ウィンドウの上部にある をクリックしてアクセスします。

    • Emacs、Vim、Nano。Cloud Shell のコマンドラインからアクセスします。

Cloud Shell を使用するには:

  1. Google Cloud コンソールに移動します。
  2. Google Cloud プロジェクトを選択します。

  3. Google Cloud コンソール ウィンドウの上部にある [Cloud Shell をアクティブにする] ボタンをクリックします。

    Google Cloud Platform コンソール

    Google Cloud コンソールの一番下にある新しいフレームの中で Cloud Shell セッションが開き、コマンドライン プロンプトが表示されます。

    Cloud Shell セッション

  4. コンポーネントを更新します。

    gcloud components update

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

    ERROR: (gcloud.components.update)
You cannot perform this action because the gcloud CLI component manager
is disabled for this installation. You can run the following command
to achieve the same result for this installation:

sudo apt-get update && sudo apt-get --only-upgrade install ...

  5. long コマンドをコピーし、貼り付けてコンポーネントを更新します。

  6. kubectl をインストールします。

    sudo apt-get install kubectl

  7. kpt をインストールします。

    sudo apt-get install google-cloud-sdk-kpt

オプション B: ローカルのコマンドライン ツールを使用する

ローカルマシンに gcloud CLI をインストールして初期化します。

  1. Google Cloud CLI で認証します。

    gcloud auth login

  2. コンポーネントを更新します。

    gcloud components update

  3. kubectl をインストールします。

    gcloud components install kubectl

  4. kpt をインストールします。

    gcloud components install kpt

プロジェクトの設定

  1. クラスタが作成されるプロジェクトのプロジェクト ID を取得します。

    gcloud

    gcloud projects list

    コンソール

    1. Google Cloud コンソールで、[ダッシュボード] ページに移動します。

      [ダッシュボード] ページに移動する

    2. ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。

      プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。

  2. プロジェクト ID の環境変数を作成します。
    export PROJECT_ID=YOUR_PROJECT_ID
  3. gcloud コマンドライン ツールのデフォルトのプロジェクト ID を設定します。
    gcloud config set project ${PROJECT_ID}
  4. プロジェクト番号の環境変数を作成します。
    export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

  5. 必要な Identity and Access Management（IAM）のロールを設定します。プロジェクト オーナーの場合、インストールを完了し、クラスタを Environ に登録するために必要なすべての権限が付与されています。プロジェクト オーナーでない場合は、次の IAM ロールを付与する担当者が必要になります。次のコマンドで、GCP_EMAIL_ADDRESS を Google Cloud へのログインに使用するアカウントに変更します。
    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
     --member user:GCP_EMAIL_ADDRESS \
     --role=roles/editor \
     --role=roles/compute.admin \
     --role=roles/container.admin \
     --role=roles/resourcemanager.projectIamAdmin \
     --role=roles/iam.serviceAccountAdmin \
     --role=roles/iam.serviceAccountKeyAdmin \
     --role=roles/gkehub.admin

    IAM のロールを付与する方法については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。これらのロールの説明については、Anthos Service Mesh のインストールに必要な権限をご覧ください。

  6. 次の API を有効にします。
    gcloud services enable \
    container.googleapis.com \
    compute.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com \
    cloudtrace.googleapis.com \
    meshca.googleapis.com \
    meshtelemetry.googleapis.com \
    meshconfig.googleapis.com \
    iamcredentials.googleapis.com \
    anthos.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    iap.googleapis.com

    API の有効化に数分かかることがあります。API が有効になると、次のような出力が表示されます。

    Operation "operations/acf.601db672-88e6-4f98-8ceb-aa3b5725533c" finished
successfully.

静的 IP アドレスの予約と DNS の構成

Identity-Aware Proxy を Anthos Service Mesh と統合するには、Google Cloud HTTP(S) ロードバランサを設定する必要があります。この設定では、静的 IP アドレスを参照するドメイン名が必要です。静的外部 IP アドレスを予約すると、明示的に解放するまで、このアドレスを無期限でプロジェクトに割り当てることができます。

  1. 静的外部 IP アドレスを予約します。

    gcloud compute addresses create example-static-ip --global

  2. 静的 IP アドレスを取得します。

    gcloud compute addresses describe example-static-ip --global

  3. ドメイン名登録事業者で、静的 IP アドレスを含む完全修飾ドメイン名（FQDN）を構成します。通常、DNS 設定に A レコードを追加します。FQDN の A レコードを追加する構成手順と用語は、使用するドメイン名登録事業者によって異なります。

  4. 環境変数にドメイン名を設定します。

    export DOMAIN_NAME=YOUR_DOMAIN_NAME

    DNS 設定が反映されるまでに、24～48 時間かかります。このチュートリアルに従って設定を続けられますが、DNS 設定が反映されるまで設定のテストはできません。

新しい GKE クラスタの設定

新しいクラスタを設定するには:

  1. 新しいクラスタのゾーン、マシンタイプ、GKE リリース チャンネルを選択します。Anthos Service Mesh で必要最小限なマシンタイプは n1-standard-4 です。任意のリリース チャンネル オプションを使用できます。

    • 使用可能な GCP ゾーンの一覧を取得するには:

      gcloud compute zones list

    • マシンタイプのリストを取得するには:

      gcloud compute machine-types list | more

  2. 次の環境変数を作成します。

    • クラスタ名を設定します。

      export CLUSTER_NAME=YOUR_CLUSTER_NAME

      クラスタ名に使用できるのは、英小文字、数字、- のみです。先頭は英字、末尾は英数字を使用し、40 文字以下にする必要があります。

    • CLUSTER_LOCATION を実際のクラスタゾーンに設定します。

      export CLUSTER_LOCATION=YOUR_ZONE

    • ワークロード プールを設定します。

      export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog

    • メッシュ ID を設定します。

      export MESH_ID="proj-${PROJECT_NUMBER}"

  3. Anthos Service Mesh で必要なオプションを使用してクラスタを作成します。次のコマンドは、4 つの vCPU を持つマシンタイプ n1-standard-4 の 4 つのノードを含むクラスタを作成します。これは、Anthos Service Mesh に必要な最小マシンタイプとノード数です。少なくとも 4 つの vCPU が存在する限り、別のマシンタイプを指定できます。また、システム要件に応じてノード数を増やすことができます。

    gcloud beta container clusters create ${CLUSTER_NAME} \
    --project=${PROJECT_ID} \
    --zone=${CLUSTER_LOCATION} \
    --machine-type=n1-standard-4 \
    --num-nodes=4 \
    --workload-pool=${WORKLOAD_POOL} \
    --enable-stackdriver-kubernetes \
    --subnetwork=default \
    --labels mesh_id=${MESH_ID} \
    --addons=HttpLoadBalancing \
    --release-channel=regular

    clusters create コマンドを使用します。

    • workload-pool=${WORKLOAD_POOL}: Workload Identity を有効にします。これは、GKE アプリケーションから Google Cloud サービスに安全にアクセスする方法として推奨される方法です。

    • enable-stackdriver-kubernetes: GKE で Cloud Monitoring と Cloud Logging を有効にします。

    • subnetwork=default: デフォルトのサブネットワークを作成します。

    • labels mesh_id=${MESH_ID}: クラスタに mesh_id ラベルを設定します。これは、Google Cloud コンソールの Anthos Service Mesh ダッシュボードに指標を表示するために必要です。

    • HttpLoadBalancing アドオンを使用すると、クラスタの HTTP（L7）ロード バランシング コントローラが有効になります。

    • release-channel regular: クラスタを regular リリース チャンネルに登録します。安定性を重視する場合は stable を、新しい非推奨の GKE 機能を試す場合は rapid を選択します。

認証情報と権限の設定

  1. プロジェクトを初期化してインストールの準備をします。次のコマンドでサービス アカウントを作成し、サイドカー プロキシなどの Istio コンポーネントがプロジェクトのデータとリソースに安全にアクセスできるようにします。
    curl --request POST \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data '' \
  https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize

    コマンドを実行すると、空の中かっこ {} が返されます。

    将来、このクラスタに新しいバージョンの Anthos Service Mesh をインストールする場合は、コマンドを再実行する必要はありませんが、コマンドを再実行してもインストールには影響しません。

  2. クラスタとやり取りするために必要な認証情報を取得します。
    gcloud container clusters get-credentials ${CLUSTER_NAME}
  3. 現在のユーザーにクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御（RBAC）ルールを作成するのに必要です。
    kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user="$(gcloud config get-value core/account)"

    "cluster-admin-binding" already exists エラーが発生した場合は、無視して既存の cluster-admin-binding を続行しても問題ありません。

クラスタの登録

Google Cloud コンソールで統合ユーザー インターフェースにアクセスするには、クラスタをプロジェクトのフリートに登録する必要があります。フリートは、Google Cloud 外のクラスタを含むクラスタとそのワークロードを表示して管理するために統合された方法を提供します。

Google Cloud のサービス アカウントと鍵ファイルを作成する

クラスタを登録するには、サービス アカウントの認証情報を含む JSON ファイルが必要です。最小権限の原則に従い、登録するクラスタごとに個別のサービス アカウントを作成することをおすすめします。

サービス アカウントとキーファイルを作成するには:

  1. サービス アカウントの名前を選択して、その環境変数を作成します。

    export SERVICE_ACCOUNT_NAME=SERVICE_ACCOUNT_NAME

  2. サービス アカウントを作成します。

    gcloud iam service-accounts create ${SERVICE_ACCOUNT_NAME}

  3. プロジェクトのサービス アカウントをすべて一覧表示して、サービス アカウントが作成されたことを確認します。

    gcloud iam service-accounts list

  4. サービス アカウントに gkehub.connect IAM ロールをバインドします。

    gcloud projects add-iam-policy-binding ${PROJECT_ID} \
   --member="serviceAccount:${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
   --role="roles/gkehub.connect"

  5. JSON ファイルを保存するローカル ファイルパスの環境変数を作成します。ファイル名にサービス アカウント名とプロジェクト ID を使用することをおすすめします（例: /tmp/creds/${SERVICE_ACCOUNT_NAME}-${PROJECT_ID}.json）。

    export SERVICE_ACCOUNT_KEY_PATH=LOCAL_KEY_PATH

  6. サービス アカウントの秘密鍵の JSON ファイルをダウンロードします。

    gcloud iam service-accounts keys create ${SERVICE_ACCOUNT_KEY_PATH} \
   --iam-account=${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

クラスタを登録する

次のコマンドを使用して、MEMBERSHIP_NAME を Hub に登録されているクラスタを一意に識別する名前に置き換えます。

gcloud container hub memberships register MEMBERSHIP_NAME \
    --gke-cluster=${CLUSTER_LOCATION}/${CLUSTER_NAME} \
    --service-account-key-file=${SERVICE_ACCOUNT_KEY_PATH}

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

kubeconfig entry generated for CLUSTER_NAME.
Waiting for membership to be created...done.
Created a new membership [projects/PROJECT_ID/locations/global/memberships/MEMBERSHIP_NAME] for the cluster [MEMBERSHIP_NAME]
Generating the Connect Agent manifest...
Deploying the Connect Agent on cluster [MEMBERSHIP_NAME] in namespace [gke-connect]...
Deployed the Connect Agent on cluster [MEMBERSHIP_NAME] in namespace [gke-connect].
Finished registering the cluster [MEMBERSHIP_NAME] with the Hub.

このサービス アカウント キーは、creds-gcp という名前のシークレットとして gke-connect 名前空間に保存されます。

クラスタの登録の詳細については、Connect のドキュメントでクラスタの登録をご覧ください。

インストール ファイルのダウンロード

次に進む前に、ASM Mesh Data Plane Service Account がプロジェクトのメンバーであることを確認します。

gcloud projects get-iam-policy ${PROJECT_ID} | grep -B 1 'roles/meshdataplane.serviceAgent'

上述のコマンドで何も出力されない場合は、認証情報と権限の設定セクションに戻り、curl コマンドを実行します。

    Linux

  1. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-linux.tar.gz
  2. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-linux.tar.gz.1.sig
openssl dgst -verify - -signature istio-1.5.10-asm.2-linux.tar.gz.1.sig istio-1.5.10-asm.2-linux.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    想定される出力は Verified OK です。

  3. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.5.10-asm.2-linux.tar.gz

    このコマンドにより、現在の作業ディレクトリに istio-1.5.10-asm.2 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples にはサンプル アプリケーション。
    • bin ディレクトリには次のツール:
      • istioctl: istioctl は Anthos Service Mesh のインストールに使用します。
      • asmctl: asmctl を使用して、Anthos Service Mesh をインストールした後、セキュリティ構成を検証します（現在、asmctl は Anthos clusters on VMware ではサポートされていません）。

    4. Mac OS

  4. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-osx.tar.gz
  5. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.5.10-asm.2-osx.tar.gz.1.sig istio-1.5.10-asm.2-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    想定される出力は Verified OK です。

  6. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.5.10-asm.2-osx.tar.gz

    このコマンドにより、現在の作業ディレクトリに istio-1.5.10-asm.2 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples にはサンプル アプリケーション。
    • bin ディレクトリには次のツール:
      • istioctl: istioctl は Anthos Service Mesh のインストールに使用します。
      • asmctl: asmctl を使用して、Anthos Service Mesh をインストールした後、セキュリティ構成を検証します（現在、asmctl は Anthos clusters on VMware ではサポートされていません）。

    7. Windows

  7. Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-win.zip
  8. 署名ファイルをダウンロードし、openssl を使用して署名を検証します。
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-win.zip.1.sig
openssl dgst -verify - -signature istio-1.5.10-asm.2-win.zip.1.sig istio-1.5.10-asm.2-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    想定される出力は Verified OK です。

  9. ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
    tar xzf istio-1.5.10-asm.2-win.zip

    このコマンドにより、現在の作業ディレクトリに istio-1.5.10-asm.2 という名前のインストール ディレクトリが作成されます。このディレクトリには、次のものが含まれます。

    • samples にはサンプル アプリケーション。
    • bin ディレクトリには次のツール:
      • istioctl: istioctl は Anthos Service Mesh のインストールに使用します。
      • asmctl: asmctl を使用して、Anthos Service Mesh をインストールした後、セキュリティ構成を検証します（現在、asmctl は Anthos clusters on VMware ではサポートされていません）。

  10. Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
    cd istio-1.5.10-asm.2
  11. 利便性を考えて、/bin ディレクトリ内のツールを PATH に追加します。
    export PATH=$PWD/bin:$PATH

リソース構成ファイルの準備

istioctl apply command を実行して Anthos Service Mesh をインストールする際には、コマンドラインで -f istio-operator.yaml を指定します。このファイルには、メッシュ テレメトリーとメッシュ セキュリティの機能を有効にするために必要なプロジェクトとクラスタに関する情報が含まれます。istio-operator.yaml と他のリソース構成ファイルをダウンロードして、プロジェクトとクラスタの情報を設定する必要があります。

リソース構成ファイルを準備するには:

  1. まだ行っていない場合は、kpt をインストールします。

    gcloud components install kpt

  2. 必要に応じて、Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。複数のクラスタを設定する場合は、クラスタ名をディレクトリ名として使用できます。

  3. Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。

  4. Anthos Service Mesh パッケージを現在の作業ディレクトリにダウンロードします。

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.5-asm .

  5. クラスタ名を設定します。

      kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  6. 必要に応じて、kpt セッターを使用してリソース構成ファイルをカスタマイズします。デフォルトでは、これらのセッターは gcloud config のデフォルトを使用します。gcloud config のデフォルトを設定する場合、または値を変更する場合は、次のセッターを実行します。

    • プロジェクト ID を設定します。

      kpt cfg set asm gcloud.core.project ${PROJECT_ID}

    • デフォルトのゾーンまたはリージョンを設定します。

      kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  7. また、リソース構成ファイルを Cloud Source Repositories などの独自のソース管理システムにチェックインして、ファイルの変更をトラッキングすることもできます。

Anthos Service Mesh のインストール

Anthos Service Mesh をインストールし、Anthos Service Mesh を IAP と統合するために必要なオプションを設定します。

PERMISSIVE mTLS

istioctl manifest apply --set profile=asm \
  -f asm/cluster/istio-operator.yaml \
  --set values.gateways.istio-ingressgateway.type=NodePort

STRICT mTLS

istioctl manifest apply --set profile=asm \
  -f asm/cluster/istio-operator.yaml \
  --set values.gateways.istio-ingressgateway.type=NodePort \
  --set values.global.mtls.enabled=true

istio-ingressgateway に NodePort を指定すると、サービス メッシュで特定のポートを開くように {[mesh_name]} が構成されます。また、ドメイン名に送信されたトラフィックがこのポートに転送されるようにロードバランサを設定できます。もう一方のオプションは、Anthos Service Mesh 認証局（Mesh CA）を有効にします。

インストールの検証

asmctl 分析ツールを使用して、プロジェクト、クラスタ、ワークロードの基本構成を検証することをおすすめします。asmctl テストに失敗した場合は、可能であれば asmctl は推奨の解決策を提示します。asmctl validate コマンドは、以下を確認する基本的なテストを実行します。

  1. Anthos Service Mesh で必要な API がプロジェクトで有効になっている。
  2. Istio-Ingressgateway が Mesh CA を呼び出すよう適切に構成されている。
  3. Istiod と Istio-Ingressgateway の全般的な状態。

オプションの --with-testing-workloads フラグを使用して asmctl validate コマンドを実行した場合、基本テストに加えて、asmctl は以下を確認するセキュリティ テストを実行します。

  1. 相互 TLS（mTLS）通信が適切に構成されている。
  2. メッシュ CA が証明書を発行できる。

セキュリティ テストを行う際に asmctl はクラスタ上のテスト用名前空間にワークロードをデプロイします。mTLS 通信のテストを実行して結果を出力し、テスト用名前空間を削除します。

asmctl を実行するには:

  1. gcloud application-default 認証情報が設定されていることを確認します。

     gcloud auth application-default login

  2. まだ行っていない場合は、クラスタとのやり取りに必要な認証情報を取得します。

     gcloud container clusters get-credentials ${CLUSTER_NAME}

  3. 基本テストとセキュリティ テストの両方を実行するには（istio-1.5.10-asm.2/bin が PATH にあると想定）:

    asmctl validate --with-testing-workloads

    成功すると、次のような出力が返されます。

    [asmctl version 0.3.0]
Using Kubernetes context: example-project_us-central1-example-cluster
To change the context, use the --context flag
Validating enabled APIs
OK
Validating ingressgateway configuration
OK
Validating istio system
OK
Validating sample traffic
Launching example services...
Sent traffic to example service http code: 200
verified mTLS configuration
OK
Validating issued certs
OK

サンプル アプリケーションのデプロイ

IAP を有効にする前に、GKE クラスタでアプリケーションを実行して、すべてのリクエストに ID があることを確認する必要があります。このガイドでは、Bookinfo サンプルを使用して、HTTP(S) ロードバランサを設定して IAP を有効にします。

アプリケーション サービスを開始する

  1. Anthos Service Mesh がインストールされたルート ディレクトリに移動します。

  2. 自動サイドカー インジェクションを使用するため、default 名前空間にラベルを付けます。

    kubectl label namespace default istio-injection=enabled

  3. アプリケーションをデプロイします。

    kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

  4. bookinfo サービスがすべて実行されていることを確認します。

    kubectl get services

    予想される出力は次のようになります。

    NAME                       CLUSTER-IP   EXTERNAL-IP   PORT(S)              AGE
details                    10.0.0.31            9080/TCP             6m
kubernetes                 10.0.0.1             443/TCP              7d
productpage                10.0.0.120           9080/TCP             6m
ratings                    10.0.0.15            9080/TCP             6m
reviews                    10.0.0.170           9080/TCP             6m

  5. すべての Pod が実行中であることを確認します。

    kubectl get pods

    予想される出力は次のようになります。

    NAME                                        READY     STATUS    RESTARTS   AGE
details-v1-1520924117-48z17                 2/2       Running   0          6m
productpage-v1-560495357-jk1lz              2/2       Running   0          6m
ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

  6. Bookinfo アプリケーションが実行中であることを確認します。

    kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"

    予想される出力:

    <title>Simple Bookstore App</title>

  7. アプリケーションの Ingress ゲートウェイと仮想サービスを定義します。

    kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

  8. ゲートウェイが作成されたことを確認します。

    kubectl get gateway

    予想される出力は次のようになります。

    NAME                AGE
bookinfo-gateway    32s

外部リクエスト

Bookinfo のゲートウェイ リソース（samples/bookinfo/networking/bookinfo-gateway.yaml で定義）は、事前構成の istio-ingressgateway を使用します。Anthos Service Mesh をデプロイするときに、istio-ingressgateway に NodePort を指定しました。これにより、サービス メッシュで特定のポートが開きます。ロードバランサを設定するまで、Bookinfo アプリケーションは GKE クラスタの外部（ブラウザなど）からアクセスできません。クラスタ内のノードには外部 IP アドレスが設定されていますが、クラスタの外部からのリクエストは Google Cloud ファイアウォール ルールによってブロックされます。IAP を使用すると、ロードバランサを使用してアプリケーションを公共のインターネットに公開できます。IAP をバイパスするファイアウォール ルールを使用してノードアドレスを公開しないでください。

Bookinfo にリクエストをルーティングするには、Google Cloud プロジェクトに HTTP(S) ロードバランサを設定します。ロードバランサはプロジェクト内にあります。これはファイアウォールの内側にあるため、クラスタ内のノードにアクセスできます。静的 IP アドレスとドメイン名を使用してロードバランサを構成すると、ドメイン名にリクエストを送信できるようになります。ロードバランサは、これらのリクエストをクラスタ内のノードに転送します。

ロードバランサのデプロイ

Ingress リソースを使用すると、自動構成の SSL 証明書で HTTP(S) ロードバランサを作成できます。Google マネージド SSL 証明書はドメインに対してプロビジョニング、更新、管理が行われます。

  1. ManagedCertificate リソースを作成します。このリソースは、SSL 証明書のドメインを指定します。spec.domains リストに複数のドメインを入れることはできません。ワイルドカード ドメインはサポートされていません。

    cat <<EOF | kubectl apply -f -
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: example-certificate
  namespace: istio-system
spec:
  domains:
    - ${DOMAIN_NAME}
EOF

  2. ロードバランサを作成するには、Ingress リソースを定義します。

    • 前の手順で作成した証明書の名前 example-certificate を networking.gke.io/managed-certificates アノテーションに設定します。

    • 予約した静的 IP アドレスの名前 example-static-ip を kubernetes.io/ingress.global-static-ip-name アノテーションに設定します。

    • serviceName を istio-ingressgateway に設定します。これは、Bookinfo サンプルのゲートウェイ リソースで使用されます。

    cat <<EOF | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example-ingress
  namespace: istio-system
  annotations:
    kubernetes.io/ingress.global-static-ip-name: example-static-ip
    networking.gke.io/managed-certificates: example-certificate
spec:
  backend:
    serviceName: istio-ingressgateway
    servicePort: 80
EOF

  3. Google Cloud コンソールで、[Kubernetes Engine] > [Services と Ingress] ページに移動します。

    [Services と Ingress] ページに移動

    [ステータス] 列に「Creating Ingress」と表示されます。GKE に Ingress が完全にプロビジョニングされてから次に進みます。数分ごとにページを更新し、Ingress の最新ステータスを確認します。Ingress がプロビジョニングされると、「OK」ステータスが表示されるか、「All backend services are in UNHEALTHY state.」というエラーが表示されます。デフォルトのヘルスチェックでは、GKE がプロビジョニングするリソースの 1 つが対象になります。エラー メッセージが表示された場合、Ingress がプロビジョニングされ、デフォルトのヘルスチェックが実行されています。「OK」ステータスまたはエラーが表示されている場合は、次のセクションでロードバランサのヘルスチェックを構成します。

ロードバランサのヘルスチェックを構成する

ヘルスチェックを構成するには、Ingress によって作成されたデフォルトのヘルスチェックの ID を取得してから、istio-ingress のヘルスチェックのパスとポートを使用するようにヘルスチェックを更新する必要があります。

  1. アプリケーションのデフォルト認証情報に使用する新しいユーザー認証情報を取得します。

      gcloud auth application-default login

  2. Ingress によって作成されたデフォルトのヘルスチェックの ID を取得します。

    1. 次の環境変数を設定します。

      • バックエンド サービス: 特定の Service NodePort にさまざまなインスタンス グループをブリッジします。

        BACKEND_SERVICE=$(gcloud compute url-maps list | grep example-ingress | awk '{print $2}' | cut -d'/' -f 2)

      • ヘルスチェック: Ingress のデプロイ時に自動的に作成されるデフォルトのヘルスチェック。

        HC=$(gcloud compute backend-services describe ${BACKEND_SERVICE} --global | grep healthChecks | cut -d'/' -f 10 | tail -n 1)

      • ヘルスチェックの Ingress ポート: istio-ingress のヘルスチェック ポート。

        export HC_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="status-port")].nodePort}')

      • ヘルスチェック Ingress パス: istio-ingress のヘルスチェック パス。

        export HC_INGRESS_PATH=$(kubectl -n istio-system get deployments istio-ingressgateway -o jsonpath='{.spec.template.spec.containers[?(@.name=="istio-proxy")].readinessProbe.httpGet.path}')

      • ヘルスチェック API: ヘルスチェックの構成で呼び出す API。
        export HC_API=https://compute.googleapis.com/compute/v1/projects/${PROJECT_ID}/global/healthChecks/${HC}

    2. デフォルトのヘルスチェックを JSON ファイルに挿入する際に healthChecks API を呼び出します。

      curl --request GET  --header "Authorization: Bearer $(gcloud auth application-default print-access-token)" ${HC_API} > health_check.json

  3. istio-ingress のヘルスチェックのパスとポートを使用するようにヘルスチェックを更新します。

    1. 次のように health_check.json ファイルを更新します。

      • httpHealthCheck.port を ${HC_INGRESS_PORT} の値に設定します。
      • httpHealthCheck.requestPath を ${HC_INGRESS_PATH} の値に設定します。
      • httpHealthCheck.portSpecification="" 属性を追加して、空の文字列に設定します。

      これを実現するには、Cloud Shell にプリインストールされている jq を使用するのが最も簡単な方法です。

      jq ".httpHealthCheck.port=${HC_INGRESS_PORT} | .httpHealthCheck.requestPath=\"${HC_INGRESS_PATH}\" | .httpHealthCheck.portSpecification=\"\"" health_check.json > updated_health_check.json

      結果の updated_health_check.json ファイルに対して cat を実行すると、次のようになります。

      {
"id": "5062913090021441698",
"creationTimestamp": "2019-11-12T10:47:41.934-08:00",
"name": "${HC}",
"description": "Default kubernetes L7 Loadbalancing health check.",
"checkIntervalSec": 60,
"timeoutSec": 60,
"unhealthyThreshold": 10,
"healthyThreshold": 1,
"type": "HTTP",
"httpHealthCheck": {
  "port": 32394,
  "requestPath": "/healthz/ready",
  "proxyHeader": "NONE",
  "portSpecification": ""
},
"selfLink": "https://www.googleapis.com/compute/v1/projects/${PROJECT_ID}/global/healthChecks/${HC}",
"kind": "compute#healthCheck"
}

      jq コマンドを使用せずに JSON ファイルを手動で編集した場合は、次のコマンドのファイル名と一致するように、ファイルを updated_health_check.json として保存します。

    2. ヘルスチェックを更新します。

      curl --request PATCH --header "Authorization: Bearer $(gcloud auth application-default print-access-token)" --header "Content-Type: application/json" --data @updated_health_check.json ${HC_API}

    GKE がヘルスチェックを更新するまでに数分かかります。Ingress のステータスが「OK」に変わるまで、Google Cloud コンソールの [Kubernetes Engine] > [Services と Ingress] ページを 1 分ごとに更新します。

  4. ロードバランサをテストします。ブラウザで次の URL にアクセスします。

    http://YOUR_DOMAIN_NAME/productpage

    ここで、YOUR_DOMAIN_NAME は、外部静的 IP アドレスで構成したドメイン名です。

    Bookinfo アプリケーションの productpage が表示されます。ページを複数回更新すると、さまざまなバージョンのビューがラウンドロビン スタイル（赤い星、黒い星、星なし）で表示されます。

    Bookinfo への https アクセスもテストする必要があります。

IAP の有効化

IAP を有効にする手順は以下のとおりです。

  1. list コマンドを使用して、既存のブランドがあるかどうかを確認します。1 つのプロジェクトで使用できるブランドは 1 つだけです。

    gcloud iap oauth-brands list

    ブランドがある場合の gcloud のレスポンスは次のとおりです。

    name: projects/[PROJECT_NUMBER]/brands/[BRAND_ID]
applicationTitle: [APPLICATION_TITLE]
supportEmail: [SUPPORT_EMAIL]
orgInternalOnly: true

  2. ブランドが存在しない場合は、create コマンドを使用します。

    gcloud iap oauth-brands create --application_title=APPLICATION_TITLE --support_email=SUPPORT_EMAIL

    上記のフィールドは、この API を呼び出すときに必要になります。

    • supportEmail: OAuth 同意画面に表示されるサポートメール。このメールアドレスは、ユーザーのアドレスでも、Google グループのエイリアスでもかまいません。サービス アカウントにもメールアドレスがありますが、これは実際のメールアドレスではないため、ブランドの作成には使用できません。ただし、サービス アカウントは Google グループのオーナーに設定できます。新しい Google グループを作成するか、既存のグループを構成し、目的のサービス アカウントをそのグループのオーナーに設定します。

    • applicationTitle: OAuth 同意画面に表示されるアプリケーション名。

    レスポンスには、次のフィールドが含まれます。

    name: projects/[PROJECT_NUMBER]/brands/[BRAND_ID]
applicationTitle: [APPLICATION_TITLE]
supportEmail: [SUPPORT_EMAIL]
orgInternalOnly: true

IAP OAuth クライアントの作成

  1. create コマンドを使用してクライアントを作成します。前のステップのブランド name を使用します。

    gcloud iap oauth-clients create projects/PROJECT_NUMBER/brands/BRAND-ID --display_name=NAME

    レスポンスには、次のフィールドが含まれます。

    name: projects/[PROJECT_NUMBER]/brands/[BRAND_NAME]/identityAwareProxyClients/[CLIENT_ID]
secret: [CLIENT_SECRET]
displayName: [NAME]

サービスの IAP の有効化

次のコマンドを使用して、サービスの IAP を有効にします。CLIENT_ID と CLIENT_SECRET は、以前に作成したクライアントの OAuth クライアント ID とクライアント シークレットに置き換えます。

gcloud beta iap web enable \
    --oauth2-client-id=CLIENT_ID \
    --oauth2-client-secret=CLIENT_SECRET \
    --resource-type=backend-services \
    --service=${BACKEND_SERVICE}

IAP アクセスリストを構成する

IAP のアクセス ポリシーにユーザーを追加するには:

gcloud beta iap web add-iam-policy-binding \
    --member=user:EMAIL_ADDRESS \
    --role=roles/iap.httpsResourceAccessor \
    --resource-type=backend-services \
    --service=$BACKEND_SERVICE

EMAIL_ADDRESS は、ユーザーの完全なメールアドレスです（例: alice@example.com）。

サービス メッシュで RCToken サポートを有効にする

デフォルトでは、IAP は OAuth クライアントをスコープとする JSON Web Token（JWT）を生成します。Anthos Service Mesh では、RequestContextToken（RCToken）を生成するように IAP を構成できます。これは、JWT ですが、オーディエンスは構成可能です。RCToken を使用すると、JWT のオーディエンスに任意の文字列を構成できます。これを Anthos Service Mesh ポリシーで使用し、きめ細かい認証を実施できます。

RCToken を構成するには:

  1. プロジェクト番号の環境変数を作成します。これは、プロジェクトの作成時に自動的に生成され、割り当てられた番号です（プロジェクト ID とは異なります）。

    export PROJECT_NUMBER=YOUR_PROJECT_NUMBER

  2. RCToken オーディエンスの環境変数を作成します。任意の文字列を指定できます。

    export RCTOKEN_AUD="your-rctoken-aud"

  3. 既存の IAP 設定を取得します。

    gcloud beta iap settings get --format json \
--project=${PROJECT_NUMBER} --resource-type=compute \
--service=${BACKEND_SERVICE} > iapSettings.json

  4. RCToken オーディエンスで IapSettings を更新します。

    cat iapSettings.json | jq --arg RCTOKEN_AUD_STR $RCTOKEN_AUD \
'. + {applicationSettings: {csmSettings: {rctokenAud: $RCTOKEN_AUD_STR}}}' \
> updatedIapSettings.json

    gcloud beta iap settings set updatedIapSettings.json --format json \
--project=${PROJECT_NUMBER} --resource-type=compute --service=${BACKEND_SERVICE}

  5. Istio Ingress ゲートウェイで RCToken 認証を有効にします。

    cat <<EOF | kubectl apply -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "ingressgateway"
  namespace: istio-system
spec:
  targets:
  - name: "istio-ingressgateway"
  origins:
  - jwt:
      issuer: "https://cloud.google.com/iap"
      jwksUri: "https://www.gstatic.com/iap/verify/public_key-jwk"
      audiences:
      - "$RCTOKEN_AUD"
      jwt_headers:
      - "ingress-authorization"
      trigger_rules:
      - excluded_paths:
        - exact: /healthz/ready
  principalBinding: USE_ORIGIN
EOF

  6. Bookinfo productpage へのリクエストが成功していることを確認します。

    http://DOMAIN_NAME/productpage

ポリシーをテストするには:

  1. IapSettings リクエスト オブジェクトを作成します。ただし、rctokenAud には別の文字列を設定します。

    echo $(cat <<EOF
{
   "name": "projects/${PROJECT_NUMBER}/iap_web/compute/services/${BACKEND_SERVICE}",
   "applicationSettings": {
     "csmSettings": {
       "rctokenAud": "some-other-arbitrary-string"
     }
   }
 }
EOF
) > request.txt

  2. IapSettings API を呼び出して、RCtoken オーディエンスを設定します。

    curl --request PATCH --header "Authorization: Bearer $(gcloud beta auth application-default print-access-token)" ${IAP_SETTINGS_API}

  3. Bookinfo productpage にリクエストを送信すると失敗します。

    http://DOMAIN_NAME/productpage

クリーンアップ

このチュートリアルを完了したら、アカウントで不要な請求が発生しないように、以下のリソースを削除します。

  1. マネージド証明書を削除します。

    kubectl delete managedcertificates example-certificate

  2. Ingress を削除します。これにより、負荷分散リソースの割り当てが解除されます。

    kubectl -n istio-system delete ingress example-ingress

  3. 静的 IP アドレスを削除します。

    gcloud compute addresses delete example-static-ip --global

    これを行う場合は、ドメイン登録事業者から IP アドレスを削除してください。

  4. クラスタを削除します。これにより、クラスタを構成するリソース（コンピューティング インスタンス、ディスク、ネットワーク リソースなど）が削除されます。

    gcloud container clusters delete ${CLUSTER_NAME}