バージョン1.17

利用可能なバージョン

Certificate Authority Service を使用して Anthos Service Mesh Ingress ゲートウェイの TLS 証明書管理を自動化する

このチュートリアルでは、cert-manager ツールの Certificate Authority Service（CA Service）発行者を使用して、Anthos Service Mesh Ingress ゲートウェイの TLS 証明書の管理を自動化する方法について説明します。この証明書により、Ingress ゲートウェイは、Virtual Private Cloud（VPC）内でサービスメッシュの外部にあるクライアントから送信された HTTPS やその他の TLS、mTLS トラフィックを終端できます。このチュートリアルでは、Kubernetes と TLS 証明書について基本的な知識があることを前提としています。

はじめに

Anthos Service Mesh は、サービスメッシュ内のすべてのワークロードに TLS 証明書をプロビジョニングします。これらの証明書により、サービスメッシュ内のワークロード間で暗号化と相互認証 TLS（mTLS）通信が可能になります。サポートされている CA の 1 つが証明書を発行して署名します。

ただし、Anthos Service Mesh は、サービスメッシュに着信するトラフィックに対して Ingress ゲートウェイに証明書を自動的にプロビジョニングしません。一般的な解決策は、オープンソースの cert-manager ツールを使用して、Ingress ゲートウェイでの証明書管理を自動化することです。

cert-manager ツールは、認証局（CA）を表す発行者の証明書をリクエストします。CA Service とは、独自のプライベート CA を作成できる Google Cloud サービスです。cert-manager ツールは、オープンソースの CA Service の外部発行者を使用して、CA Service の証明書をリクエストできます。

プライベート CA は、内部ネットワーク内でトラフィックを認証して暗号化する TLS 証明書を発行できます。多くの場合、Anthos Service Mesh の Ingress ゲートウェイは、VPC 内でサービスメッシュ外のクライアントからの受信トラフィックを許可するように設定されています。内部ネットワークトラフィックに対しては、CA Service のプライベート CA を使用して Ingress ゲートウェイの証明書を発行できます。

このチュートリアルでは、Ingress ゲートウェイの TLS 証明書のプロビジョニングと更新を自動化するために、cert-manager ツールと CA Service 発行者を設定する方法について説明します。cert-manager ツールは、TLS タイプの Kubernetes Secret リソースとして証明書をプロビジョニングします。cert-manager ツールが証明書を更新すると、Secret リソースが新しい証明書で更新されます。Ingress ゲートウェイは Envoy プロキシを実行し、Envoy のシークレット検出サービス（SDS）をサポートします。SDS を使用すると、管理者がプロセスを再起動または再読み込みすることなく、Ingress ゲートウェイが新しい証明書を使用できるようになります。

メッシュの一部であるサイドカープロキシは、CA Service または Anthos Service Mesh 認証局（Mesh CA）から TLS 証明書を取得できます。このチュートリアルでは、サイドカープロキシと Ingress ゲートウェイの両方の証明書に CA Service を使用します。これにより、すべての TLS 証明書に 1 つのルート CA を使用できます。

次の図は、このチュートリアルでプロビジョニングするリソースを示しています。Ingress ゲートウェイに内部パススルーネットワークロードバランサをプロビジョニングします。内部パススルーネットワークロードバランサはプロキシではないため、TCP 接続の終端処理や TLS handshake は行いません。代わりに、istio-ingressgateway Deployment の Pod に接続がルーティングされます。

hello-example-com-credential Secret には証明書と秘密鍵が含まれています。hello ゲートウェイは、この証明書と秘密鍵を使用してホスト名 hello.example.com を持つリクエストに対して TLS handshake を実行するように istio-ingressgateway Deployment の Pod を構成します。

CA Service を使用した mTLS 管理

cert-manager Namespace 内の google-cas-issuer Deployment の Pod が、CA Service で作成した CA の証明書をリクエストします。ca-service-isser Pod が Workload Identity を使用して Google サービスアカウントの権限を借用できるようにする Identity and Access Management ポリシーバインディングを作成します。この Google サービスアカウントに CA Service の CA に証明書をリクエストする権限を付与するには、CA プールで IAM ポリシーバインディングを作成します。

費用

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

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

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

始める前に

Google Cloud コンソールでプロジェクトセレクタのページに移動し、プロジェクトを選択または作成します。

注: このチュートリアルで作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルが終了したら、プロジェクトを削除して、プロジェクトに関連するすべてのリソースを削除できます。
Google Cloud プロジェクトの課金が有効になっていることを確認します。
Google Cloud コンソールで、Cloud Shell に移動します。

Google Cloud コンソールの下部で Cloud Shell セッションが開き、コマンドラインプロンプトが表示されます。このチュートリアルでは、コマンドの実行はすべて Cloud Shell で行います。
このチュートリアルで使用する Google Cloud コンソールプロジェクトを設定します。
```
gcloud config set core/project PROJECT_ID
```
PROJECT_ID は、Cloud プロジェクト ID に置き換えます。

