Anthos Service Mesh 1.10 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

HSM と Vault を使用してオンプレミスに Anthos Service Mesh をインストールする

このガイドでは、既存の GKE on VMware に Anthos Service Mesh をインストールし、Thales Luna HSM 7+ と Hashicorp Vault を使用して安全に Istiod の CA 署名鍵を生成して CA 署名鍵を保護する方法について説明します。

以前のバージョンの Anthos Service Mesh がインストールされている場合は、GKE on VMware での Anthos Service Mesh のアップグレードをご覧ください。このインストールにより、クラスタでサポートされる機能が有効になります。

始める前に

次の要件を確認してから設定を開始してください。

要件

Anthos のサブスクリプションが必要です。また、Google Cloud の GKE Enterprise の場合のみ、従量課金制の請求オプションを使用できます。詳細については、GKE Enterprise 料金ガイドをご覧ください。
イメージにアクセスする権限を付与するよう、サポートチームにお問い合わせいただく必要があります。サポートチームが、お客様にサポートを提供いたします。
Anthos Service Mesh をインストールするクラスタには、少なくとも 4 つの vCPU、15 GB のメモリ、4 つのノードがあることを確認します。
サービスポートには、name: protocol[-suffix] の構文を使用して名前を指定する必要があります。角かっこはオプションの接尾辞を示しており、この接尾辞は先頭をダッシュにする必要があります。詳細については、サービスポートの命名をご覧ください。
クラスタバージョンがサポートされる環境に含まれていることを確認します。クラスタのバージョンを確認するには、gkectl コマンドラインツールを使用します。gkectl がインストールされていない場合は、GKE On-Prem のダウンロードをご覧ください。
```
gkectl version
```
お使いのインフラストラクチャに Thales Luna HSM 7+ が必要です。HSM にネットワークサービスをセットアップして、Anthos Service Mesh クラスタから到達できるようにする必要があります。
HSM にアクセスするための認証情報を保存するインフラストラクチャに、Hashicorp Vault サーバーが存在するはずです。Vault サーバーは、Anthos Service Mesh クラスタからネットワーク経由で到達できるようにする必要があります。

環境の設定

Anthos Service Mesh のインストールプロセスを制御するマシンに、次のツールをインストールします。

curl コマンドラインツール
Google Cloud CLI

前もって必要なツールをインストールしたら、次の手順を行います。

gcloud CLI を使用して認証します。
```
gcloud auth login --project PROJECT_ID
```
コンポーネントを更新します。
```
gcloud components update
```
kubectl をインストールします。
```
gcloud components install kubectl
```
Online Boutique のサンプルアプリケーションでインストールをデプロイしてテストする場合は、kpt をインストールします。
```
gcloud components install kpt
```
コンテキストをユーザークラスタに切り替えます（必要な場合）。
```
kubectl config use-context CLUSTER_NAME
```
ユーザーアカウント（Google Cloud ログインメールアドレス）にクラスタ管理者の権限を付与します。この権限は、Anthos Service Mesh に必要なロールベースのアクセス制御（RBAC）ルールを作成するのに必要です。
```
kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user=USER_ACCOUNT
```

依存関係をデプロイする

Istiod の CA 署名鍵を安全に管理するために、Thales Luna HSM 7+ をご利用のインフラストラクチャにデプロイします。HSM のネットワークサービスが Anthos Service Mesh クラスタと接続していることを確認します。
インフラストラクチャに Hashicorp Vault サーバーをデプロイして、HSM にアクセスするための認証情報を保存します。Vault サーバーが Anthos Service Mesh クラスタとネットワーク接続していることを確認します。
Vault サーバー、HSM および Anthos Service Mesh をインストールする Kubernetes クラスタにアクセスできるワークステーションを用意します。

ハードウェアセキュリティモジュール（HSM）を設定する

このセクションでは、ハードウェアセキュリティモジュール（HSM）を設定し、暗号鍵を生成する手順を示します。

HSM の認証情報とスロットをプロビジョニングする

HSM インストールガイドに従って次の手順を実施してください。

