GKE で Private Service Connect を使用してサービスを公開して使用する

1. はじめに

Private Service Connect を使用すると、サービス プロデューサーはサービス コンシューマに非公開でサービスを提供できます。Private Service Connect には次の利点があります。

  • 1 つのサービス プロデューサー VPC ネットワークで複数のサービス コンシューマをサポートできます。
  • 各コンシューマは、コンシューマが定義した内部 IP アドレスに接続します。Private Service Connect は、ネットワーク アドレス変換（NAT）を行い、リクエストをサービス プロデューサーに転送します。

45b90d50690dd111.png

図 2. Private Service Connect はエンドポイントとサービス アタッチメントを使用して、サービス コンシューマがコンシューマの VPC ネットワークからサービス プロデューサーの VPC ネットワーク内のサービスにトラフィックを送信できるようにします（クリックして拡大）。

学習内容

  • Private Service Connect のメリット
  • サービス コンシューマに関する主なコンセプト
  • サービス プロデューサーの主なコンセプト
  • プロデューサー環境を作成する
  • サービス アタッチメントを介してサービス（プロデューサー環境）を公開する
  • コンシューマ環境を作成する
  • コンシューマ ネットワークに転送ルールを作成する
  • コンシューマ アクセスを検証する
  • ポリシーのアクセス制御を有効にする
  • 下り（外向き）ファイアウォール ルールを使用してコンシューマ転送ルールへのアクセスをブロックする

必要なもの

  • GKE クラスタとサービスのデプロイに関する知識
  • 内部ロードバランサに関する知識
  • 2 つのプロジェクトで VPC を作成可能
  • GKE クラスタを作成できる権限

2. Private Service Connect のメリット

PSC には、VPC ピアリングを使用する場合と比べていくつかの利点があります。

プライベート IP 空間の制御の強化

  • サービス ユーザーは、アクセスしたいマネージド サービスへの接続に使用するプライベート IP アドレスを制御できます。
  • サービス ユーザーは、VPC で利用されるバックエンド サービス用にプライベート IP アドレス範囲を予約することについて心配する必要はありません。プロデューサー サービスに接続するには、ご自分のサブネットから IP アドレスを選択するだけです。
  • サービス プロデューサーの場合、マルチテナント モデルのデプロイを選択できます。このモデルでは、複数のコンシューマ VPC にサービスを提供するサービスが VPC に含まれています。コンシューマのサブネット範囲が重複していても、問題が生じなくなりました。
  • サービス プロバイダの場合、必要な数の VM インスタンスにサービスをスケーリングでき、追加の IP アドレスについてコンシューマに連絡しなくても済みます。

セキュリティと分離の向上

  • サービス コンシューマの場合、サービス プロデューサーとの通信を開始できるのはご自身のみです。このような一方向の接続により、ファイアウォールの構成が大幅に簡素化されるだけでなく、サービス プロデューサーからの不正トラフィックによるリスクも軽減されます。
  • サービス プロデューサーの場合、コンシューマの VPC のサブネット範囲に基づいてファイアウォール ルールを変更する必要がありません。サービス用に構成された NAT IP アドレスの範囲に合わせてファイアウォール ルールを作成するだけです。

スケーラビリティの向上

  • PSC では、数千のコンシューマをサポートしてスケーラビリティに優れた設計を実現できます。また、サービス プロデューサーは、スケーラビリティに優れたマルチテナント サービスやシングル テナント サービスを提供できます。
  • PSC を使用するサービス コンシューマは、VPC で必要に応じてリソースを作成できます。このスケーリングは、プロデューサー VPC で作成されたリソースの数に影響されません。

3. サービス コンシューマの主なコンセプト

Private Service Connect エンドポイントを使用すると、VPC ネットワークの外部にあるサービスを使用できます。サービス ユーザーは、ターゲット サービスに接続する Private Service Connect エンドポイントを作成します。

Endpoints

ターゲット サービスには、Private Service Connect エンドポイントを使用して接続します。エンドポイントには VPC ネットワーク内の内部 IP アドレスが 1 つ割り振られています。エンドポイントは転送ルールのリソースに基づいています。