[Cloud Shell の承認] ダイアログで、[承認] をクリックします。[承認] をクリックすると、Cloud Shell で実行する gcloud コマンドで、ユーザー認証情報を使用して Google API に対する認証が可能となります。

Resource Manager、GKE、GKE Hub、Anthos Service Mesh 認証局、CA Service API を有効にします。

gcloud services enable \
    cloudresourcemanager.googleapis.com \
    container.googleapis.com \
    gkehub.googleapis.com \
    meshca.googleapis.com \
    privateca.googleapis.com

CA Service を構成する

このセクションでは、ルート CA と 2 つの下位 CA を CA Service に作成します。1 つの下位 CA が Ingress ゲートウェイに証明書を発行し、もう 1 つの下位 CA がメッシュ内のサイドカープロキシに証明書を発行します。

わかりやすくするため、このチュートリアルでは GKE クラスタ、ルート CA、下位 CA に同じプロジェクトを使用します。独自の環境では、GKE クラスタと CA に異なるプロジェクトを使用できます。

Cloud Shell で、ルート CA に使用する CA プールを作成します。
```
gcloud privateca pools create ROOT_CA_POOL \
    --location CA_LOCATION \
    --tier enterprise
```
- ROOT_CA_POOL は、CA プールの名前です。例: root-ca-pool-tutorial
- CA_LOCATION は、CA プールのロケーションです。例: us-central1
利用可能な CA Service のロケーションを一覧表示するには、gcloud privateca locations list コマンドを使用します。

ルート CA を作成して有効にします。

gcloud privateca roots create ROOT_CA \
    --auto-enable \
    --key-algorithm ec-p384-sha384 \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --subject "CN=Example Root CA, O=Example Organization" \
    --use-preset-profile root_unconstrained

ROOT_CA は、ルート CA に使用する名前です。例: root-ca-tutorial

Ingress ゲートウェイに証明書を発行する下位 CA に使用する CA プールを作成します。
```
gcloud privateca pools create SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --tier devops
```
- SUBORDINATE_CA_POOL_GATEWAYS は、CA プールの名前です。例: subordinate-ca-mtls-pool-gateways-tutorial
Ingress ゲートウェイに証明書を発行する下位 CA を作成して有効にします。
```
gcloud privateca subordinates create SUBORDINATE_CA_GATEWAYS \
    --auto-enable \
    --issuer-location CA_LOCATION \
    --issuer-pool ROOT_CA_POOL \
    --key-algorithm ec-p256-sha256 \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --subject "CN=Example Gateway mTLS CA, O=Example Organization" \
    --use-preset-profile subordinate_mtls_pathlen_0
```
- SUBORDINATE_CA_GATEWAYS は、下位 CA に使用する名前です。例: subordinate-ca-mtls-gateways-tutorial
- --use-preset-profile フラグは、下位 mTLS 証明書プロファイルを使用するように下位 CA を構成します。このプロファイルにより、下位 CA は mTLS に対してクライアント TLS とサーバー TLS 証明書の両方を発行できます。
Ingress ゲートウェイで mTLS の代わりに単純な TLS を使用する場合は、下位 CA でサーバー TLS 証明書を発行するだけで済みます。この場合は、代わりに下位サーバーの TLS（subordinate_server_tls_pathlen_0）証明書プロファイルを使用できます。

証明書の発行ポリシーを作成します。

cat << EOF > policy.yaml
baselineValues:
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
      clientAuth: true
  caOptions:
    isCa: false
identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )
EOF

この発行ポリシーにより、CA はメッシュ内のワークロードの証明書のみを発行するように制限されます。

メッシュ内のサイドカープロキシに証明書を発行する下位 CA に使用する CA プールを作成します。発行ポリシーを CA プールに適用します。
```
gcloud privateca pools create SUBORDINATE_CA_POOL_SIDECARS \
 --issuance-policy policy.yaml \
 --location CA_LOCATION \
 --tier devops
```
- SUBORDINATE_CA_POOL_SIDECARS は、CA プールの名前です。例: subordinate-ca-mtls-pool-sidecars-tutorial

メッシュ内のサイドカープロキシに証明書を発行する下位 CA を作成して有効にします。

gcloud privateca subordinates create SUBORDINATE_CA_SIDECARS \
    --auto-enable \
    --issuer-location CA_LOCATION \
    --issuer-pool ROOT_CA_POOL \
    --key-algorithm ec-p256-sha256 \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --subject "CN=Example Sidecar mTLS CA, O=Example Organization" \
    --use-preset-profile subordinate_mtls_pathlen_0

SUBORDINATE_CA_GATEWAYS は、下位 CA に使用する名前です。例: subordinate-ca-mtls-sidecars-tutorial

Google Kubernetes Engine クラスタを作成する