HSM をネットワーク HSM として設定します。
HSM で mTLS 接続用の PEM ファイルをプロビジョニングします。これにはクライアント鍵ファイル、クライアント証明書ファイル、サーバー証明書ファイルも含まれます。
Anthos Service Mesh の HSM スロットをプロビジョニングし、スロットラベルと PIN を記録します。

HSM 鍵暗号鍵（KEK）を生成する

HSM にアクセスできるマシンで、HSM ツールをダウンロードします（Linux amd-64 でのみ使用できます）。
```
gsutil cp gs://artifacts.thalescpl-io-k8s-kms-plugin.appspot.com/binary/k8s-kms-plugin .
```

環境変数を設定してから、HSM ツールをローカルサーバーとして実行します。このサーバーは HSM に接続して、ローカル Unix ドメインソケット（UDS）となります。

export P11_TOKEN=HSM slot label
export ChrystokiConfigurationPath=path to the Thales HSM Chrystoki configuration file
export P11_LIB=path to the libCryptoki2.so file for accessing the Thales HSM
export P11_PIN_FILE=path to the file that stores the HSM slot PIN
export SOCKET=/tmp/.hsm-sock
./k8s-kms-plugin serve &

出力は次のようになることが想定されます。

The token has been initialized and is reassigned to slot 412789065
INFO Loaded P11 PIN from file: /home/hsm/hsm-credential/pin  line="cmd/serve.go:93"
INFO KMS Plugin Listening on : /var/.hsm-sock  line="cmd/serve.go:119"
INFO Serving on socket: /tmp/.hsm-sock  line="cmd/serve.go:198"

HSM に鍵暗号鍵（KEK）がない場合は、次の手順で鍵を生成します。k8s-kms-plugin をクライアントとして使用して、HSM ツールサーバーと通信します。KEK ID を明示的に指定する場合は、コマンドで --kek-id フラグを渡します。それ以外の場合は、ランダムな KEK ID が自動的に生成されます。
```
./k8s-kms-plugin generate-kek --kek-id KEK ID
```
KEK ID を記録します。これは次の手順で使用します。
HSM はインポートされたルート証明書を使用して、署名済みの Istio CA 証明書を検証します。この手順に沿って、ルート証明書を HSM にインポートできます。k8s-kms-plugin をクライアントとして使用して、HSM ツールサーバーと通信します。次のコマンドを使用して、ルート証明書をインポートします。
```
./k8s-kms-plugin import-ca -f root cert PEM file
```

Vault 認証用に Kubernetes を設定する

Kubernetes クラスタで、TokenReview API を呼び出すために Vault 専用のサービスアカウントと RBAC ポリシーを作成します。この目的専用の Namespace を作成します。
vault Namespace にデフォルトのサービスアカウントを作成して権限を設定し、Vault サーバーに関連付けられた JSON Web Token（JWT）を抽出して、Kubernetes TokenReview API を呼び出します。注: 十分な権限があれば、Kubernetes サービスアカウントと Namespace を使用できます。
設定するクラスタのクラスタサフィックスを構成します。構成専用のディレクトリを使用します。
```
export CLUSTER_SUFFIX="c1"
mkdir ${CLUSTER_SUFFIX}
cd ${CLUSTER_SUFFIX}
```
管理するクラスタに切り替えて、vault Namespace を作成します。kubectl により、デフォルトのサービスアカウントが自動的に作成されます。
```
kubectl create ns vault
```

権限を付与するには、サービスアカウント default.vault を auth-delegator ロールにバインドします。

kubectl apply -f -<< EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: role-tokenreview-binding
 namespace: vault
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
 - kind: ServiceAccount
   name: default
   namespace: vault
EOF

トークンの認証情報を保持するシークレットを作成します。

VAULT_SA_SECRET=default-token
kubectl apply -n vault -f - << EOF
apiVersion: v1
kind: Secret
metadata:
 name: "${VAULT_SA_SECRET}"
 annotations:
   kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

サービスアカウント default.vault の JWT を取得します。