エンドポイントに送信されたトラフィックは、VPC ネットワーク外のターゲットに転送されます。

目標

Private Service Connect エンドポイントにはターゲット（接続先のサービス）があります。

  • API バンドル:
  • すべての API: ほとんどの Google API
  • VPC-SC: VPC Service Controls がサポートする API
  • 別の VPC ネットワーク内の公開サービス。このサービスは組織やサードパーティによって管理されます。

公開サービス

エンドポイントをサービス プロデューサーのサービスに接続するには、サービスのサービス アタッチメントが必要です。サービス アタッチメント URI の形式は projects/SERVICE_PROJECT/regions/REGION/serviceAttachments/SERVICE_NAME です。

4. サービス プロデューサーの主なコンセプト

コンシューマがサービスを利用できるようにするには、コンシューマ IP アドレスのネットワーク アドレス変換（NAT）に使用する専用サブネットを 1 つ以上作成します。次に、これらのサブネットを参照するサービス アタッチメントを作成します。

Private Service Connect サブネット

サービスを公開するために、サービス プロデューサーは Private Service Connect を目的として 1 つ以上のサブネットを作成します。

コンシューマの VPC ネットワークからリクエストが送信されると、コンシューマの送信元 IP アドレスが送信元 NAT（SNAT）を使用して Private Service Connect サブネットの 1 つから選択された IP アドレスに変換されます。

コンシューマの接続 IP アドレス情報を保持する場合は、コンシューマの接続情報の表示をご覧ください。

これらのサブネットは、VM インスタンスや転送ルールなどのリソースに使用できません。サブネットは、受信コンシューマ接続の SNAT に IP アドレスを提供する目的でのみ使用されます。

Private Service Connect サブネットには、63 個のコンシューマ VM ごとに少なくとも 1 つの IP アドレスが含まれている必要があります。これにより、各コンシューマ VM にネットワーク アドレス変換用の 1,024 個のソースタプルが割り当てられます。

Private Service Connect サブネットの最小サイズは /24 です。

サービス アタッチメント

サービス プロデューサーは、サービス アタッチメントを介してサービスを公開します。

  • サービスを公開するために、サービス プロデューサーは、サービスのロードバランサ転送ルールを参照するサービス アタッチメントを作成します。
  • サービス ユーザーは、サービスにアクセスするために、サービス アタッチメントを参照するエンドポイントを作成します。

接続の設定

サービスの作成時に、サービスの利用方法を選択します。次の 2 つの方法があります。

  • すべてのプロジェクトの接続を自動的に受け入れる - すべてのサービス コンシューマは、エンドポイントを構成して、自動的にサービスに接続できます。
  • 選択したプロジェクトの接続を受け入れる - サービス コンシューマがサービスに接続するようにエンドポイントを構成し、サービス プロデューサーが接続リクエストを承認または拒否します。

要件と制限事項

  • Private Service Connect の制限事項が適用されます。
  • サービス アタッチメントは、GKE バージョン 1.21.4-gke.300 以降で作成できます。
  • 複数サービスのアタッチメント構成で同じサブネットを使用することができない。
  • 内部 TCP / UDP ロードバランサを使用する GKE サービスを作成する必要があります。

5. テスト環境

コンシューマ ネットワークは、サービス プロデューサーへのリクエストの送信元に使用される静的 IP アドレスと、プロデューサーのサービス アタッチメント（公開サービス）にマッピングされる target-service-アタッチメントで構成されています。

1ce5607c0c56d77d.jpeg

次にプロデューサー ネットワークを 見ていきましょうプロデューサー ネットワークにはコンシューマ ネットワークへのマッピングがなく、代わりにプロデューサー ネットワークにはコンシューマがサービスに使用するサービス アタッチメント（公開サービス）が含まれています。プロデューサーのサービス アタッチメントは、GKE Ingress L4 ILB（公開済みのサービス）によって公開され、GKE Pod や関連アプリケーションと通信できます。

NAT サブネットはコンシューマ VPC ネットワークからリクエストが送信されるときに使用され、送信元 NAT（SNAT）により、コンシューマの送信元 IP アドレスが Private Service Connect のサブネットの 1 つから選択された IP アドレスに変換されます。