Cloud Shell で、GKE クラスタを作成します。
```
gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes 4 \
    --release-channel regular \
    --scopes cloud-platform \
    --workload-pool PROJECT_ID.svc.id.goog \
    --zone ZONE
```
CLUSTER_NAME は、クラスタの名前に置き換えます。例: asm-ingress-cert-manager-ca-service

ZONE は、クラスタに使用するゾーンに置き換えます。例: us-central1-f

コマンドについて、次の点に注意してください。
- --release-channel フラグを指定すると、クラスタの GKE リリースチャンネルが選択されます。
- Anthos Service Mesh と cert-manager ツールの CA Service 発行元の両方で、クラスタノードに cloud-platform スコープを設定する必要があります。
- --workload-pool 引数を使用すると、Workload Identity が有効になり、CA Service 発行元の Kubernetes サービスアカウントが Google サービスアカウントの権限を借用できます。この権限借用により、CA Service 発行元 Pod が Google サービスアカウントの鍵ファイルをダウンロードすることなく、CA Service API にアクセスできます。
ユーザーアカウントにクラスタ管理者の権限を付与します。
```
kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin \
    --user $(gcloud config get-value core/account)
```
Anthos Service Mesh のロールベースのアクセス制御（RBAC）ルールを作成し、cert-manager ツールをインストールするには、Kubernetes cluster-admin ClusterRole によって提供される権限が必要です。

Anthos Service Mesh コントロールプレーンをインストールする

このチュートリアルでは、Google Cloud 上の GKE クラスタにマネージド Anthos Service Mesh をインストールし、すべてのリソースを 1 つのプロジェクトに保存します。独自の環境では、このドキュメントで説明する解決策はマネージド Anthos Service Mesh またはクラスタ内コントロールプレーンを使用して適用できます。

Anthos Service Mesh には、さまざまなシナリオに対応するインストールオプションが用意されています。このチュートリアルを完了したら、インストールガイドを確認して、実際の環境に最適なオプションを選択することをおすすめします。

Cloud Shell で、asmcli インストールツールをダウンロードします。
```
curl --location --output asmcli https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.17

chmod +x asmcli
```
asmcli を使用して Anthos Service Mesh コントロールプレーンをインストールします。
Anthos Service Mesh コントロールプレーンをインストールします。
```
./asmcli install \
    --ca gcp_cas \
    --ca_pool projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_SIDECARS \
    --cluster_location ZONE \
    --cluster_name CLUSTER_NAME \
    --enable_all \
    --enable_registration \
    --fleet_id PROJECT_ID \
    --managed \
    --output_dir asm-files \
    --project_id PROJECT_ID \
    --verbose
```
- --ca gcp_cas フラグと --ca_pool フラグを指定すると、CA Service のサイドカー CA プールを使用してメッシュ内のサイドカープロキシに証明書を発行するように、Anthos Service Mesh コントロールプレーンを構成します。
- --enable_registration フラグを指定して、--fleet_id フラグに指定したプロジェクトのフリートに GKE クラスタを登録します。このチュートリアルでは、GKE クラスタとフリートは同じプロジェクトを使用します。
- --managed フラグは、マネージド Anthos Service Mesh コントロールプレーンを設定します。
- --output_dir フラグには、Anthos Service Mesh のインストールに必要なファイルと構成をダウンロードする際に asmcli が使用するディレクトリを指定します。これらのファイルは、チュートリアルの後半で使用します。
注: 利用可能なすべての asmcli オプションを表示するには、./asmcli --help --verbose を実行します。
インストールには数分かかります。インストールが完了すると、次の出力が表示されます。
```
asmcli: Successfully installed ASM.
```

Ingress ゲートウェイをインストールする