VAULT_SA_JWT_TOKEN=$(kubectl get -n vault secret $VAULT_SA_SECRET -o jsonpath="{.data.token}" | base64 --decode)
echo $VAULT_SA_JWT_TOKEN > ${CLUSTER_SUFFIX}-tokenreview_jwt
cat ${CLUSTER_SUFFIX}-tokenreview_jwt

Kubernetes API サーバーのアドレスと CA 証明書を取得します。後で、Kubernetes API サーバーを呼び出すように Vault サーバーを構成します。

Kubernetes 公開 IP:Port 値を取得します。

K8S_ADDR=$(kubectl config  view -o jsonpath="{.clusters[?(@.name == '$(kubectl config current-context)')].cluster.server}")
echo $K8S_ADDR > ${CLUSTER_SUFFIX}-k8s_addr
cat ${CLUSTER_SUFFIX}-k8s_addr

Kubernetes API サーバーの認証用の証明書を取得します。

VAULT_SA_CA_CRT=$(kubectl get -n vault secret $VAULT_SA_SECRET -o jsonpath="{.data['ca\.crt']}" | base64 --decode)
echo $VAULT_SA_CA_CRT > "${CLUSTER_SUFFIX}-k8s_cert"
cat "${CLUSTER_SUFFIX}-k8s_cert"

証明書ファイルを PEM ファイル形式に変換して検証します。

sed -i 's/ CERTIFICATE/CERTIFICATE/g' ${CLUSTER_SUFFIX}-k8s_cert
sed -i 's/ /\n/g' ${CLUSTER_SUFFIX}-k8s_cert
sed -i 's/CERTIFICATE/ CERTIFICATE/g' ${CLUSTER_SUFFIX}-k8s_cert

証明書が有効であることを確認します。

openssl x509 -in ${CLUSTER_SUFFIX}-k8s_cert -noout -text

前のディレクトリに戻ります。
```
cd ..
```

次に、クラスタのディレクトリにある 3 つのファイルを使用して、次の手順で Vault を構成します。

Vault を設定して HSM 認証情報を保存する

Vault サーバーが有効な証明書を使用して TLS トラフィックを配信する場合は、Vault PKI を構成し、Kubernetes 認証を構成します。次に、単一のルート CA とクラスタ別の中間 CA を設定する例を示します。

root として Vault にログインします。
```
vault login
```

HSM のシークレットを保存します。

SECRET_PATH=asm-$CLUSTER_SUFFIX
vault secrets enable -path=$SECRET_PATH  kv
vault secrets tune -max-lease-ttl=87600h $SECRET_PATH
export HSM_SECRET_PATH="$SECRET_PATH/hsm"
vault kv put ${HSM_SECRET_PATH} clientcert=HSM_CLIENT_CERT clientkey=HSM_CLIENT_KEY servercert=HSM_SERVER_CERT PIN=HSM_PIN
vault kv get ${HSM_SECRET_PATH}

PKI パスに対する権限を持つポリシーを作成します。

vault policy write asm-$CLUSTER_SUFFIX-hsm-policy -<< EOF
path "${HSM_SECRET_PATH}" {
capabilities = ["read"]
}
EOF

クラスタの Kubernetes 認証を追加します。

vault auth enable --path="${HSM_SECRET_PATH}"  kubernetes

Kubernetes JWT、Kubernetes アドレス、Kubernetes CA 証明書を Vault 認証パスに設定します。

vault write auth/${HSM_SECRET_PATH}/config \
token_reviewer_jwt=cat "${CLUSTER_SUFFIX}"-tokenreview_jwt \
kubernetes_host=cat "${CLUSTER_SUFFIX}"-k8s_addr \
kubernetes_ca_cert=@"${CLUSTER_SUFFIX}"-k8s_cert

istiod-service-account.istio-system に demo ロールとして認証することを許可し、作成されたポリシーを使用します。

vault write auth/${HSM_SECRET_PATH}/role/istiod \
bound_service_account_names=istiod-service-account \
bound_service_account_namespaces=istio-system \
policies=asm-$CLUSTER_SUFFIX-hsm-policy \
ttl=768h