これらのサブネットは、VM インスタンスや転送ルールなどのリソースに使用できません。サブネットは、受信コンシューマ接続の SNAT に IP アドレスを提供する目的でのみ使用されます。

GKE Private Service Connect の L4ILB の詳細を確認し、このラボで使用するコンテンツに直接アクセスするには、 以下を参照してください。

セルフペース型の環境設定

  1. Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

  • プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列で、いつでも更新できます。
  • プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud Console により一意の文字列が自動生成されます（通常は内容を意識する必要はありません）。ほとんどの Codelab では、プロジェクト ID を参照する必要があります（通常、プロジェクト ID は「PROJECT_ID」の形式です）。好みの文字列でない場合は、別のランダムな ID を生成するか、独自の ID を試用して利用可能であるかどうかを確認することができます。プロジェクトの作成後、ID は「フリーズ」されます。
  • 3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
  1. 次に、Cloud のリソースや API を使用するために、Cloud Console で課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルを終了した後に課金が発生しないようにリソースをシャットダウンするには、Codelab の最後にある「クリーンアップ」の手順を行います。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。

Cloud Shell の起動

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。

bce75f34b2c53987.png

プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。

f6ef2b5f13479f3a.png

この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。

6. 始める前に

Codelab には 2 つのプロジェクトが必要ですが、PSC の要件ではありません。単一または複数のプロジェクトに対応するための参照にご注意ください。

単一プロジェクト - プロジェクトを更新してプロデューサー ネットワークとコンシューマ ネットワークをサポートする

Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
consumerproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

複数のプロジェクト - プロデューサー ネットワークをサポートするようにプロジェクトを更新する

Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
prodproject=YOUR-PROJECT-NAME
echo $prodproject

以下の色コードの規則に注意してください。

f251ebb137e37136.png

7. プロデューサー VPC ネットワークの作成

afe738fc869f0d6e.png

VPC ネットワーク

Cloud Shell から

gcloud compute networks create gke-producer-l4-vpc --project=$prodproject --subnet-mode=custom

GKE クラスタのサブネットを作成する

Cloud Shell から

gcloud compute networks subnets create node-subnet1 --project=$prodproject --range=192.168.10.0/24 --network=gke-producer-l4-vpc --region=us-central1 --secondary-range=pod=10.10.10.0/24,service=10.10.20.0/24 --enable-private-ip-google-access

GKE クラスタを作成する

Cloud Shell から

gcloud container clusters create gke-psc-l4 \
    --release-channel=rapid \
    --enable-ip-alias \
    --zone=us-central1-a \
    --network gke-producer-l4-vpc \
    --num-nodes 1 \
    --subnetwork node-subnet1 \
    --cluster-secondary-range-name pod \
    --services-secondary-range-name service

Private Service Connect 用のサブネット（NAT サブネット）を作成する

Private Service Connect で使用する専用サブネットを 1 つ以上作成する必要があります。Google Cloud コンソールを使用してサービスを公開する場合、その作業中にサブネットを作成できます。

Private Service Connect サブネットの詳細については、Private Service Connect サブネットをご覧ください。

Cloud Shell から

gcloud beta compute networks subnets create gke-nat-subnet \
    --project $prodproject \
    --network gke-producer-l4-vpc \
    --region us-central1 \
    --range 100.100.10.0/24 \
    --purpose PRIVATE_SERVICE_CONNECT

8. ワークロードとサービスをデプロイする

次のマニフェストは、サンプルのウェブ アプリケーション コンテナ イメージを実行する Deployment を記述しています。Cloud Shell でマニフェストを my-deployment.yaml として保存します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: psc-ilb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: psc-ilb
  template:
    metadata:
      labels:
        app: psc-ilb
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.1
        ports:
          - name: http
            containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 5
          timeoutSeconds: 1

Cloud Shell からクラスタにマニフェストを適用する

kubectl apply -f my-deployment.yaml

サービスの作成