Cloud Shell で、Ingress ゲートウェイの Kubernetes 名前空間を作成します。
```
kubectl create namespace GATEWAY_NAMESPACE
```
- GATEWAY_NAMESPACE は、Ingress ゲートウェイに使用する名前空間の名前です。例: istio-ingress
Ingress ゲートウェイの内部パススルーネットワークロードバランサに使用する静的内部 IP アドレスを予約します。
```
LOAD_BALANCER_IP=$(gcloud compute addresses create \
    asm-ingress-gateway-ilb \
    --region REGION \
    --subnet default \
    --format 'value(address)')
```
- REGION は、GKE クラスタノードが使用するゾーンを含むリージョンに置き換えます。たとえば、クラスタで us-central1-f ゾーンを使用する場合は、REGION を us-central1 に置き換えます。
このコマンドは、指定したリージョンのデフォルトサブネットの IP アドレスを予約します。
Ingress ゲートウェイのオペレータマニフェストを作成します。
```
cat << EOF > ingressgateway-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: ingressgateway-operator
  annotations:
    config.kubernetes.io/local-config: "true"
spec:
  profile: empty
  revision: asm-managed
  components:
    ingressGateways:
    - name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
      enabled: true
      k8s:
        overlays:
        - apiVersion: apps/v1
          kind: Deployment
          name: istio-ingressgateway
          patches:
          - path: spec.template.metadata.annotations
            value:
              inject.istio.io/templates: gateway
          - path: spec.template.metadata.labels.sidecar\.istio\.io/inject
            value: "true"
          - path: spec.template.spec.containers[name:istio-proxy]
            value:
              name: istio-proxy
              image: auto
        service:
          loadBalancerIP: $LOAD_BALANCER_IP
        serviceAnnotations:
          networking.gke.io/load-balancer-type: Internal
          networking.gke.io/internal-load-balancer-allow-global-access: "true"
EOF
```
オペレータマニフェストについては、次の点に注意してください。
- revision フィールドには、データプレーンに使用するマネージド Anthos Service Mesh リリースチャンネルを指定します。コントロールプレーンに Rapid または Stable のリリースチャンネルを使用する場合は、このフィールドの値を変更します。
- overlays セクションで指定した annotation、label、image により、Ingress ゲートウェイデプロイメントでプロキシ構成の自動挿入が有効になります。
- loadBalancerIP フィールドには、ロードバランサに使用する IP アドレスを指定します。このフィールドをマニフェストから削除すると、ロードバランサはエフェメラル IP アドレスを使用します。
- Ingress ゲートウェイのサービスアノテーション networking.gke.io/load-balancer-type: Internal は、GKE が Ingress ゲートウェイ Pod の前に内部パススルーネットワークロードバランサをプロビジョニングすることを意味します。このアノテーションを削除すると、GKE は代わりに外部パススルーネットワークロードバランサをプロビジョニングします。
- オプションのサービスアノテーション networking.gke.io/internal-load-balancer-allow-global-access: "true" を使用すると、VPC の任意のリージョンのクライアントが内部パススルーネットワークロードバランサにアクセスできます。このアノテーションを削除すると、内部パススルーネットワークロードバランサは、VPC の同じリージョン内のクライアントから送信されたトラフィックのみを受信します。
オペレータマニフェストと、コントロールプレーンのインストール時に asmcli スクリプトがダウンロードした istioctl ツールを使用して、Ingress ゲートウェイインストールマニフェストを作成します。
```
./asm-files/istioctl manifest generate \
    --filename ingressgateway-operator.yaml \
    --output ingressgateway
```
Ingress ゲートウェイをインストールします。
```
kubectl apply --recursive --filename ingressgateway/
```

cert-manager ツールをインストールする

Cloud Shell で、cert-manager ツールのインストールマニフェストをダウンロードして適用します。

CERT_MANAGER_VERSION=v1.5.4

curl --location --output cert-manager.yaml "https://github.com/jetstack/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.yaml"

kubectl apply --filename cert-manager.yaml

cert-manager ツールのインストールには 1 分ほどかかります。

CA Service 発行元コントローラをインストールする

CA Service 発行元コントローラを使用すると、cert-manager ツールは CA Service を使用して証明書をリクエストできます。コントローラは、cert-manager ツールの外部発行元の拡張メカニズムを使用します。

Cloud Shell で、Google サービスアカウントを作成します。
```
gcloud iam service-accounts create CAS_ISSUER_GSA \
    --display-name "CA Service issuer for cert-manager"
```
- CAS_ISSUER_GSA は、Google サービスアカウントの名前です。例: cert-manager-ca-service-issuer
Certificate Authority Service 発行元コントローラは、この Google サービスアカウントを使用して、Certificate Authority Service API に対する認証を行います。
Certificate Authority Service 発行元コントローラの Google サービスアカウントが下位 CA を含む CA プールの証明書をリクエストできるように、Identity and Access Management ポリシーバインディングを作成します。
```
gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester
```

Certificate Authority Service 発行元コントローラのインストールマニフェストをダウンロードします。

CAS_ISSUER_VERSION=v0.5.3

curl --location --output ca-service-issuer.yaml "https://github.com/jetstack/google-cas-issuer/releases/download/${CAS_ISSUER_VERSION}/google-cas-issuer-${CAS_ISSUER_VERSION}.yaml"

IAM ポリシーバインディングを作成して、cert-manager Namespace の ksa-google-cas-issuer Kubernetes サービスアカウントが Workload Identity を使用して Google サービスアカウント（GSA）の権限借用を許可します。
```
gcloud iam service-accounts add-iam-policy-binding \
 CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \
    --role roles/iam.workloadIdentityUser
```
CA Service 発行元コントローラ Pod は、ksa-google-cas-issuer Kubernetes サービスアカウントを使用します。
GKE クラスタに CA Service 発行元コントローラをインストールします。
```
kubectl apply --filename ca-service-issuer.yaml
```
CA Service 発行元コントローラ Pod が使用する Kubernetes サービスアカウントに、Workload Identity アノテーション iam.gke.io/gcp-service-account を追加します。
```
kubectl annotate serviceaccount ksa-google-cas-issuer --namespace cert-manager \
   "iam.gke.io/gcp-service-account=CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com"
```
このアノテーションは、Kubernetes サービスアカウントが Google サービスアカウントの権限を借用して Google API にアクセスできることを GKE に通知します。