親フォルダに戻ります。
```
cd ..
```

インストールファイルをダウンロードする

Linux

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-linux-amd64.tar.gz
```

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.10.6-asm.2-linux-amd64.tar.gz.1.sig istio-1.10.6-asm.2-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

ファイルシステム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
```
 tar xzf istio-1.10.6-asm.2-linux-amd64.tar.gz
```
このコマンドにより、現在の作業ディレクトリに istio-1.10.6-asm.2 という名前のインストールディレクトリが作成されます。このディレクトリには、次のものが含まれます。
- samples ディレクトリにあるサンプルアプリケーション。
- Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
- Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。
```
cd istio-1.10.6-asm.2
```

Mac OS

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-osx.tar.gz
```

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.10.6-asm.2-osx.tar.gz.1.sig istio-1.10.6-asm.2-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

ファイルシステム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
```
tar xzf istio-1.10.6-asm.2-osx.tar.gz
```
このコマンドにより、現在の作業ディレクトリに istio-1.10.6-asm.2 という名前のインストールディレクトリが作成されます。このディレクトリには、次のものが含まれます。
- samples ディレクトリにあるサンプルアプリケーション。
- Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
- Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。
```
cd istio-1.10.6-asm.2
```

Windows

Anthos Service Mesh インストールファイルを現在の作業ディレクトリにダウンロードします。
```
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-win.zip
```

署名ファイルをダウンロードし、openssl を使用して署名を検証します。

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.10.6-asm.2-win.zip.1.sig
openssl dgst -verify - -signature istio-1.10.6-asm.2-win.zip.1.sig istio-1.10.6-asm.2-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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

ファイルシステム上の任意の場所にファイルの内容を抽出します。たとえば、現在の作業ディレクトリにコンテンツを抽出するには、次のコマンドを実行します。
```
tar xzf istio-1.10.6-asm.2-win.zip
```
このコマンドにより、現在の作業ディレクトリに istio-1.10.6-asm.2 という名前のインストールディレクトリが作成されます。このディレクトリには、次のものが含まれます。
- samples ディレクトリにあるサンプルアプリケーション。
- Anthos Service Mesh のインストールに使用する istioctl コマンドラインツールは、bin ディレクトリにあります。
- Anthos Service Mesh 構成プロファイルは manifests/profiles ディレクトリにあります。
Anthos Service Mesh インストールのルートディレクトリに移動していることを確認します。
```
cd istio-1.10.6-asm.2
```

コントロールプレーンでリソースを設定する

環境変数を設定します。

export CLUSTER_SUFFIX="c1"
export VAULT_ADDR="https://VAULT_IP:PORT"

Vault を認証するための証明書を含むファイルを、cert という名前のファイルにコピーします。Vault サーバーの TLS 証明書 ${VAULT_CACERT} などが考えられます。

注: Vault クライアントはこの証明書を使用して Vault サーバーの認証を行います。この証明書は、Vault が Kubernetes API サーバーの認証に使用する証明書とは異なります。
```
cp ${VAULT_CACERT} ./cert
```

Namespace istio-system 内のファイルから ConfigMap を作成します。

kubectl create ns istio-system
kubectl delete configmap vault-tls-cert -n istio-system
kubectl create configmap vault-tls-cert -n istio-system --from-file=./cert

検証 Webhook の構成

Anthos Service Mesh をインストールするときに、istiod にリビジョンラベルを設定します。検証 Webhook に同じリビジョンを設定する必要があります。

次の YAML を istiod-service.yaml という名前のファイルにコピーします。

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1106-2
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1106-2

Anthos Service Mesh をインストールする

環境変数を設定して、Vault および HSM とやり取りするように ASM を構成します。次のコマンドは、オペレーターがインポートオペレーションを保留にしているために Istiod を完全には使用できないため、待機時間を 10 秒に短縮します。