次のマニフェストでは、TCP ポート 8080 に内部 TCP/UDP ロードバランサを作成するサービスを記述しています。Cloud Shell でマニフェストを my-service.yaml として保存します。

apiVersion: v1
kind: Service
metadata:
  name: gke-l4-psc
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  selector:
    app: psc-ilb
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Cloud Shell からクラスタにマニフェストを適用する

kubectl apply -f my-service.yaml

ServiceAttachment を作成する

次のマニフェストでは、作成したサービスをサービス コンシューマに公開する ServiceAttachment を記述しています。Cloud Shell でマニフェストを my-psc.yaml として保存します。

apiVersion: networking.gke.io/v1beta1
kind: ServiceAttachment
metadata:
 name: emoji-sa
 namespace: default
spec:
 connectionPreference: ACCEPT_AUTOMATIC
 natSubnets:
 - gke-nat-subnet
 proxyProtocol: false
 resourceRef:
   kind: Service
   name: gke-l4-psc

Cloud Shell からクラスタにマニフェストを適用する

kubectl apply -f my-psc.yaml

ServiceAttachment には次のフィールドがあります。

  • connectionPreference: お客様によるサービスへの接続方法を決定する接続設定。ACCEPT_AUTOMATIC を使用してプロジェクトの自動承認を使用するか、ACCEPT_MANUAL を使用してプロジェクトを明示的に承認できます。詳細については、Private Service Connect を使用してサービスを公開するをご覧ください。
  • natSubnets: サービス アタッチメントに使用するサブネットワーク リソース名のリスト。
  • proxyProtocol: true に設定すると、リクエストでコンシューマのソース IP と Private Service Connect の接続 ID を使用できます。このフィールドは省略可能で、指定しない場合はデフォルトの false になります。
  • consumerAllowList: ServiceAttachment への接続を許可されたコンシューマ プロジェクトのリスト。このフィールドは、connectionPreference が ACCEPT_MANUAL の場合にのみ使用できます。このフィールドとその他のオプションの詳細については、Private Service Connect を使用してサービスを公開するをご覧ください。

プロデューサーの検証

サービス アタッチメントの詳細の表示

ServiceAttachment の詳細を表示するには、Cloud Shell から次のコマンドを使用します。

kubectl describe serviceattachment emoji-sa

GKE L4 ILB を表示する

Cloud コンソールで、[ネットワーク サービス] → [ロード バランシング] → [フロントエンド] に移動します。

以前に定義したノードのサブネット 192.168.10.0/24 に一致するフロントエンド IP アドレスを特定します。以下のスクリーンショットに注意してください。IP アドレスは異なる場合があります。

ed7a25ed4774977b.png

公開サービスを表示する

Cloud コンソールから、[ネットワーク サービス] → [Private Service Connect] → [公開サービス] に移動します。

ラボで使用されているネットワークで使用されているサービスを特定します（gke-producer-l4-vpc,）。以下のスクリーンショットをご覧ください（Service とターゲットの値は異なる場合があります）。

5a00836ee514b918.png

サービス名をクリックして下の画面に進みます。[Basic Info] にサービス アタッチメントの詳細が入力されています。「接続されているプロジェクト」もコンシューマがまだサービスに登録していないため、 は空になります。[接続の設定] が [ACCEPT_AUTOMATICALLY] に設定されているため、ACCEPT と REJECT はグレー表示されたままになります。このオプションは、サービス アタッチメントの yaml（my-psc.yaml）を変更すれば、いつでも "ACCEPT_MANUAL" に変更できます。

497f5f43920018c0.png

e246063a23771273.png

9. コンシューマ VPC ネットワークの作成

1f3c90f1e139e906.png

次のセクションでは、コンシューマ VPC を別のプロジェクトで構成します。コンシューマ ネットワークとプロデューサー ネットワーク間の通信は、コンシューマ ネットワークで定義されているサービス アタッチメントを介して行われます。

Codelab には 2 つのプロジェクトが必要ですが、PSC の要件ではありません。単一または複数のプロジェクトに対応するための参照にご注意ください。

単一プロジェクト - プロジェクトを更新してプロデューサー ネットワークとコンシューマ ネットワークをサポートする

Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
prodproject=YOUR-PROJECT-NAME
echo $prodproject
echo $consumerproject