証明書の発行者を作成する

Cloud Shell で、GoogleCASIssuer マニフェストを作成して適用します。
```
cat << EOF > gateway-cas-issuer.yaml
apiVersion: cas-issuer.jetstack.io/v1beta1
kind: GoogleCASIssuer
metadata:
  name: gateway-cas-issuer
  namespace: GATEWAY_NAMESPACE
spec:
  caPoolId: SUBORDINATE_CA_POOL_GATEWAYS
  location: CA_LOCATION
  project: PROJECT_ID
EOF

kubectl apply --filename gateway-cas-issuer.yaml
```
発行元により、cert-manager ツールで Ingress ゲートウェイ名前空間の下位 CA プールの証明書をプロビジョニングできます。

注: 名前空間スコープの発行者ではなく、クラスタスコープの発行者を作成できます。クラスタスコープの発行者は、Kubernetes クラスタ内のすべての名前空間に証明書をプロビジョニングできます。

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

このセクションでは、cert-manager ツールが CA Service 発行元を使用して CA Service から証明書を取得できることを確認します。確認のために、リクエストルーティング構成と Ingress ゲートウェイの証明書を使用してサンプルアプリケーションをデプロイします。

Cloud Shell で、サンプルアプリケーションリソースの名前空間を作成します。
```
cat << EOF > sample-app-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: APP_NAMESPACE
  annotations:
    mesh.cloud.google.com/proxy: '{"managed":"true"}'
  labels:
    istio.io/rev: asm-managed
EOF

kubectl apply --filename sample-app-namespace.yaml
```
- APP_NAMESPACE は、サンプルアプリケーションの名前空間の名前です。例: sample-app。
アノテーション mesh.cloud.google.com/proxy を使用すると、名前空間に対してマネージドデータプレーンが有効になります。

ラベル istio.io/rev: asm-managed は、サンプルアプリケーションの Namespace にマネージドデータプレーンの Regular リリースチャンネルを選択します。Rapid または Stable のリリースチャンネルを使用している場合は、このラベルの値を変更します。

サンプルアプリケーションの Deployment リソースを作成します。

cat << EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
  namespace: APP_NAMESPACE
  labels:
    app: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        name: hello-app
        ports:
        - containerPort: 8080
EOF

kubectl apply --filename deployment.yaml

サンプルアプリケーションの Service リソースを作成します。

cat << EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
  name: SERVICE_NAME
  namespace: APP_NAMESPACE
spec:
  ports:
  - name: http-hello
    port: 8080
  selector:
    app: hello
  type: ClusterIP
EOF

kubectl apply --filename service.yaml

SERVICE_NAME は、サービスの名前です。例: hello

証明書の発行元を使用して、ドメイン名 hello.example.com の Certificate リソースを作成します。
```
cat << EOF > certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: hello-example-com-certificate
  namespace: GATEWAY_NAMESPACE
spec:
  secretName: hello-example-com-credential
  commonName: hello.example.com
  dnsNames:
  - hello.example.com
  duration: 24h
  renewBefore: 8h
  issuerRef:
    group: cas-issuer.jetstack.io
    kind: GoogleCASIssuer
    name: gateway-cas-issuer
EOF

kubectl apply --filename certificate.yaml
```
Certificate の名前空間が Ingress ゲートウェイの名前空間と一致する必要があります。サービスメッシュ全体に影響する可能性があるため、通常、この名前空間のリソースを変更できるのはプラットフォーム管理者のみです。cert-manager ツールにより、同じ名前空間に TLS 証明書の Secret リソースが作成されます。つまり、アプリケーション管理者は Ingress ゲートウェイ名前空間にアクセスする必要はありません。

Certificate の dnsNames リストで別のホスト名を追加できます。これらのホスト名は、サブジェクトの代替名（SAN）として証明書に含まれています。
サンプルアプリケーションの Gateway リソースを作成します。
```
cat << EOF > gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: GATEWAY_NAME
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - APP_NAMESPACE/hello.example.com
    port:
      name: https-hello
      number: 443
      protocol: HTTPS
    tls:
      credentialName: hello-example-com-credential
      mode: MUTUAL
EOF

kubectl apply --filename gateway.yaml
```
- GATEWAY_NAME はゲートウェイ名です。例: hello
- ゲートウェイの credentialName フィールドは、証明書の secretName フィールドと一致します。cert-manager ツールにより、CA Service の TLS 証明書を使用して Kubernetes Secret が作成されます。この証明書により、Ingress ゲートウェイは hello.example.com 宛ての TLS トラフィックを終端できます。
Gateway マニフェストには、MUTUAL TLS（mTLS）を指定します。通常の TLS にゲートウェイを構成する場合は、代わりに Gateway の TLS モードを SIMPLE に設定します。
サンプルアプリケーションの VirtualService リソースを作成します。
```
cat << EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: hello
  namespace: APP_NAMESPACE
spec:
  hosts:
  - hello.example.com
  gateways:
  - GATEWAY_NAMESPACE/GATEWAY_NAME
  http:
  - route:
    - destination:
        host: SERVICE_NAME
        port:
          number: 8080
EOF

kubectl apply --filename virtual-service.yaml
```
Gateway と VirtualService の名前空間は異なります。この共通パターンでは、Ingress ゲートウェイ名前空間内のリソースを変更する権限を持つプラットフォーム管理者にのみ、Gateway のホストベースのルーティングの変更が許可されます。