export HSM_SLOT_LABEL=the HSM slot label
export VAULT_ADDR=address of the vault server
export HSM_SECRET_PATH=the path to the HSM secret on Vault
export KEK_ID=the HSM slot KEK ID
export HSM_PLUGIN_IMAGE=gcr.io/thalescpl-io-k8s-kms-plugin/hsm-plugin:asm-1.7-1
export VAULT_CLIENT_IMAGE=gcr.io/gke-release/asm/vaultclient:latest
export WAIT_FOR_RESOURCES_TIMEOUT=10s

次のコマンドを実行し、asm-multicloud プロファイルを使用して Anthos Service Mesh をインストールします。サポートされているオプション機能を有効にするには、コマンドラインで -f と YAML のファイル名を指定します。詳細については、オプション機能の有効化をご覧ください。

istioctl install --set profile=asm-multicloud \
   --set revision=asm-1106-2 \
   --set values.hsm.enabled=true \
   --set values.hsm.hsmKEKID=${KEK_ID} \
   --set values.hsm.hsmPluginImage=${HSM_PLUGIN_IMAGE} \
   --set values.hsm.hsmSlotLabel=${HSM_SLOT_LABEL} \
   --set values.hsm.vaultClientImage=${VAULT_CLIENT_IMAGE} \
   --set values.hsm.vaultAddr=${VAULT_ADDR} \
   --set values.hsm.vaultAuthPath=auth/${HSM_SECRET_PATH}/login \
   --set values.hsm.vaultAuthRole=istiod \
   --set values.hsm.vaultAuthJwtPath="/var/run/secrets/kubernetes.io/serviceaccount/token" \
   --set values.hsm.vaultSecretPath=${HSM_SECRET_PATH} \
   --set values.global.jwtPolicy="first-party-jwt"

検証 Webhook を構成して、リビジョンラベルで istiod サービスを検出できるようにします。
```
kubectl apply -f istiod-service.yaml
```
このコマンドは、構成の適用前に検証 Webhook が構成を自動的にチェックするサービスエントリを作成します。
Istiod が正しく初期化され、ステータスが待機中であることを確認します。
```
kubectl get pod -l app=istiod -n istio-system
```
次のような出力が想定されます。
```
NAME                      READY   STATUS    RESTARTS   AGE
istiod-66ff56d76c-f9p5l   2/3     Running   2          1m27s
```
discovery コンテナがブロックされ、証明書を待機しているため、Istiod の準備が完了していないことを確認します。

Istiod コンテナのログを調べて、コンテナが適切な状態にあることを確認します。

kubectl logs -c hsm-plugin -l app=istiod -n istio-system

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

The token has been initialized and is reassigned to slot 412789065
INFO Loaded P11 PIN from file: /var/run/hsm-credential/pin  line="cmd/serve.go:93"
INFO KMS Plugin Listening on : /var/run/hsm-socket/.sock  line="cmd/serve.go:119"
INFO Serving on socket: /var/run/hsm-socket/.sock  line="cmd/serve.go:198"
KEK ID: 7651a4ea-eeb7-4c1f-927b-8c871c2127aa

kubectl logs -c discovery -l app=istiod -n istio-system

出力の最後の行は次のようになることが想定されます。

...
2020-10-15T21:56:56.918931Z info    pkica   Wait until the CA certificate secret istio-system.istio-ca-cert can be loaded...

Istiod の証明書に署名する

暗号化された CSR を Kubernetes Secret からダウンロードします。

kubectl get secret istio-ca-cert-csr -n istio-system -o jsonpath={.data} > encrypted_csr.json

CSR を復号します。

kubectl get secret istio-ca-cert-csr -n istio-system -o jsonpath={.data} > encrypted_csr.json
./k8s-kms-plugin decrypt-csr -f encrypted_csr.json -o csr.pem

セキュリティ管理者は、csr.pem ファイルを取得し、ルート CA を使用して署名する必要があります。
証明書チェーンを cert-chain.pem という名前のファイルのルートにして、次のコマンドを実行します。
```
kubectl create secret generic istio-ca-cert --from-file=cert-chain.pem -n istio-system
```

Istiod ログを調べて、Istiod が新しい証明書チェーンを正常に読み込むことを確認します。

kubectl logs ISTIOD_POD -c discovery -n istio-system | grep "CA cert\:" -A 60