複数のプロジェクト - プロジェクトを更新してコンシューマ ネットワークをサポートする

Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
consumerproject=YOUR-PROJECT-NAME
echo $consumerproject

VPC ネットワーク

Cloud Shell から

gcloud compute networks create vpc-demo-consumer --project=$consumerproject --subnet-mode=custom

PSC 用のサブネットを作成する

Cloud Shell から

gcloud compute networks subnets create consumer-subnet --project=$consumerproject  --range=10.0.60.0/24 --network=vpc-demo-consumer --region=us-central1

VM インスタンスのサブネットを作成する

Cloud Shell から

gcloud compute networks subnets create consumer-subnet-vm --project=$consumerproject  --range=10.0.70.0/24 --network=vpc-demo-consumer --region=us-central1

静的 IP アドレスを作成して公開サービスにアクセスする

Cloud Shell から

gcloud compute addresses create vpc-consumer-psc --region=us-central1 --subnet=consumer-subnet --addresses 10.0.60.100

ファイアウォール ルールを作成する

IAP に VM インスタンスへの接続を許可するには、次のファイアウォール ルールを作成します。

  • IAP を使用してアクセスできるようにするすべての VM インスタンスに適用します。
  • IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可する。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています

Cloud Shell から

gcloud compute firewall-rules create psclab-iap-consumer --network vpc-demo-consumer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging

PSC では必須ではありませんが、プロデューサー サービス アタッチメントへのコンシューマ PSC トラフィックをモニタリングする下り（外向き）ファイアウォール ルールを作成します。

gcloud compute --project=$consumerproject firewall-rules create vpc-consumer-psc --direction=EGRESS --priority=1000 --network=vpc-demo-consumer --action=ALLOW --rules=all --destination-ranges=10.0.60.0/24 --enable-logging

10. コンシューマ テスト インスタンス 1 を作成する

Cloud Shell から

gcloud compute instances create consumer-instance-1 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.10 --no-address --subnet=consumer-subnet-vm --tags=google1 --image-family=debian-10 --image-project=debian-cloud

11. コンシューマ テスト インスタンス 2 を作成する

Cloud Shell から

gcloud compute instances create consumer-instance-2 --zone=us-central1-a --machine-type=e2-micro --private-network-ip=10.0.70.20 --no-address --subnet=consumer-subnet-vm --tags=google2 --image-family=debian-10 --image-project=debian-cloud

12. サービス アタッチメントを作成する

前のステップでは、プロデューサー サービス アタッチメントの文字列を安全な場所にコピーしたので、保存した値を「target-service-attachment」に挿入しましょう。表示されます。

7abaccc4e24f1ef7.png

Cloud Shell から

gcloud compute forwarding-rules create vpc-consumer-psc-fr --region=us-central1 --network=vpc-demo-consumer --address=vpc-consumer-psc --target-service-attachment=yoursavedproducerserviceattachment

13. 検証 - コンシューマー

CURL とファイアウォール ログを使用して、コンシューマとプロデューサーの通信を検証します。

コンシューマのプロジェクト内では、静的 IP アドレスを使用してプロデューサーとの通信を開始します。この静的 IP アドレスとコンシューマ転送ルールのマッピングは、次の構文を実行して検証します。

1f3c90f1e139e906.png

コンシューマ VPC から Cloud Shell を使用して転送ルールと静的 IP を特定します。

gcloud compute forwarding-rules describe vpc-consumer-psc-fr --region us-central1

以下の出力。後のステップでプロデューサーに到達するために 10.0.60.100 を使用します。

IPAddress: 10.0.60.100
creationTimestamp: '2021-09-30T21:13:54.124-07:00'
id: '3564572805904938477'
kind: compute#forwardingRule
labelFingerprint: 42WmSpB8rSM=
name: vpc-consumer-psc-fr
network: https://www.googleapis.com/compute/v1/projects/deepakmichaelstage/global/networks/vpc-demo-consumer
networkTier: PREMIUM
pscConnectionId: '36583161500548196'
pscConnectionStatus: ACCEPTED

