Terraform を使用して複数の GKE クラスタ向けに Anthos Service Mesh を設定
Google Cloud Japan Team
※この投稿は米国時間 2021 年 2 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。
Anthos Service Mesh は、Google Kubernetes Engine（GKE）クラスタ向けのマネージド サービス メッシュです。Anthos Service Mesh により、GKE クラスタは単一の論理的なサービス メッシュを使用できるようになるため、Pod がクラスタ間で安全に通信し、サービスが単一のVirtual Private Cloud（VPC）を共有できます。
Anthos Service Mesh の使用には、GKE クラスタとファイアウォール ルールが必要です。また、プライベート クラスタを使用している場合は、GKE コントロール プレーンへのアクセスを許可する必要があります。Infrastructure as Code（IaC）により、Anthos Service Mesh のブートストラップが大幅に簡単になります。本ブログ投稿では、Anthos Service Mesh の新機能と、Terraform を使用して Anthos Service Mesh を 2 つのプライベート GKE クラスタ間に実装する方法をご説明します。また、クラウド環境を設定するためのガイドとなる、自動スクリプトもご紹介します。
すぐに始められるよう、完全なソースコードと README の手順を含む Git リポジトリをご用意しています。また最後には、メッシュのトラフィックのセキュリティ スキャンと、外部データベース向けのボーナス セクションがそれぞれあります。
サポートされているバージョン
サポートされているバージョンは Anthos Service Mesh 1.7 および 1.8 です。Anthos Service Mesh バージョンの詳細については、Anthos Service Mesh リリースノートをご覧ください。
共有 VPC
Anthos Service Mesh 1.8 は、複数のプロジェクトにまたがる場合でも、単一の共有 VPC 向けに使用できます。詳細については、Anthos Service Mesh 1.8 のマルチクラスタのサポートに関するドキュメントをご覧ください。
SSL / TLS の終端
外部リクエストの TLS の終端は Anthos Service Mesh 1.8 でサポートされています。これには、Anthos Service Mesh の設定ファイルを修正する必要があります。
Anthos Service Mesh は、install_asm スクリプトを使用して設定できます。カスタマイズされた istio-operator.yaml ファイルは、install_asm を --custom_overlay オプション付きで実行することで使用できます。
Istio（Anthos Service Mesh など）が外部サービスへのアクセスを許可するようにするためには、下り（外向き）ポリシーを REGISTRY_ONLY に変更します。詳細については、Istio のデフォルトでのブロックのドキュメントをご覧ください。
Prisma Cloud（Twistlock）へのリクエストの TLS 終端については、Prisma Cloud に関する次のセクションをご覧ください。
セキュリティ
セキュリティ概要ドキュメントに記載されているとおり、Anthos Service Mesh には、固有のセキュリティ機能（および制限）があります。また、セキュリティのための GKE のベスト プラクティスに従ってください。
注: Anthos Service Mesh は、名前空間や制限付きサービス アカウントなどの、Istio のセキュリティのベスト プラクティスを実装するようになっています。Workload Identity は、名前空間に限定されているオプションの GKE 特有のサービス アカウントです。
Istio Ingress ゲートウェイは手動でセキュリティ保護する必要があります。詳細については、ゲートウェイの保護の Istio のドキュメントをご覧ください。
GKE クラスタの上り（内向き）のセキュリティ スキャンについては、Prisma Cloud に関する以下のセクションをご覧ください。
コンテナのワークロード セキュリティ
GKE クラスタのネットワーク ポリシーにより、Pod と名前空間の間のワークロードのアクセスを定義できます。これは、Kubernetes NetworkPolicy API 上にビルドされています。アプリケーション向けに GKE ネットワーク ポリシーを構成するための便利なチュートリアルもあります。
GKE でコンテナのワークロードを保護するための詳細な手順があります。これには、ノードのセキュリティ、Pod / コンテナのセキュリティのコンテキスト、Pod のセキュリティ ポリシーに対する階層化されたアプローチが含まれています。また、Google Cloud の Container-Optimized OS（cos と cos_containerd の両方）は、デフォルトの Docker AppArmor セキュリティ ポリシーを、Kubernetes によって開始されたすべてのコンテナに適用します。
コンテナのランタイム（Containerd）
Anthos Service Mesh を使用して、GKE クラスタ向けの cos_containerd ランタイムを使用することをおすすめします。現在の Docker コンテナのランタイムは GKE から削除されています。ここで cos_containerd を採用することで、今後の移行の必要性を回避できます。
Containerd をコンテナのランタイムとして使用することで、デベロッパーは引き続き Docker を使用してコンテナをビルドできます。Docker から Containerd に移行する際は、次のような競合が発生する可能性があります。
Docker コマンドを実行する特権 Pod の実行
Kubernetes インフラストラクチャ外のノードでのスクリプトの実行（ssh を使用した問題のトラブルシューティングなど）
同様の特権オペレーションを実行するサードパーティ ツールの使用
モニタリング システム内の Docker 固有のログメッセージに応答するように構成されたツールの使用
このような競合を防ぐためには、cos_containerd を使用してクラスタをカナリア デプロイすることをおすすめします。カナリア デプロイの手順については、前述の移行ドキュメントのリンクをご覧ください。
Prisma Cloud（旧称 Twistlock）を使用したセキュリティ スキャン
Anthos Service Mesh 上の Pod トラフィックのセキュリティ スキャンを行うには、Palo Alto Networks の Prisma Cloud（旧称 Twistlock）を使用できます。これは、マルチクラウドの視認性と脅威の検出を提供する、クラウド セキュリティ体制管理（CSPM）およびクラウド ワークロード保護プラットフォーム（CWPP）です。詳細については、Prisma Cloud 管理ガイド（2021 年 1 月 7 日時点で最新）をご覧ください。
Prisma Cloud の設定
設定手順については、anthos-service-mesh-multicluster ソースコード リポジトリ内の Twistlock のフォルダの README ファイルをご覧ください。以下の表には、公式の Prisma Cloud 設定ドキュメントへのリンクが含まれています。
TLS 終端
Prisma Cloud TLS リクエストは、Prisma Cloud Console で終端します。Prisma Cloud SaaS から Twistlock コンテナへリクエストがあると、API 呼び出しも TLS 証明書とともに終端されます。
Google Cloud SQL for PostgreSQL を使用した外部データベース
多くの組織は、Anthos Service Mesh 環境への外部データベース接続を確立したいと考えています。一般的な一例では、Google Cloud SQL for PostgreSQL（Cloud SQL）を使用します。
Cloud SQL は GKE に対して外部であるため、外部サービスに対する GKE による SSL 終端が必要となります。Anthos Service Mesh では、SSL のパススルーが可能となる Istio Ingress ゲートウェイを使用して、サーバー証明書をコンテナ内に配置できます。ただし、このアプローチは多くの PostgreSQL データベースでは問題となります。
PostgreSQL は SSL 接続に対してアプリケーション レベルでのプロトコル ネゴシエーションを使用します。Istio プロキシは現在 TCP レベルのプロトコル ネゴシエーションを使用しています。このため、Istio プロキシのサイドカーが PostgreSQL との接続を自動的に暗号化しようとすると、SSL handshake でエラーが発生します。幸いにも、Cloud SQL 自体が TLS 終端用のサイドカーをホストできます。
設定手順については、anthos-service-mesh-multicluster ソースコード リポジトリ内の postgres フォルダの README ファイルをご覧ください。
連携クラスタに向けて
Anthos Service Mesh 1.7 および 1.8 では複数の GKE クラスタを連携できるようになりました。単一の VPC 内の「マネージド Istio」として、このコンテナのオーケストレーション モデルにより GKE を最大限活用できるようになります。これは、anthos-service-mesh-multicluster Git リポジトリにある Terraform やシェル スクリプトなどのツールを使用して構成できます。.
まだサンプルコードをお試しではない場合は、Git リポジトリにアクセスして試してみてください。README ファイルは詳細でわかりやすいため、次の手順として有効です。Anthos Service Mesh を理解するには、実際にやってみて学ぶのが効果的な方法です。また、Terraform コードは最新の Google Cloud モージュルを使用するため、習得にふさわしい価値のあるツールとなります。
Google Cloud Professional Services の投稿手順を使用して、Git リポジトリに投稿することをおすすめします。
注: 2020 年 11 月 12 日時点で、Google Cloud Console 内の Anthos Service Mesh、Mesh CA、Anthos Service Mesh ダッシュボードはすべての GKE のユーザーが利用でき、Anthos の購入は不要です。詳細については、料金をご覧ください。
[1] Prisma Cloud SaaS バージョン管理者ガイド
[2] Twistlock 参照アーキテクチャ
-戦略的クラウド エンジニア Waheed Brown
-パートナー デリバリー マネージャー Jianhe Liao