出力は次のようになることが想定されます。

2020-10-24T18:58:14.354254Z info pkica CA cert: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

中間証明書: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

ルート証明書: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----

インストールを確認する

次の手順に沿って、Anthos Service Mesh のインストールが正しくなされていることを確認します。

コントロールプレーンコンポーネントを確認する

istio-system のコントロールプレーン Pod が稼働していることを確認します。

kubectl get pod -n istio-system

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

NAME                                      READY   STATUS      RESTARTS   AGE
istio-ingressgateway-74cc894bfd-786rg     1/1     Running     0          7m19s
istiod-78cdbbbdb-d7tps                    3/3     Running     0          7m36s
promsd-576b8db4d6-lqf64                   2/2     Running     1          7m19s

サイドカーからサービスへの TLS 呼び出しをトリガーし、bookinfo を例に使用してサービスが使用する証明書を調べます。
```
kubectl exec POD -c istio-proxy -- openssl s_client -alpn istio -showcerts -connect details:9080
```
出力で証明書を調べて、出力にサーバー側の証明書チェーンが示されていることを確認します。

サイドカープロキシを挿入する

Anthos Service Mesh は、サイドカープロキシを使用してネットワークのセキュリティ、信頼性、オブザーバビリティを強化します。Anthos Service Mesh では、これらの機能がアプリケーションのプライマリコンテナから抽出され、同じ Pod 内の個別のコンテナとして提供される共通のプロセス外プロキシに実装されます。

インストールは、自動サイドカープロキシ挿入（自動挿入）を有効化して、Anthos Service Mesh をインストールする前にクラスタで実行していたワークロードの Pod を再起動するまで完了しません。

自動挿入を有効にするには、Anthos Service Mesh をインストールしたときに istiod に設定したリビジョンラベルで名前空間にラベルを付けます。リビジョンラベルは、サイドカーインジェクタ Webhook によって使用され、挿入されたサイドカーを特定の istiod リビジョンに関連付けます。ラベルを追加したら、サイドカーを挿入できるように、名前空間内の既存の Pod を再起動する必要があります。

新しいワークロードを新しい名前空間にデプロイする前に、Anthos Service Mesh がトラフィックのモニタリングと保護を行えるように自動挿入を構成してください。

自動インジェクションを有効にするには:

次のコマンドを使用して、istiod のリビジョンラベルを探します。

kubectl -n istio-system get pods -l app=istiod --show-labels

出力は次のようになります。

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586

出力の LABELS 列で、接頭辞 istio.io/rev= に続く istiod リビジョンラベルの値をメモします。この例での値は asm-1106-2 です。

リビジョンラベルを適用し、存在する場合は istio-injection ラベルを削除します。次のコマンドで、NAMESPACE は自動インジェクションを有効にする名前空間の名前で、REVISION は前の手順でメモしたリビジョンラベルです。
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
出力中のメッセージ "istio-injection not found" は無視して構いません。これは、今までは名前空間に istio-injection ラベルが付いていなかったことを意味します。Anthos Service Mesh の新規インストールや新規デプロイでは、こうなって当然です。名前空間に istio-injection とリビジョンラベルの両方があると自動インジェクションが失敗するため、Anthos Service Mesh ドキュメント内のすべての kubectl label コマンドには istio-injection ラベルの削除が含まれています。
Anthos Service Mesh をインストールする前にクラスタでワークロードが実行されていた場合は、Pod を再起動して再インジェクションをトリガーします。

Pod を再起動する方法は、アプリケーションとクラスタが属する環境によって異なります。たとえば、ステージング環境では、すべての Pod を削除するのみの場合がありますが、それによって Pod が再起動されます。ただし、本番環境では、Blue/Green デプロイを実装するプロセスにより、トラフィックが中断しないように Pod を安全に再起動できます。

