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 エンドポイントには、接続先のサービスであるターゲットが 1 つあります。

  • 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 ネットワークからリクエストが送信されると、送信元 NAT（SNAT）により、コンシューマーの送信元 IP アドレスが 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 アドレスで構成されます。

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 を使用してサービスを公開するをご覧ください。

プロデューサーの検証

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

Cloud Shell から次のコマンドを使用して、ServiceAttachment の詳細を表示できます。

kubectl describe serviceattachment emoji-sa

GKE L4 ILB を表示する

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

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

ed7a25ed4774977b.png

公開済みサービスを表示する

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

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

5a00836ee514b918.png

サービス名をクリックして次の画面に進み、[基本情報] に入力されたサービス アタッチメントの詳細を確認します。また、コンシューマーはまだサービスに登録していないため、「Connected Projects（接続されたプロジェクト）」は空になっています。接続設定が 「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

接続されたサービスを表示する

クラウド コンソールで、[ネットワーク サービス] → [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 コンソールで、[Identify Operations Logging] → [Log Explorer] を選択します。
  2. [Query] フィールドで、次のエントリを yourconsumerproject に更新し、[Run Query] を選択します。

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 は Producer Service へのアクセスに使用される静的 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 はすべての下り（外向き）トラフィックを許可しますが、すべての上り（内向き）トラフィックを拒否します。次の手順では、公開済みサービスへのアクセスを拒否するために、consumer-instance-2 の作成時に使用される、以前に定義したネットワーキング タグ「google2」に基づいてファイアウォール ルールを作成します。

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 コンソールで、[Identify Operations Logging] → [Log Explorer] を選択します。
  2. [Query] フィールドで、次のエントリを consumerproject に更新し、[Run Query] を選択します。

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 は静的 TCP IP、src_ip: 10.0.70.10 または 10.0.70.20 は VM インスタンスの IP アドレスです。対応状況が [Denied]（拒否）になっています。

a344f75f67590655.png

17. クリーンアップ手順

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

afe738fc869f0d6e.png

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