サンプルアプリケーションの名前空間で VirtualService を編集する権限を持つアプリケーション管理者は、プラットフォーム管理者と調整を行わずに、URL パスなどの他のリクエストフィールドによるルーティングを変更できます。

他の構成オプションを確認する場合は、Certificate、Gateway、VirtualService リソースの API ドキュメントをご覧ください。

Ingress ゲートウェイを経由してサービスメッシュに到達するトラフィックに、認証ポリシーと認可ポリシーを適用できます。方法については、Istio PeerAuthentication API と AuthorizationPolicy API のドキュメントをご覧ください。

問題の解決を確認する

このセクションでは、サービスメッシュの外部からサンプルアプリケーションに mTLS を使用して HTTPS リクエストを送信できることを確認します。これを確認するには、Compute Engine VM インスタンスを作成して、CA Service からクライアント TLS 証明書をリクエストし、その証明書を使用してサンプルアプリケーションへのリクエストを認証します。

VM インスタンスへの SSH アクセスが必要です。デフォルトネットワークには、SSH アクセスを許可するファイアウォールルールが含まれています。SSH でアクセスできない場合は、ファイアウォールルールのドキュメントに沿って、ポート 22 で受信 TCP 接続を許可するファイアウォールルールを作成してください。

Cloud Shell で、Google サービスアカウントを作成します。
```
gcloud iam service-accounts create CLIENT_VM_GSA \
    --display-name "CA Service tutorial VM instance service account"
```
- CLIENT_VM_GSA は、Google サービスアカウントの名前です。例: cas-tutorial-client
この Google サービスアカウントを Compute Engine VM インスタンスに割り当てます。

Google サービスアカウントにゲートウェイの下位 CA プールの CA Service 証明書リクエスト元ロールを付与します。

gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

このロールは、CA プールの証明書をリクエストする権限を付与します。

GKE クラスタと同じ VPC 内に Compute Engine VM インスタンスを作成します。
```
gcloud compute instances create cas-tutorial-client \
    --scopes cloud-platform \
    --service-account CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --zone ZONE
```
VM インスタンスが CA Service API にアクセスするには、cloud-platform スコープが必要です。

Ingress ゲートウェイの内部パススルーネットワークロードバランサの IP アドレスをファイルに保存します。

kubectl get services istio-ingressgateway \
   --namespace GATEWAY_NAMESPACE \
   --output jsonpath='{.status.loadBalancer.ingress[0].ip}' > ilb-ip.txt

ルート CA の公開鍵証明書をファイルに保存します。
```
gcloud privateca roots describe ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --format 'value(pemCaCertificates)' > root-ca-cert.pem
```
注: この証明書をシークレットの認証情報として扱う必要はありません。証明書には、ルート CA の公開鍵のみが含まれ、秘密鍵は含まれません。サービスを使用するすべてのクライアントに、TLS handshake の一環としてこの証明書のコピーが送信されます。
ルート CA 証明書と Ingress ゲートウェイの内部パススルーネットワークロードバランサの IP アドレスを含むファイルを VM インスタンスにコピーします。
```
gcloud compute scp root-ca-cert.pem ilb-ip.txt cas-tutorial-client:~ \
   --zone ZONE
```
SSH を使用して VM インスタンスに接続します。
```
gcloud compute ssh cas-tutorial-client --zone ZONE
```
このセクションの残りのコマンドは、SSH セッションから実行します。
ca-certificates パッケージ、coreutils パッケージ、curl、openssl、jq コマンドラインツールをインストールします。
```
sudo apt-get update --yes

sudo apt-get install --yes ca-certificates coreutils curl jq openssl
```

クライアント TLS 証明書の鍵ペアを作成します。

openssl genrsa -out private-key.pem 2048

openssl rsa -in private-key.pem -pubout -out public-key.pem

メタデータサーバーにクエリを実行し、VM インスタンスに接続している Google サービスアカウント ID のメールアドレスを取得します。
```
GSA_EMAIL=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email)
```

Certificate Authority Service API からクライアント TLS 証明書をリクエストするときに、リクエスト本文として使用する JSON ファイルを作成します。