連携サービスを表示する

Cloud コンソールから、[ネットワーク サービス] → [Private Service Connect] → [接続エンドポイントと接続] に移動します。新しく作成したエンドポイントを表示する

206bc00297aaa260.png

consumer-instance-1 にログインし、プロデューサー公開サービスへのアクセスをテストします。

Cloud Shell で [+] をクリックして新しいタブを開きます

81f3210b29faebd3.png

Cloud Shell から、次の手順を行います。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-1" --project "$projectname"

consumer-instance-1 インスタンスにログインしたら、転送ルールの IP アドレス 10.0.60.100 に対して curl を実行します。

Cloud Shell から、次の手順を行います。

user@consumer-instance-1:~$ curl 10.0.60.100

出力例

user@consumer-instance-1:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodprojectid.internal",
  "pod_name": "psc-ilb-588887dfdb-w7tbr",
  "pod_name_emoji": "🤷",
  "project_id": "prodorijectid",
  "timestamp": "2021-10-01T17:43:37",
  "zone": "us-central1-a"

consumer-instance-2 にログインし、プロデューサー公開サービスへのアクセスをテストします。

Cloud Shell で [+] をクリックして新しいタブを開きます

81f3210b29faebd3.png

Cloud Shell から、次の手順を行います。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

Cloud Shell から、次の手順を行います。

user@consumer-instance-2:~$ curl 10.0.60.100

出力例

