このチュートリアルでは、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 アドレスを使用できます。
目標
- 設定を行う。
- Google Cloud プロジェクトを設定し、権限を付与して、IAP で必要な Google API を有効にする。
- 外部静的 IP アドレスを予約し、ロードバランサで必要となる IP アドレスを使用するようにドメイン名を構成する。
- IAP と Anthos Service Mesh の統合に必要なオプションを使用して、新しい Google Kubernetes Engine(GKE)クラスタを設定する。
- 統合に必要なオプションを使用して Anthos Service Mesh をインストールする。
- サンプル アプリケーションをデプロイする。
- ロードバランサをデプロイする。
IAP を有効にする。
サービス メッシュで RCToken サポートを有効にする。
費用
このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
始める前に
要件
Anthos の試用版ライセンスまたはサブスクリプションが必要です。詳細については、Anthos 料金ガイドをご覧ください。
GKE クラスタは次の要件を満たす必要があります。
- 少なくとも 4 つのノード。
- 最小のマシンタイプが 4 つの vCPU を備えた
e2-standard-4
。 - 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 を使用するには:
- Google Cloud コンソールに移動します。
- Google Cloud プロジェクトを選択します。
Google Cloud コンソール ウィンドウの上部にある [Cloud Shell をアクティブにする] ボタンをクリックします。
Google Cloud コンソールの一番下にある新しいフレームの中で Cloud Shell セッションが開き、コマンドライン プロンプトが表示されます。
コンポーネントを更新します。
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 ...
long コマンドをコピーし、貼り付けてコンポーネントを更新します。
kubectl
をインストールします。sudo apt-get install kubectl
kpt
をインストールします。sudo apt-get install google-cloud-sdk-kpt
オプション B: ローカルのコマンドライン ツールを使用する
ローカルマシンに gcloud CLI をインストールして初期化します。
Google Cloud CLI で認証します。
gcloud auth login
コンポーネントを更新します。
gcloud components update
kubectl
をインストールします。gcloud components install kubectl
kpt
をインストールします。gcloud components install kpt
プロジェクトの設定
-
クラスタが作成されるプロジェクトのプロジェクト ID を取得します。
gcloud
gcloud projects list
コンソール
- Google Cloud コンソールで、[ダッシュボード] ページに移動します。
-
ページ上部の [選択元] プルダウン リストをクリックします。表示された [選択元] ウィンドウで、プロジェクトを選択します。
プロジェクト ID は、プロジェクト ダッシュボードの [プロジェクト情報] カードに表示されます。
- プロジェクト ID の環境変数を作成します。
export PROJECT_ID=YOUR_PROJECT_ID
-
gcloud
コマンドライン ツールのデフォルトのプロジェクト ID を設定します。gcloud config set project ${PROJECT_ID}
- プロジェクト番号の環境変数を作成します。
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
-
必要な 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 のインストールに必要な権限をご覧ください。
- 次の 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 アドレスを予約すると、明示的に解放するまで、このアドレスを無期限でプロジェクトに割り当てることができます。
静的外部 IP アドレスを予約します。
gcloud compute addresses create example-static-ip --global
静的 IP アドレスを取得します。
gcloud compute addresses describe example-static-ip --global
ドメイン名登録事業者で、静的 IP アドレスを含む完全修飾ドメイン名(FQDN)を構成します。通常、DNS 設定に
A
レコードを追加します。FQDN のA
レコードを追加する構成手順と用語は、使用するドメイン名登録事業者によって異なります。環境変数にドメイン名を設定します。
export DOMAIN_NAME=YOUR_DOMAIN_NAME
DNS 設定が反映されるまでに、24~48 時間かかります。このチュートリアルに従って設定を続けられますが、DNS 設定が反映されるまで設定のテストはできません。
新しい GKE クラスタの設定
新しいクラスタを設定するには:
新しいクラスタのゾーン、マシンタイプ、GKE リリース チャンネルを選択します。Anthos Service Mesh で必要最小限なマシンタイプは n1-standard-4 です。任意のリリース チャンネル オプションを使用できます。
使用可能な GCP ゾーンの一覧を取得するには:
gcloud compute zones list
マシンタイプのリストを取得するには:
gcloud compute machine-types list | more
次の環境変数を作成します。
クラスタ名を設定します。
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}"
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
を選択します。
認証情報と権限の設定
- プロジェクトを初期化してインストールの準備をします。次のコマンドでサービス アカウントを作成し、サイドカー プロキシなどの 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 をインストールする場合は、コマンドを再実行する必要はありませんが、コマンドを再実行してもインストールには影響しません。
-
クラスタとやり取りするために必要な認証情報を取得します。
gcloud container clusters get-credentials ${CLUSTER_NAME}
-
現在のユーザーにクラスタ管理者の権限を付与します。この権限は、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 ファイルが必要です。最小権限の原則に従い、登録するクラスタごとに個別のサービス アカウントを作成することをおすすめします。
サービス アカウントとキーファイルを作成するには:
サービス アカウントの名前を選択して、その環境変数を作成します。
export SERVICE_ACCOUNT_NAME=SERVICE_ACCOUNT_NAME
サービス アカウントを作成します。
gcloud iam service-accounts create ${SERVICE_ACCOUNT_NAME}
プロジェクトのサービス アカウントをすべて一覧表示して、サービス アカウントが作成されたことを確認します。
gcloud iam service-accounts list
サービス アカウントに 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"
JSON ファイルを保存するローカル ファイルパスの環境変数を作成します。ファイル名にサービス アカウント名とプロジェクト ID を使用することをおすすめします(例:
/tmp/creds/${SERVICE_ACCOUNT_NAME}-${PROJECT_ID}.json
)。export SERVICE_ACCOUNT_KEY_PATH=LOCAL_KEY_PATH
サービス アカウントの秘密鍵の 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
コマンドを実行します。
- Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-linux.tar.gz
- 署名ファイルをダウンロードし、
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
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
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 ではサポートされていません)。
- Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-osx.tar.gz
- 署名ファイルをダウンロードし、
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
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
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 ではサポートされていません)。
- Anthos Service Mesh インストール ファイルを現在の作業ディレクトリにダウンロードします。
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.5.10-asm.2-win.zip
- 署名ファイルをダウンロードし、
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
です。 -
ファイル システム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
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 ではサポートされていません)。
- Anthos Service Mesh インストールのルート ディレクトリに移動していることを確認します。
cd istio-1.5.10-asm.2
- 利便性を考えて、
/bin
ディレクトリ内のツールを PATH に追加します。export PATH=$PWD/bin:$PATH
Linux
Mac OS
Windows
リソース構成ファイルの準備
istioctl apply command
を実行して Anthos Service Mesh をインストールする際には、コマンドラインで -f istio-operator.yaml
を指定します。このファイルには、メッシュ テレメトリーとメッシュ セキュリティの機能を有効にするために必要なプロジェクトとクラスタに関する情報が含まれます。istio-operator.yaml
と他のリソース構成ファイルをダウンロードして、プロジェクトとクラスタの情報を設定する必要があります。
リソース構成ファイルを準備するには:
まだ行っていない場合は、
kpt
をインストールします。gcloud components install kpt
必要に応じて、Anthos Service Mesh パッケージのリソース構成ファイル用に新しいディレクトリを作成します。複数のクラスタを設定する場合は、クラスタ名をディレクトリ名として使用できます。
Anthos Service Mesh パッケージをダウンロードするディレクトリに変更します。
Anthos Service Mesh パッケージを現在の作業ディレクトリにダウンロードします。
kpt pkg get \ https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.5-asm .
クラスタ名を設定します。
kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}
必要に応じて、
kpt
セッターを使用してリソース構成ファイルをカスタマイズします。デフォルトでは、これらのセッターはgcloud config
のデフォルトを使用します。gcloud config
のデフォルトを設定する場合、または値を変更する場合は、次のセッターを実行します。プロジェクト ID を設定します。
kpt cfg set asm gcloud.core.project ${PROJECT_ID}
デフォルトのゾーンまたはリージョンを設定します。
kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}
また、リソース構成ファイルを 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
コマンドは、以下を確認する基本的なテストを実行します。
- Anthos Service Mesh で必要な API がプロジェクトで有効になっている。
- Istio-Ingressgateway が Mesh CA を呼び出すよう適切に構成されている。
- Istiod と Istio-Ingressgateway の全般的な状態。
オプションの --with-testing-workloads
フラグを使用して asmctl validate
コマンドを実行した場合、基本テストに加えて、asmctl
は以下を確認するセキュリティ テストを実行します。
- 相互 TLS(mTLS)通信が適切に構成されている。
- メッシュ CA が証明書を発行できる。
セキュリティ テストを行う際に asmctl
はクラスタ上のテスト用名前空間にワークロードをデプロイします。mTLS 通信のテストを実行して結果を出力し、テスト用名前空間を削除します。
asmctl
を実行するには:
gcloud application-default 認証情報が設定されていることを確認します。
gcloud auth application-default login
まだ行っていない場合は、クラスタとのやり取りに必要な認証情報を取得します。
gcloud container clusters get-credentials ${CLUSTER_NAME}
基本テストとセキュリティ テストの両方を実行するには(
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 を有効にします。
アプリケーション サービスを開始する
Anthos Service Mesh がインストールされたルート ディレクトリに移動します。
自動サイドカー インジェクションを使用するため、
default
名前空間にラベルを付けます。kubectl label namespace default istio-injection=enabled
アプリケーションをデプロイします。
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
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 すべての 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
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>
アプリケーションの Ingress ゲートウェイと仮想サービスを定義します。
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
ゲートウェイが作成されたことを確認します。
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 証明書はドメインに対してプロビジョニング、更新、管理が行われます。
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
ロードバランサを作成するには、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
Google Cloud コンソールで、[Kubernetes Engine] > [Services と Ingress] ページに移動します。
[ステータス] 列に「Creating Ingress」と表示されます。GKE に Ingress が完全にプロビジョニングされてから次に進みます。数分ごとにページを更新し、Ingress の最新ステータスを確認します。Ingress がプロビジョニングされると、「OK」ステータスが表示されるか、「All backend services are in UNHEALTHY state.」というエラーが表示されます。デフォルトのヘルスチェックでは、GKE がプロビジョニングするリソースの 1 つが対象になります。エラー メッセージが表示された場合、Ingress がプロビジョニングされ、デフォルトのヘルスチェックが実行されています。「OK」ステータスまたはエラーが表示されている場合は、次のセクションでロードバランサのヘルスチェックを構成します。
ロードバランサのヘルスチェックを構成する
ヘルスチェックを構成するには、Ingress によって作成されたデフォルトのヘルスチェックの ID を取得してから、istio-ingress のヘルスチェックのパスとポートを使用するようにヘルスチェックを更新する必要があります。
アプリケーションのデフォルト認証情報に使用する新しいユーザー認証情報を取得します。
gcloud auth application-default login
Ingress によって作成されたデフォルトのヘルスチェックの ID を取得します。
次の環境変数を設定します。
バックエンド サービス: 特定の 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}
デフォルトのヘルスチェックを JSON ファイルに挿入する際に
healthChecks
API を呼び出します。curl --request GET --header "Authorization: Bearer $(gcloud auth application-default print-access-token)" ${HC_API} > health_check.json
istio-ingress のヘルスチェックのパスとポートを使用するようにヘルスチェックを更新します。
次のように
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
として保存します。ヘルスチェックを更新します。
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 分ごとに更新します。
ロードバランサをテストします。ブラウザで次の URL にアクセスします。
http://YOUR_DOMAIN_NAME/productpage
ここで、
YOUR_DOMAIN_NAME
は、外部静的 IP アドレスで構成したドメイン名です。Bookinfo アプリケーションの
productpage
が表示されます。ページを複数回更新すると、さまざまなバージョンのビューがラウンドロビン スタイル(赤い星、黒い星、星なし)で表示されます。Bookinfo への
https
アクセスもテストする必要があります。
IAP の有効化
IAP を有効にする手順は以下のとおりです。
同意画面の構成
list コマンドを使用して、既存のブランドがあるかどうかを確認します。1 つのプロジェクトで使用できるブランドは 1 つだけです。
gcloud iap oauth-brands list
ブランドがある場合の gcloud のレスポンスは次のとおりです。
name: projects/[PROJECT_NUMBER]/brands/[BRAND_ID] applicationTitle: [APPLICATION_TITLE] supportEmail: [SUPPORT_EMAIL] orgInternalOnly: true
ブランドが存在しない場合は、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 クライアントの作成
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 を構成するには:
プロジェクト番号の環境変数を作成します。これは、プロジェクトの作成時に自動的に生成され、割り当てられた番号です(プロジェクト ID とは異なります)。
export PROJECT_NUMBER=YOUR_PROJECT_NUMBER
RCToken オーディエンスの環境変数を作成します。任意の文字列を指定できます。
export RCTOKEN_AUD="your-rctoken-aud"
既存の IAP 設定を取得します。
gcloud beta iap settings get --format json \ --project=${PROJECT_NUMBER} --resource-type=compute \ --service=${BACKEND_SERVICE} > iapSettings.json
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}
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
Bookinfo
productpage
へのリクエストが成功していることを確認します。http://DOMAIN_NAME/productpage
ポリシーをテストするには:
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
IapSettings
API を呼び出して、RCtoken オーディエンスを設定します。curl --request PATCH --header "Authorization: Bearer $(gcloud beta auth application-default print-access-token)" ${IAP_SETTINGS_API}
Bookinfo
productpage
にリクエストを送信すると失敗します。http://DOMAIN_NAME/productpage
クリーンアップ
このチュートリアルを完了したら、アカウントで不要な請求が発生しないように、以下のリソースを削除します。
マネージド証明書を削除します。
kubectl delete managedcertificates example-certificate
Ingress を削除します。これにより、負荷分散リソースの割り当てが解除されます。
kubectl -n istio-system delete ingress example-ingress
静的 IP アドレスを削除します。
gcloud compute addresses delete example-static-ip --global
これを行う場合は、ドメイン登録事業者から IP アドレスを削除してください。
クラスタを削除します。これにより、クラスタを構成するリソース(コンピューティング インスタンス、ディスク、ネットワーク リソースなど)が削除されます。
gcloud container clusters delete ${CLUSTER_NAME}