cat << EOF > request.json
{
  "config": {
    "publicKey": {
      "format": "PEM",
      "key": "$(base64 --wrap 0 public-key.pem)"
    },
    "subjectConfig": {
      "subject": {
        "commonName": "$(hostname --short)",
        "organization": "Example Organization"
      },
      "subjectAltName": {
        "dnsNames": [
          "$(hostname --fqdn)"
        ],
        "emailAddresses": [
          "$GSA_EMAIL"
        ]
      }
    },
    "x509Config": {
      "caOptions": {
        "isCa": false
      },
      "keyUsage": {
        "baseKeyUsage": {
          "digitalSignature": true,
          "keyEncipherment": true
        },
        "extendedKeyUsage": {
          "clientAuth": true
        }
      }
    }
  },
  "lifetime": "86400s"
}
EOF

構成セクションのフィールドの詳細については、CA Service API ドキュメントの CertificateConfig タイプをご覧ください。

メタデータサーバーの OAuth 2.0 アクセストークンをリクエストします。
```
TOKEN=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | jq --raw-output ".access_token")
```
このアクセストークンにより、VM インスタンスに接続している Google サービスアカウントに付与された権限が提供されます。

CA Service API のクライアント TLS 証明書をリクエストし、レスポンスの本文をファイルに保存します。

curl --silent --request POST \
    --header "Authorization: Bearer $TOKEN" \
    --header "Content-Type: application/json" \
    --data @request.json \
    --output response.json \
    "https://privateca.googleapis.com/v1/projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_GATEWAYS/certificates"

このコマンドでは、アクセストークンを使用して API リクエストを認証しています。

クライアント証明書と証明書チェーンをファイルに保存します。

jq --raw-output --join-output ".pemCertificate , .pemCertificateChain[]" response.json > client-cert-chain.pem

curl を使用して、VM インスタンスからサンプルアプリケーションに HTTPS リクエストを送信します。
```
curl --cert client-cert-chain.pem --key private-key.pem \
    --cacert root-ca-cert.pem \
    --resolve hello.example.com:443:$(cat ilb-ip.txt) \
    --silent https://hello.example.com | head -n1
```
出力は次のようになります。
```
Hello, world!
```
このレスポンスは、curl が mTLS を使用して HTTPS リクエストを送信したことを示しています。サンプルアプリケーションは、ターミナルの出力に表示されるメッセージで応答しています。

curl コマンドは、次のことを行います。
- --cert フラグと --key フラグを指定すると、curl はクライアントの TLS 証明書と秘密鍵を使用してリクエストを認証します。クライアント証明書ファイルには、クライアント証明書からルート CA までの完全な証明書チェーンが含まれています。
- --cacert フラグを指定すると、このチュートリアルで作成したルート CA またはその下位 CA のいずれかがサーバー証明書を発行したことを curl に確認するように指示します。
  
  このフラグを省略すると、curl は、オペレーティングシステムのデフォルト CA バンドル（Debian の ca-certificates パッケージなど）を使用してサーバー証明書の検証を試みます。デフォルトの CA バンドルに、このチュートリアルで作成したルート CA が含まれていないため、検証は失敗します。
- --resolve フラグは、ポート 443 で hello.example.com をホストするリクエストの宛先として、内部パススルーネットワークロードバランサの IP アドレスを使用するよう curl に指示します。
  
  このフラグを省略すると、curl は DNS を使用して hello.example.com ホスト名を解決しようとします。このホスト名の DNS エントリがないため、DNS の解決は失敗します。
  
  独自の環境では、内部パススルーネットワークロードバランサの IP アドレス（$LOAD_BALANCER_IP）を指す DNS A レコードを作成することをおすすめします。レコードの管理のドキュメントに従って、Cloud DNS を使用してこのレコードを作成します。
- --silent フラグを指定すると、ターミナル出力でレスポンスのダウンロード進捗状況レポートが抑制されます。
- このコマンドは、curl 出力を head -n1 にパイプします。その結果、ターミナルの出力にはレスポンスの本文の最初の行だけが含まれます。
SSH セッションを終了します。
```
exit
```

このセクションでは、クライアント TLS 証明書を CA Service API から直接リクエストしました。クライアントが別の Kubernetes クラスタ内の別のサービスメッシュの下り（外向き）ゲートウェイである場合は、同じルート CA を持つ cert-manager ツールと Certificate Authority Service 発行元を使用して、Egress ゲートウェイにクライアント証明書を提供できます。

場合によっては、Hashicorp Vault、Terraform、gcloud などのツールを使用して、サービスメッシュ外のワークロードのクライアント TLS 証明書をリクエストすることもできます。サンプルソリューションの詳細については CA Service のドキュメントを、CA Service の詳細については gcloud のドキュメントをご覧ください。

（オプション）CA 証明書をトラストストアに追加する

このセクションでは、Linux Debian ディストリビューションの信頼できる CA 証明書のストアに CA 証明書を追加する方法を説明します。以下の手順は、Ubuntu などの Debian から生成されたディストリビューションにも適用されます。