deepakmichael@consumer-instance-2:~$ curl 10.0.60.100
{
  "cluster_name": "gke-psc-l4",
  "host_header": "10.0.60.100",
  "node_name": "gke-gke-psc-l4-default-pool-f2c6e301-vnlz.c.prodproject.internal",
  "pod_name": "psc-ilb-588887dfdb-4jdql",
  "pod_name_emoji": "🧑🏿",
  "project_id": "prodproject",
  "timestamp": "2021-10-01T17:49:51",
  "zone": "us-central1-a"

14. ファイアウォールのロギング - 割り当てられた検証

ログ エクスプローラを使用してファイアウォール ルール「vpc-consumner-psc」を検証するVM のインスタンスと静的 IP の間のフローをキャプチャし、

  1. Cloud コンソールから、[オペレーション ロギングの特定] → [ログ エクスプローラ] に移動します。
  2. [クエリ] フィールドで、以下のエントリを「yourconsumerproject」に変更し、[クエリを実行] を選択します。

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:vpc-consumer-psc")

  1. 提供されたスクリーンショットに従って、クエリ結果は次のようになります。

23e427b3060473.png

  1. ログを開き（jsonPayload → Connection）、以下の出力を確認します。dest_ip に注目してください。10.0.60.100 はプロデューサー サービスへのアクセスに使用される STATIC TCP IP で、src_ip: 10.0.70.10 または 10.0.70.20 は VM インスタンスの IP アドレスです。廃棄は許可されています。

2669743fd1f1cb0d.png

15. 検証 - プロデューサー

afe738fc869f0d6e.png

プロデューサー プロジェクトで、サービス アタッチメントが正常に接続されていることを確認します。[ネットワーク サービス] → [Private Service Connect] → [公開サービス] に移動します。

89ded87a63888f60.png

サービスをクリックすると、次の図のように、接続されたコンシューマ プロジェクトとステータスが表示されます。

15966d47423ebc5f.png

16. 公開サービスへのアクセスを制限する

1f3c90f1e139e906.png

ここまでで、両方のインスタンスが公開サービスにアクセスできることを確認できました。では、consumer-instance-2 の公開サービス アクセスを拒否する下り（外向き）ファイアウォール ルールを作成しましょう。

デフォルトでは、GCP はすべての下り（外向き）を許可し、上り（内向き）トラフィックはすべて拒否します。次の手順では、以前に定義したネットワーク タグ「google2」に基づいてファイアウォール ルールを作成します。consumer-instance-2 を作成する際に使用し、公開サービスへのアクセスを拒否します。

7fa2cda1dfec33a.png

Cloud Shell で [+ 次のファイアウォール ルールを実行] をクリックして、新しい Cloud Shell タブを開きます。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute --project=$projectname firewall-rules create psc-endpoint-deny-egress --direction=EGRESS --priority=999 --network=vpc-demo-consumer --action=DENY --rules=all --destination-ranges=10.0.60.100/32 --target-tags=google2 --enable-logging

次に、consumer-instance-2 が公開サービスにアクセスできるかどうかをテストします。セッションがタイムアウトした場合は、以下で説明するように、新しい Cloud Shell を開き、VM にログインする必要があります。

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
projectname=YOUR-PROJECT-NAME
echo $projectname

gcloud compute ssh --zone "us-central1-a" "consumer-instance-2" --project "$projectname"

Cloud Shell から、次の手順を行います。

user@consumer-instance-2:~$ curl 10.0.60.100

出力例

user@consumer-instance-2:~$ curl 10.0.60.100
curl: (7) Failed to connect to 10.0.60.100 port 80: Connection timed out

ファイアウォール ロギング - 拒否検証

ログ エクスプローラを使用してファイアウォール ルール「psc-endpoint-deny-egress」を検証するVM インスタンスと静的 IP の間のフローをキャプチャし、

  1. Cloud コンソールから、[オペレーション ロギングの特定] → [ログ エクスプローラ] に移動します。
  2. [クエリ] フィールドで、consumerproject を使用して以下のエントリを更新し、[クエリを実行] を選択します。

logName:(projects/yourconsumerprojectID/logs/compute.googleapis.com%2Ffirewall) AND jsonPayload.rule_details.reference:("network:vpc-demo-consumer/firewall:psc-endpoint-deny-egress")

  1. 提供されたスクリーンショットに従って、クエリ結果は次のようになります。

83b4fc7348ac93cd.png

  1. ログを開き、以下の出力を確認します。dest_ip に注目してください。10.0.60.100 は STATIC TCP IP で、src_ip: 10.0.70.10 または 10.0.70.20 は VM インスタンスの IP アドレスです。処理が拒否されました。

a344f75f67590655.png

17. クリーンアップ手順

プロデューサー ネットワークのクリーンアップ手順

afe738fc869f0d6e.png

Producer Project ターミナルの単一の Cloud Shell から、ラボのコンポーネントを削除する

gcloud container clusters delete gke-psc-l4 --region us-central1-a --quiet

gcloud compute networks subnets delete gke-nat-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete node-subnet1 --region=us-central1 --quiet

gcloud compute networks delete gke-producer-l4-vpc --quiet

1f3c90f1e139e906.png

コンシューマー ネットワークのクリーンアップ手順

コンシューマ プロジェクトのターミナルで単一の Cloud Shell からラボのコンポーネントを削除する

gcloud compute instances delete consumer-instance-1 --zone=us-central1-a --quiet

gcloud compute instances delete consumer-instance-2 --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete vpc-consumer-psc-fr --region=us-central1 --quiet

gcloud compute addresses delete vpc-consumer-psc --region=us-central1 --quiet

gcloud compute firewall-rules delete psclab-iap-consumer --quiet

gcloud compute networks subnets delete consumer-subnet --region=us-central1 --quiet

gcloud compute networks subnets delete consumer-subnet-vm --region=us-central1 --quiet

gcloud compute firewall-rules delete vpc-consumer-psc --quiet

gcloud compute firewall-rules delete psc-endpoint-deny-egress --quiet

gcloud compute networks delete vpc-demo-consumer --quiet

18. 完了

以上で、この Codelab は完了です。

学習した内容

  • Private Service Connect のメリット
  • サービス コンシューマに関する主なコンセプト
  • サービス プロデューサーの主なコンセプト
  • プロデューサー環境を作成する
  • サービス アタッチメントを介してサービス（プロデューサー環境）を公開する
  • コンシューマ環境を作成する
  • コンシューマ ネットワークに転送ルールを作成する
  • コンシューマ アクセスを検証する
  • ポリシーのアクセス制御を有効にする
  • 下り（外向き）ファイアウォール ルールを使用して、コンシューマ転送ルールへのアクセスをブロックした