kubectl を使用すると、ローリングの再起動を実行できます。
```
kubectl rollout restart deployment -n NAMESPACE
```
Pod が新しいバージョンの istiod を指すように構成されていることを確認します。
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```

外部 IP アドレスを構成する

デフォルトの Anthos Service Mesh インストールでは、外部 IP アドレスが LoadBalancer サービスに自動的に割り振られることを前提としています。これは、GKE on VMware には当てはまりません。このため、Anthos Service Mesh Ingress Gateway リソースに IP アドレスを手動で割り振る必要があります。

外部 IP アドレスを構成するには、クラスタの負荷分散モードに応じて、以下のいずれかのセクションに従います。

統合負荷分散モードを構成する

istio-ingressgateway Service の構成を開きます。
```
kubectl edit svc -n istio-system istio-ingressgateway
```
istio-ingressgateway Service の構成がシェルのデフォルトのテキストエディタで開かれます。
このファイルの仕様（spec）ブロックの下に次の行を追加します。
```
loadBalancerIP: <your static external IP address>
```
例:
```
spec:
 loadBalancerIP: 203.0.113.1
```
ファイルを保存します。

手動負荷分散モードを構成する

ロードバランサで仮想 IP アドレス（VIP）を持つ NodePort タイプのサービスを公開するには、まず nodePort 値を取得します。

シェルで istio-ingressgateway Service の構成を表示します。

kubectl get svc -n istio-system istio-ingressgateway -o yaml

Anthos Service Mesh のゲートウェイの各ポートが表示されます。コマンドの出力は次のようになります。

 ...
 ports:
 - name: status-port
   nodePort: 30391
   port: 15020
   protocol: TCP
   targetPort: 15020
 - name: http2
   nodePort: 31380
   port: 80
   protocol: TCP
   targetPort: 80
 - name: https
   nodePort: 31390
   port: 443
   protocol: TCP
   targetPort: 443
 - name: tcp
   nodePort: 31400
   port: 31400
   protocol: TCP
   targetPort: 31400
 - name: https-kiali
   nodePort: 31073
   port: 15029
   protocol: TCP
   targetPort: 15029
 - name: https-prometheus
   nodePort: 30253
   port: 15030
   protocol: TCP
   targetPort: 15030
 - name: https-grafana
   nodePort: 30050
   port: 15031
   protocol: TCP
   targetPort: 15031
 - name: https-tracing
   nodePort: 31204
   port: 15032
   protocol: TCP
   targetPort: 15032
 - name: tls
   nodePort: 30158
   port: 15443
   protocol: TCP
   targetPort: 15443
 ...

こうしたポートはロードバランサで公開されます。

たとえば、http2 という名前のサービスポートには port 80 と nodePort 31380 があります。ユーザークラスタのノードアドレスが 192.168.0.10、192.168.0.11、192.168.0.12 で、ロードバランサの VIP が 203.0.113.1 であると仮定します。

203.0.113.1:80 に送信されたトラフィックが 192.168.0.10:31380、192.168.0.11:31380、192.168.0.12:31380 のいずれかに転送されるようにロードバランサを構成します。この指定された VIP で公開するサービスポートを選択できます。

次のステップ

Online Boutique サンプルアプリケーションをデプロイする

HSM と Vault を使用してオンプレミスに Anthos Service Mesh をインストールする

始める前に

要件

環境の設定

依存関係をデプロイする

ハードウェア セキュリティ モジュール（HSM）を設定する

HSM の認証情報とスロットをプロビジョニングする

HSM 鍵暗号鍵（KEK）を生成する

Vault 認証用に Kubernetes を設定する

Vault を設定して HSM 認証情報を保存する

インストール ファイルをダウンロードする

Linux

Mac OS

Windows

コントロール プレーンでリソースを設定する

検証 Webhook の構成

Anthos Service Mesh をインストールする

Istiod の証明書に署名する

インストールを確認する

コントロール プレーン コンポーネントを確認する

サイドカー プロキシを挿入する

外部 IP アドレスを構成する

統合負荷分散モードを構成する

手動負荷分散モードを構成する

次のステップ

ハードウェアセキュリティモジュール（HSM）を設定する

インストールファイルをダウンロードする

コントロールプレーンでリソースを設定する

コントロールプレーンコンポーネントを確認する

サイドカープロキシを挿入する