このストアに CA 証明書を追加すると、curl、Python、Go、Ruby を使用して HTTPS リクエストを送信する場合に、信頼できる CA 証明書のロケーションを指定する必要がなくなります。

SSH を使用して VM インスタンスに接続します。
```
gcloud compute ssh cas-tutorial-client --zone ZONE
```
このセクションの残りのコマンドは、SSH セッションから実行します。
ルート CA 証明書をディレクトリ /usr/local/share/ca-certificates にコピーし、ファイルの拡張子が .crt であることを確認します。
```
sudo cp root-ca-cert.pem /usr/local/share/ca-certificates/cas-rootca.crt
```
すべてのユーザーがルート CA 証明書ファイルを読み取れるように、ファイル権限を設定します。
```
sudo chmod 644 /usr/local/share/ca-certificates/cas-rootca.crt
```
update-ca-certificates スクリプトを実行します。
```
sudo update-ca-certificates
```
このスクリプトでは、ディレクトリ /etc/ssl/certs 内の信頼できる証明書のセットとファイル /etc/ssl/certs/ca-certificates.crt に証明書を追加します。

次のような出力が表示されます。
```
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
```
curl を使用して、VM インスタンスからサンプルアプリケーションに HTTPS リクエストを送信します。
```
curl --cert client-cert-chain.pem --key private-key.pem \
   --resolve hello.example.com:443:$(cat ilb-ip.txt) \
   --silent https://hello.example.com | head -n1
```
出力は次のようになります。
```
Hello, world!
```
このレスポンスは、curl が mTLS を使用して HTTPS リクエストを正常に送信し、デフォルトの CA 証明書ストアを使用して Ingress ゲートウェイのサーバー TLS 証明書を検証したことを示しています。
SSH セッションを終了します。
```
exit
```

トラブルシューティング

CA Service 発行元コントローラが TLS 証明書のシークレットを作成しない場合は、CA Service 発行元コントローラのログを確認します。

kubectl logs deployment/google-cas-issuer --namespace cert-manager

Anthos Service Mesh のインストールで問題が発生した場合は、asmcli ツールを使用して、Cloud プロジェクトと GKE クラスタを検証します。

このチュートリアルで他の問題が発生した場合は、次のドキュメントを確認することをおすすめします。

クリーンアップ

このチュートリアルで使用したリソースについて、これ以降 Google Cloud アカウントに課金されないようにするには、プロジェクトを削除するか、個々のリソースを削除します。

プロジェクトの削除

Cloud Shell で、プロジェクトを削除します。
```
gcloud projects delete PROJECT_ID
```

リソースの削除

このチュートリアルで使用した Google Cloud プロジェクトを残しておく場合は、個々のリソースを削除します。

Cloud Shell で、GKE Hub から GKE クラスタの登録を解除します。

gcloud container hub memberships unregister CLUSTER_NAME \
    --gke-cluster ZONE/CLUSTER_NAME

GKE クラスタを削除します。

gcloud container clusters delete CLUSTER_NAME \
    --zone ZONE --async --quiet

下位 CA プールの IAM ポリシーバインディングを削除します。

gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/privateca.certificateRequester

下位 CA とルート CA の無効化と削除のスケジュール設定を行います。

gcloud privateca subordinates disable SUBORDINATE_CA_GATEWAYS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --quiet

gcloud privateca subordinates delete SUBORDINATE_CA_GATEWAYS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_GATEWAYS \
    --ignore-active-certificates \
    --quiet

gcloud privateca subordinates disable SUBORDINATE_CA_SIDECARS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --quiet

gcloud privateca subordinates delete SUBORDINATE_CA_SIDECARS \
    --location CA_LOCATION \
    --pool SUBORDINATE_CA_POOL_SIDECARS \
    --ignore-active-certificates \
    --quiet

gcloud privateca roots disable ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --quiet

gcloud privateca roots delete ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --ignore-active-certificates \
    --quiet

CA Service 発行元コントローラの Google サービスアカウントの IAM ポリシーバインディングを削除します。

gcloud iam service-accounts remove-iam-policy-binding \
    CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \
    --role roles/iam.workloadIdentityUser

Google サービスアカウントを削除します。

gcloud iam service-accounts delete --quiet \
    CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com

gcloud iam service-accounts delete --quiet \
    CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com

予約済みのロードバランサの IP アドレスを削除します。

gcloud compute addresses delete asm-ingress-gateway-ilb \
    --region REGION --quiet

Compute Engine VM インスタンスを削除します。

gcloud compute instances delete cas-tutorial-client \
    --zone ZONE --quiet

次のステップ

他の Certificate Authority Service 入門ガイドを確認する。
Istio ベースのツールスイートである Anthos Service Mesh を学習する。このスイートを使用すると、オンプレミスと Google Cloud で信頼性の高いサービスメッシュのモニタリングと管理を行うことができます。
Anthos Service Mesh 入門ガイドを読む。