Workflows で Service Directory のサービス レジストリを使用すると、ワークフローの実行から HTTP 呼び出しのプライベート エンドポイントをターゲットにできます。Virtual Private Cloud（VPC）ネットワーク内にプライベート エンドポイントを作成することで、エンドポイントを VPC Service Controls に準拠させることが可能です。
VPC Service Controls は、Identity and Access Management（IAM）から独立した追加のセキュリティ防御レイヤを提供します。IAM では詳細な ID ベースのアクセス制御が可能ですが、VPC Service Controls では、境界全体での下り（外向き）データの制御など、コンテキスト ベースの境界セキュリティが可能になります。
Service Directory は、登録済みネットワーク サービスに関する情報（名前、ロケーション、属性など）を保存するサービス レジストリです。インフラストラクチャに関係なく、サービスを自動的に登録して詳細を取得できます。これにより、すべてのサービス エンドポイントに対して大規模なサービスの検出、公開し、接続ができます。
VPC ネットワークは、仮想マシン（VM）インスタンスに接続性を提供し、内部 IP アドレスを使用して VPC ネットワーク内にプライベート エンドポイントを作成できるようにします。VPC ネットワーク リソースへの HTTP 呼び出しは、IAM と VPC Service Controls を適用しながらプライベート ネットワーク経由で送信されます。
VPC Service Controls は、サービス境界の設定とデータ転送の境界の作成を可能にする、Google Cloud の機能です。Workflows で VPC Service Controls を使用すると、サービスを保護し、データ引き出しのリスクを軽減できます。
このドキュメントでは、VPC ネットワーク内の VM を Service Directory エンドポイントとして登録する方法について説明します。これにより、ワークフローに Service Directory サービス名を指定できます。ワークフローの実行では、サービス レジストリから取得した情報を使用して、公共のネットワークに出ることなく、適切な HTTP リクエストを送信します。
次の図に概要を示します。
大まかには以下を行う必要があります。
- Cloud Workflows サービス エージェントに権限を付与して、サービス エージェントが Service Directory リソースを表示し、Service Directory を使用して VPC ネットワークにアクセスできるようにします。
- VPC ネットワークを作成して、ネットワーキング機能を提供します。
- VPC ファイアウォール ルールを作成して、VPC ネットワーク内の VM インスタンスとの間で送受信されるトラフィックを許可または拒否できるようにします。
- VPC ネットワークに VM インスタンスを作成します。Compute Engine VM インスタンスは、Google のインフラストラクチャでホストされる仮想マシンです。Compute Engine インスタンス、VM インスタンス、VM という用語は同義語であり、同じ意味で使用されています。
- VM にアプリケーションをデプロイします。VM インスタンスでアプリを実行し、トラフィックが想定どおりに処理されていることを確認できます。
ワークフローの実行で Service Directory エンドポイントを呼び出せるように、Service Directory を構成します。
ワークフローを作成してデプロイします。ワークフローの
private_service_name値は、前の手順で登録した Service Directory エンドポイントを指定します。
Cloud Workflows サービス エージェントに権限を付与する
一部の Google Cloud サービスでは、ユーザーのリソースにアクセスするために、サービス エージェントを使用します。API にサービス エージェントが必要な場合は、API を有効にして使用した後、サービス エージェントが作成されます。
初めてワークフローをデプロイすると、Cloud Workflows サービス エージェントが次の形式で自動的に作成されます。
service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com次のコマンドを使用して、ワークフローを使用せずにプロジェクトにサービス アカウントを手動で作成できます。
gcloud beta services identity create \ --service=workflows.googleapis.com \ --project=PROJECT_ID
PROJECT_IDは、実際の Google Cloud プロジェクト ID に置き換えます。Service Directory リソースを表示するには、プロジェクトの Service Directory 閲覧者のロール（
servicedirectory.viewer）を Workflows サービス エージェントに付与します。gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com \ --role=roles/servicedirectory.viewer
PROJECT_NUMBERは、実際の Google Cloud プロジェクトの番号に置き換えます。プロジェクト番号は、Google Cloud コンソールの [ようこそ] ページで確認できます。また、次のコマンドで確認することもできます。gcloud projects describe PROJECT_ID --format='value(projectNumber)'
Service Directory を使用して VPC ネットワークにアクセスするには、プロジェクトの Private Service Connect 承認済みサービスのロール（
roles/servicedirectory.pscAuthorizedService）を Workflows サービス エージェントに付与します。gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-workflows.iam.gserviceaccount.com \ --role=roles/servicedirectory.pscAuthorizedService
VPC ネットワークの作成
VPC ネットワークは、Google の本番環境ネットワーク内に仮想的に実装された物理ネットワークです。Compute Engine VM インスタンスへの接続性を提供します。
自動モードまたはカスタムモードの VPC ネットワークを作成できます。新しく作成した各ネットワークには、同じプロジェクト内で一意の名前を付ける必要があります。
たとえば、次のコマンドは自動モードの VPC ネットワークを作成します。
gcloud compute networks create NETWORK_NAME \ --subnet-mode=auto
NETWORK_NAME は、VPC ネットワークの名前に置き換えます。
詳細については、VPC ネットワークを作成して管理するをご覧ください。
VPC ファイアウォール ルールを作成する
VPC ファイアウォール ルールを使用すると、ポート番号、タグ、プロトコルに基づいて、VPC ネットワーク内の VM インスタンスとの間で送受信されるトラフィックを許可または拒否できます。
VPC ファイアウォール ルールはネットワーク レベルで定義され、ルールが作成されたネットワークにのみ適用されます。ただし、ルールに使用する名前はプロジェクトごとに一意である必要があります。
たとえば、次のコマンドは、指定された VPC ネットワークのファイアウォール ルールを作成し、任意の IPv4 アドレス 0.0.0.0/0 からの内向きトラフィックを許可します。--rules フラグの値を all にすると、すべてのプロトコルと宛先ポートにルールが適用されます。
gcloud compute firewall-rules create RULE_NAME \ --network=projects/PROJECT_ID/global/networks/NETWORK_NAME \ --direction=INGRESS \ --action=ALLOW \ --source-ranges=0.0.0.0/0 \ --rules=all
RULE_NAME は、ファイアウォール ルールの名前に置き換えます。
詳細については、VPC ファイアウォール ルールをご覧ください。
VPC ネットワークに VM インスタンスを作成する
VM インスタンスには、Google Kubernetes Engine（GKE）クラスタ、App Engine フレキシブル環境インスタンス、Compute Engine VM 上に構築された他の Google Cloud プロダクトが含まれます。プライベート ネットワーク アクセスをサポートするために、VPC ネットワーク リソースは、VM インスタンス、Cloud Interconnect IP アドレス、またはレイヤ 4 内部ロードバランサにできます。
Compute Engine インスタンスでは、Google が提供する Linux 用または Windows Server 用の公開イメージだけでなく、独自に作成したか既存のシステムからインポートした非公開のカスタム イメージも実行できます。Docker コンテナをデプロイすることもできます。
インスタンスのマシン プロパティ（仮想 CPU の数やメモリの容量など）を選択するには、事前定義されたマシンタイプのセットを使用するか、または独自のカスタム マシンタイプを作成します。
たとえば、次のコマンドは、以前に作成した VPC ネットワークにネットワーク インターフェースが接続された公開イメージから Linux VM インスタンスを作成します。
VM インスタンスを作成して起動します。
gcloud compute instances create VM_NAME \ --image-family=debian-11 \ --image-project=debian-cloud \ --machine-type=e2-micro \ --network-interface network=projects/PROJECT_ID/global/networks/NETWORK_NAME
VM_NAMEは VM の名前に置き換えます。インスタンスのゾーンを確認するよう求められたら、
yと入力します。VM インスタンスを作成したら、返された
INTERNAL_IPアドレスをメモします。Google Cloud コンソールで [VM インスタンス] ページに移動します。
[名前] 列で、適切な VM インスタンスの名前をクリックします。
VM が実行されている場合は、VM を停止するには、 [停止] をクリックします。
VM を編集するには、 [編集] をクリックします。
[ネットワーキング] > [ファイアウォール] セクションで、VM への HTTP または HTTPS トラフィックを許可するには、[HTTP トラフィックを許可する] または [HTTPS トラフィックを許可する] を選択します。
この例では、[HTTP トラフィックを許可する] チェックボックスをオンにします。
Compute Engine は、ファイアウォール ルールを VM に関連付けるネットワーク タグを VM に追加します。その後、対応する内向きファイアウォール ルールを作成し、
tcp:80（HTTP）またはtcp:443（HTTPS）で受信するすべてのトラフィックを許可します。変更を保存するには、[保存] をクリックします。
VM を再起動するには、[開始 / 再開] をクリックします。
詳しくは、VM インスタンスの作成と開始をご覧ください。
VM にアプリケーションをデプロイする
ネットワーク構成をテストし、トラフィックが期待どおりに提供されていることを確認するには、ポートをリッスンするシンプルなアプリを VM にデプロイします。
たとえば、次のコマンドはポート 3000 でリッスンする Node.js ウェブサービスを作成します。
VM インスタンスとの SSH 接続を確立します。
パッケージ リポジトリを更新します。
sudo apt update
-
詳細については、Node.js 開発環境の設定をご覧ください。
package.jsonファイルをインタラクティブに作成します。npm init次に例を示します。
{ "name": "test", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "hello" }, "author": "", "license": "ISC" }
Node.js 用のウェブ アプリケーション フレームワークである Express をインストールします。
npm install express
テストアプリのコードを書きます。
vim app.js次のサンプルでは、ルートパス（
/）へのGETリクエストに「Hello, world!」というテキストで応答するアプリを作成します。アプリがリッスンしているポートをメモします。Service Directory サービスのエンドポイントを構成する場合は、同じポート番号を使用する必要があります。
アプリがポート 3000 でリッスンしていることを確認します。
node app.js
Compute Engine には、さまざまなデプロイ オプションが用意されています。詳細については、ワークロードに対する Compute Engine のデプロイ戦略を選択するをご覧ください。
Service Directory を構成する
ワークフローの実行からプライベート エンドポイントの呼び出しをサポートするには、Service Directory 名前空間を設定し、名前空間にサービスを登録し、サービスにエンドポイントを追加する必要があります。
たとえば、次のコマンドは、名前空間、サービス、VM インスタンスの VPC ネットワークと内部 IP アドレスを指定するエンドポイントを作成します。
Namespace を作成します。
gcloud service-directory namespaces create NAMESPACE \ --location=REGION
以下を置き換えます。
NAMESPACE: Namespace の ID または Namespace の完全修飾識別子。REGION: 名前空間を含む Google Cloud リージョン（us-central1など）。
サービスを作成します。
gcloud service-directory services create SERVICE \ --namespace=NAMESPACE \ --location=REGION
SERVICEは、作成するサービスの名前に置き換えます。エンドポイントを構成します。
gcloud service-directory endpoints create ENDPOINT \ --namespace=NAMESPACE \ --service=SERVICE \ --network=projects/PROJECT_NUMBER/locations/global/networks/NETWORK_NAME \ --port=PORT_NUMBER \ --address=IP_ADDRESS \ --location=REGION
以下を置き換えます。
ENDPOINT: 作成するエンドポイントの名前。PORT_NUMBER: エンドポイントが実行されているポート。例:3000。IP_ADDRESS: エンドポイントの IPv6 アドレスまたは IPv4 アドレス。これは、以前にメモした内部 IP アドレスです。
詳細については、Service Directory の構成とプライベート ネットワーク アクセスの構成をご覧ください。
ワークフローを作成してデプロイする
Workflows からのプライベート エンドポイントの呼び出しは、HTTP リクエストを介して行われます。最も一般的な HTTP リクエスト メソッドには、呼び出しショートカット（http.get、http.post など）がありますが、call フィールドを http.request に設定し、method フィールドでリクエストのタイプを指定することであらゆるタイプの HTTP リクエストを作成できます。詳細については、HTTP リクエストを行うをご覧ください。
ワークフローのソースコード ファイルを作成します。
touch call-private-endpoint.JSON_OR_YAMLワークフローの形式に応じて、
JSON_OR_YAMLをyamlまたはjsonに置き換えます。テキスト エディタで、次のワークフロー（この場合は
url値に HTTP プロトコルを使用）をソースコード ファイルにコピーします。YAML
main: steps: - checkHttp: call: http.get args: url: http://IP_ADDRESS private_service_name: "projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE" result: res - ret: return: ${res}
JSON
{ "main": { "steps": [ { "checkHttp": { "call": "http.get", "args": { "url": "http://IP_ADDRESS", "private_service_name": "projects/PROJECT_ID/locations/REGION/namespaces/NAMESPACE/services/SERVICE" }, "result": "res" } }, { "ret": { "return": "${res}" } } ] } }
private_service_name値は、登録済の Service Directory サービス名を次の形式で指定する文字列にする必要があります。projects/PROJECT_ID/locations/LOCATION/namespaces/NAMESPACE_NAME/services/SERVICE_NAMEワークフローをデプロイします。テスト目的で、ワークフローに Compute Engine のデフォルトのサービス アカウントを関連付けて、その ID を示すことができます。
gcloud workflows deploy call-private-endpoint \ --source=call-private-endpoint.JSON_OR_YAML \ --location=REGION \ --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com
ワークフローを実行します。
gcloud workflows run call-private-endpoint \ --location=REGION
次のような結果が表示されます。
argument: 'null' duration: 0.650784403s endTime: '2023-06-09T18:19:52.570690079Z' name: projects/968807934019/locations/us-central1/workflows/call-private-endpoint/executions/4aac88d3-0b54-419b-b364-b6eb973cc932 result: '{"body":"Hello, world!","code":200,"headers":{"Connection":"keep-alive","Content-Length":"21","Content-Type":"text/html; charset=utf-8","Date":"Fri, 09 Jun 2023 18:19:52 GMT","Etag":"W/\"15-NFaeBgdti+9S7zm5kAdSuGJQm6Q\"","Keep-Alive":"timeout=5","X-Powered-By":"Express"}}' startTime: '2023-06-09T18:19:51.919905676Z' state: SUCCEEDED
次のステップ
- Private Service Connect について学習する。
- VPC Service Controls を使用してサービス境界を設定する。
- IAP を有効にして、プライベート オンプレミス、Compute Engine、GKE、その他のエンドポイントを呼び出す。