このページの内容は Apigee と Apigee ハイブリッドに該当します。
Apigee Edge のドキュメントを表示する。
Apigee は VPC Service Controls と統合されているため、Google Cloud プロジェクトのリソースを分離できます。これによりデータの漏洩や引き出しを防ぎます。
このセクションでは、Apigee で VPC Service Controls を使用する方法について説明します。
概要
VPC Service Controls では、プロジェクトと他のサービスの境界として機能するサービス境界を定義します。サービス境界は、データの引き出しリスクを軽減するための、プロジェクト内の Google Cloud サービスを保護する組織レベルの方法です。
VPC Service Controls は、境界内でリソースへのプライベート アクセス権を付与されているクライアントに対して、境界外の未承認のリソースへのアクセス権が付与されないようにすることもできます。
サービス境界の利点の詳細については、VPC Service Controls の概要をご覧ください。
VPC Service Controls を使用する場合は、次の点に注意してください。
- Google Cloud プロジェクトと関連するランタイムは、そのプロジェクトの VPC Service Controls の境界内に含まれています。
- 境界内部のサービス間のやり取りは、VPC ネットワーク アクセス可能なサービス機能を使用して制限できます。
Apigee と Apigee ハイブリッドはどちらも VPC Service Controls と統合されています。VPC Service Controls と統合されているプロダクトの完全なリストについては、サポートされているプロダクトをご覧ください。
インターネット接続への影響
VPC Service Controls を有効にすると、インターネットへのアクセスが無効になります(Apigee ランタイムが公共のインターネット ターゲットと通信しなくなります)。カスタムルートを確立して、トラフィックを VPC にルーティングする必要があります。カスタムルートのインポートとエクスポートをご覧ください。
Apigee を使用した VPC Service Controls の設定
Apigee で VPC Service Controls を設定する一般的な手順は次のとおりです。
- VPC Service Controls を有効化します。
- 新しいサービス境界を作成します。
- サービス境界を構成します。
以下では、これらの手順について詳しく説明します。
Apigee で VPC Service Controls を設定するには:
-
次のコマンドを実行して、ネットワークから Apigee へのピアリング接続で VPC Service Controls を有効にします。
gcloud services vpc-peerings enable-vpc-service-controls \ --network=SHARED_VPC_NETWORK --project=PROJECT_ID
各要素の意味は次のとおりです。
- SHARED_VPC_NETWORK: 共有 VPC ネットワークの名前。
- PROJECT_ID は、共有 VPC ネットワークをホストするプロジェクトの名前です。Apigee 組織の作成に使用されるプロジェクトではありません。
このコマンドを実行すると、プロジェクトで VPC Service Controls が有効になります。複数回実行すると、複数のプロジェクトで VPC Service Controls を有効にできます。
-
VPC Service Controls のクイックスタートの説明に沿って、新しい境界を作成します。境界を作成する際は、その境界内に追加するプロジェクトと保護するサービスを選択します。
Apigee と Apigee ハイブリッドについては、境界(Apigee API を含む)を作成する際に、すべてのサービスを保護することをおすすめします。
詳細については、サービス境界の作成をご覧ください。
- サービス境界の詳細と構成の説明に沿って、サービス境界を構成します。
境界内に統合ポータルを追加するには、統合ポータルを境界に追加するをご覧ください。
Apigee ハイブリッドによる VPC Service Controls の設定
Apigee ハイブリッドは VPC Service Controls をサポートしていますが、行う必要がある追加の手順が存在します。Apigee ハイブリッドを VPC Service Controls と統合するための一般的なプロセスは次のとおりです。
- プライベート接続を設定する。
- 境界内で追加サービスを保護する。
- 非公開リポジトリを設定する(非公開リポジトリは境界内にあり、境界内に存在している限り、必ずしもローカル リポジトリであることを必要としません)。
- Apigee イメージを非公開リポジトリに push する。
- ハイブリッド インストールと構成プロセス中にプ非公開リポジトリを使用するようにオーバーライドを更新します。
これらの各ステップについては、次の手順で詳しく説明します。
Apigee ハイブリッドで VPC Service Controls を設定するには:
- Google API およびサービスへのプライベート接続を設定するの説明に従って、ハイブリッド ネットワーク ホストのプライベート IP アドレスを設定します。これには、Google API がこれらのプライベート IP にアクセスできるように、ルート、ファイアウォール ルール、DNS エントリを構成することが含まれます。
-
Apigee での VPC Service Controls の設定の手順に沿って操作します。
このプロセスでは、境界内で Apigee 用に指定されたサービスに加え、次のサービスを保護する必要があります。
- Anthos Service Mesh
- Cloud Monitoring(Stackdriver)
- Google Kubernetes Engine(GKE で実行している場合)
- Google Container Registry(これをローカル リポジトリとして使用する場合)
これらのサービスを境界に追加するには、サービス境界の詳細と構成の手順に沿って操作してください。
- Apigee イメージを非公開リポジトリにコピーします。
-
こちらの説明に沿って、署名付きの Apigee イメージを Docker Hub からダウンロードします。必ず最新のバージョン番号を指定してください。
例:
docker pull google/apigee-installer:1.3.3 docker pull google/apigee-authn-authz:1.3.3 docker pull google/apigee-mart-server:1.3.3 docker pull google/apigee-synchronizer:1.3.3 docker pull google/apigee-runtime:1.3.3 docker pull google/apigee-hybrid-cassandra-client:1.3.3 docker pull google/apigee-hybrid-cassandra:1.3.3 docker pull google/apigee-cassandra-backup-utility:1.3.3 docker pull google/apigee-udca:1.3.3 docker pull google/apigee-stackdriver-logging-agent:1.6.8 docker pull google/apigee-prom-prometheus:v2.9.2 docker pull google/apigee-stackdriver-prometheus-sidecar:0.7.5 docker pull google/apigee-connect-agent:1.3.3 docker pull google/apigee-watcher:1.3.3 docker pull google/apigee-operators:1.3.3 docker pull google/apigee-kube-rbac-proxy:v0.4.1
-
イメージにタグを付けます。
次の例では、米国に拠点を置く GCR リポジトリ内のイメージにタグを付けます。
docker tag google/apigee-installer:1.3.3 us.gcr.io/project_ID/apigee-installer:1.3.3 docker tag google/apigee-authn-authz:1.3.3 us.gcr.io/project_ID/apigee-authn-authz:1.3.3 docker tag google/apigee-mart-server:1.3.3 us.gcr.io/project_ID/apigee-mart-server:1.3.3 docker tag google/apigee-synchronizer:1.3.3 us.gcr.io/project_ID/apigee-synchronizer:1.3.3 docker tag google/apigee-runtime:1.3.3 us.gcr.io/project_ID/apigee-runtime:1.3.3 docker tag google/apigee-hybrid-cassandra-client:1.3.3 us.gcr.io/project_ID/apigee-hybrid-cassandra-client:1.3.3 docker tag google/apigee-hybrid-cassandra:1.3.3 us.gcr.io/project_ID/apigee-hybrid-cassandra:1.3.3 docker tag google/apigee-cassandra-backup-utility:1.3.3 us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3 docker tag google/apigee-udca:1.3.3 us.gcr.io/project_ID/apigee-udca:1.3.3 docker tag google/apigee-stackdriver-logging-agent:1.6.8 us.gcr.io/project_ID/apigee-stackdriver-logging-agent:1.6.8 docker tag google/apigee-prom-prometheus:v2.9.2 us.gcr.io/project_ID/apigee-prom-prometheus:v2.9.2 docker tag google/apigee-stackdriver-prometheus-sidecar:0.7.5 us.gcr.io/project_ID/apigee-stackdriver-prometheus-sidecar:0.7.5 docker tag google/apigee-connect-agent:1.3.3 us.gcr.io/project_ID/apigee-connect-agent:1.3.3 docker tag google/apigee-watcher:1.3.3 us.gcr.io/project_ID/apigee-watcher:1.3.3 docker tag google/apigee-operators:1.3.3 us.gcr.io/project_ID/apigee-operators:1.3.3 docker tag google/apigee-kube-rbac-proxy:v0.4.1 us.gcr.io/project_ID/apigee-kube-rbac-proxy:v0.4.1
必須ではありませんが、各リポジトリのリポジトリパスにプロジェクト ID などの識別値を含めることをおすすめします。
-
イメージを非公開リポジトリに push します。
次の例では、イメージを米国に拠点を置く GCR リポジトリに push します。
docker push us.gcr.io/project_ID/apigee-installer:1.3.3 docker push us.gcr.io/project_ID/apigee-authn-authz:1.3.3 docker push us.gcr.io/project_ID/apigee-mart-server:1.3.3 docker push us.gcr.io/project_ID/apigee-synchronizer:1.3.3 docker push us.gcr.io/project_ID/apigee-runtime:1.3.3 docker push us.gcr.io/project_ID/apigee-hybrid-cassandra-client:1.3.3 docker push us.gcr.io/project_ID/apigee-hybrid-cassandra:1.3.3 docker push us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3 docker push us.gcr.io/project_ID/apigee-cassandra-backup-utility:1.3.3 docker push us.gcr.io/project_ID/apigee-udca:1.3.3 docker push us.gcr.io/project_ID/apigee-stackdriver-logging-agent:1.6.8 docker push us.gcr.io/project_ID/apigee-prom-prometheus:v2.9.2 docker push us.gcr.io/project_ID/apigee-stackdriver-prometheus-sidecar:0.7.5 docker push us.gcr.io/project_ID/apigee-connect-agent1.3.3 docker push us.gcr.io/project_ID/apigee-watcher1.3.3 docker push us.gcr.io/project_ID/apigee-operators1.3.3 docker push us.gcr.io/project_ID/apigee-kube-rbac-proxy:v0.4.1
必須ではありませんが、各リポジトリのリポジトリパスにプロジェクト ID などの識別値を含めることをおすすめします。
-
-
構成のオーバーライドの指定の説明に沿って、イメージ URL が非公開リポジトリを指すようにオーバーライド ファイルを更新します。
次のコンポーネントの画像 URL を変更する必要があります。
コンポーネント名(オーバーライド ファイル内) Image URL ao
your_private_repo/apigee-operators
authz
your_private_repo/apigee-authn-authz
cassandra
your_private_repo/apigee-hybrid-cassandra
auth: your_private_repo/apigee-hybrid-cassandra-client
backup: your_private_repo/apigee-cassandra-backup-utility
restore: your_private_repo/apigee-cassandra-backup-utilityconnectAgent
your_private_repo/apigee-connect-agent
installer
your_private_repo/apigee-installer
kubeRBACProxy
your_private_repo/apigee-kube-rbac-proxy
logger
your_private_repo/apigee-stackdriver-logging-agent
mart
your_private_repo/apigee-mart-server
metrics
your_private_repo/apigee-prom-prometheus
sdSidecar: your_private_repo/apigee-stackdriver-prometheus-sidecarruntime
your_private_repo/apigee-runtime
synchronizer
your_private_repo/apigee-synchronizer
udca
your_private_repo/apigee-udca
fluentd: your_private_repo/apigee-stackdriver-logging-agentwatcher
your_private_repo/apigee-watcher
- クラスタに構成を適用するで説明されているように、GCR の新しいイメージを使用して変更を適用します。
統合ポータルに境界へのアクセス権を付与する
VPC-SC では、統合ポータルへの VPC-SC アクセスレベルの付与がサポートされていますが、このプロセスではこのセクションで説明する追加の手順が必要になります。
統合ポータルへのアクセスレベルを付与しないと、VPC-SC 対応の Apigee 組織では統合ポータルを使用できません。
ポータルへのアクセスレベルの付与:
- 統合ポータルを境界内に配置しない。
- 統合ポータルに境界外からのアクセスを許可する。
- VPC-SC で保護されている Apigee データ(アプリケーション データなど)の VPC-SC 境界外のポータル ユーザーへの公開を許可する。
詳細については、保護されたリソースへの境界外部からのアクセスの許可をご覧ください。
前提条件
境界に統合ポータルへのアクセス権を付与する前に、プロジェクトで Access Context Manager API
がまだ有効になっていない場合は有効にする必要があります。これを行うには、Google Cloud コンソールまたは gcloud services enable コマンドを使用します。
API が有効になっているかどうかを確認するには、ステップ 2: Apigee API を有効にするで説明されているように、gcloud services list コマンドの出力を調べます。
また、ポータルが使用されているプロジェクトのサービス アカウントのメールアドレスが必要です。これを取得するには、GCP プロジェクト ID とプロジェクト番号が必要です。これらの値を取得する手順は次のとおりです。
- 次の例のように、gcloud projects list コマンドを使用して GCP プロジェクトの詳細を取得します。
gcloud projects list
このコマンドは、GCP 組織内の各プロジェクトのプロジェクト ID(
PROJECT_ID
列内)とプロジェクト番号(PROJECT_NUMBER
列内)を返します。 -
Apigee サービス アカウントのメールアドレスを特定します。これは、ステップ 3: 組織を作成するで組織をプロビジョニングしたときに Apigee インストーラが作成したアカウントと同じです。
このメールアドレスを取得するには、
iam service-accounts list
コマンドを使用します。コマンドで使用する構文は次のとおりです。gcloud iam service-accounts list --project GCP_PROJECT_ID
例:
gcloud iam service-accounts list --project my-project DISPLAY NAME EMAIL DISABLED Apigee default service account service-
8675309
@gcp-sa-apigee.iam.gserviceaccount.com False Compute Engine default service account8675309
-compute@developer.gserviceaccount.com False目的のサービス アカウントは、メールアドレスが次の形式に一致するアカウントです。
service-GCP_PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com
例:
service-
8675309
@gcp-sa-apigee.iam.gserviceaccount.com -
access-context-manager policies list
コマンドを使用して、ポリシー(または境界)ID を取得します。次の例のように、組織 ID をこのコマンドに渡します。gcloud access-context-manager policies list --organization=organizations/GCP_ORG_ID
gcloud
は、次の例のように、指定された組織に関連付けられたポリシーのリストを返します。gcloud access-context-manager policies list --organization=organizations/
2244340
NAME ORGANIZATION TITLE ETAG04081981
2244340
Default policy
421924c5a97c0Icu8VPC-SC のポリシー ID(境界 ID)は、プロジェクトと他のサービス間の境界として機能する VPC-SC サービス境界の ID です。これは、
NAME
列の値です。
境界に統合ポータルへのアクセス権を付与する手順
境界に統合ポータルへのアクセス権を付与するには:
- 前提条件の説明に沿って、サービス アカウントのメールアドレスと VPC-SC のポリシー ID を収集します。
-
管理マシンに、境界を介したポータルへのアクセス権を付与するサービス アカウントのアドレスを指定する条件ファイルを作成します。
ファイル名は任意ですが、拡張子は
*.yaml
にする必要があります。たとえば、my-portal-access-rules.yaml
です。 -
条件ファイルで、次の例に示すように Apigee サービス アカウントを指定する
members
セクションを追加します。- members: - serviceAccount:
service-
8675309
@gcp-sa-apigee.iam.gserviceaccount.commembers
セクションを追加するだけで十分です。アクセス レベル セクションを追加する必要はありません。条件ファイルの作成の詳細については、ユーザーまたはサービス アカウントによるアクセスを制限するをご覧ください。 access-context-manager levels create
コマンドを使用してアクセスレベルを作成します。次に例を示します。gcloud access-context-manager levels create ACCESS_LEVEL_ID \ --title ACCESS_LEVEL_TITLE \ --basic-level-spec PATH/TO/CONDITIONS_FILE.yaml \ --policy=POLICY_ID
各要素の意味は次のとおりです。
- ACCESS_LEVEL_ID は、付与される新しいアクセスレベルの識別子(例:
my-portal-access-level
)です。 - ACCESS_LEVEL_TITLE はアクセスレベルのタイトルです。タイトルは任意のものを指定できますが、自分自身や他の管理者がそれが何に適用されるかを理解できるように、意味のある値にすることをおすすめします(例: My Portal Access Level など)。
- CONDITIONS_FILE は、前のステップで作成した YAML ファイルのパスです。
- POLICY_ID は、ポリシーまたは境界の ID です。
次に例を示します。
gcloud access-context-manager levels create
my-portal-access-level
\ --title My Portal Access Level \ --basic-level-spec ~/my-portal-access-rules.yaml
\ --policy=04081981
- ACCESS_LEVEL_ID は、付与される新しいアクセスレベルの識別子(例:
access-context-manager perimeters update
コマンドを使用して、新しいアクセスレベルで境界を更新します。gcloud access-context-manager perimeters update POLICY_ID \ --add-access-levels=ACCESS_LEVEL_ID \ --policy=POLICY_ID
例:
gcloud access-context-manager perimeters update
04081981
\ --add-access-levels=my-portal-access-level
\ --policy=04081981
トラブルシューティング
以下をご確認ください。
- GCP プロジェクトで Access Context Manager API が有効になっていない場合に、ポリシーを一覧表示または設定しようとすると、API を有効にするよう求めるプロンプトが
gcloud
によって表示されます。 - 組織の詳細を取得するときは、Apigee 組織 ID ではなく GCP 組織 ID を使用するようにしてください。
- このセクションで説明するコマンドには、昇格した権限が必要です。たとえば、プロジェクトのサービス アカウントの詳細を取得するには、そのプロジェクトのオーナーである必要があります。
-
サービス アカウントが存在することを確認するには、次の例に示すように
iam service-accounts describe
コマンドを実行します。gcloud iam service-accounts describe
service-
8675309
@gcp-sa-apigee.iam.gserviceaccount.comgcloud
は、サービス アカウントに関する情報(表示名や所属するプロジェクト ID など)を返します。サービス アカウントが存在しない場合、gcloud
はNOT_FOUND
エラーを返します。
制限事項
Apigee と VPC Service Controls とのインテグレーションには次の制限があります。
- 統合ポータルを構成するには、追加の手順が必要です。
- サービス境界内に Drupal ポータルをデプロイする必要があります。