Apigee 및 Apigee Hybrid와 함께 VPC 서비스 제어 사용

이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.

Apigee는 Google Cloud 프로젝트의 리소스를 격리할 수 있는 VPC 서비스 제어와 통합됩니다. 이렇게 하면 데이터 유출/무단 반출을 방지하는 데 도움이 됩니다.

이 섹션에서는 Apigee로 VPC 서비스 제어를 사용하는 방법을 설명합니다.

개요

VPC 서비스 제어는 프로젝트와 다른 서비스 간의 경계 역할을 하는 서비스 경계를 정의합니다. 서비스 경계는 데이터 무단 반출 위험을 완화하기 위해 프로젝트에서 Google Cloud 서비스를 보호하는 조직 수준의 방법입니다.

VPC 서비스 제어는 리소스에 대한 비공개 액세스 권한이 있는 경계 내 클라이언트가 경계 외부에 있는 권한이 없는 리소스에 액세스하지 못하도록 차단할 수도 있습니다.

서비스 경계의 이점에 대한 자세한 내용은 VPC 서비스 제어 개요를 참조하세요.

VPC 서비스 제어를 사용할 때는 다음 사항에 유의하세요.

Google Cloud 프로젝트 및 연결된 런타임은 모두 해당 프로젝트의 VPC 서비스 제어 경계 내에 들어갑니다.
VPC 네트워크 액세스 가능 서비스 기능을 사용하여 경계 내부의 서비스 간 상호작용을 제한할 수 있습니다.

Apigee와 Apigee Hybrid는 모두 VPC 서비스 제어와 통합됩니다. VPC 서비스 제어와 통합되는 전체 제품 목록은 지원되는 제품을 참조하세요.

인터넷 연결에 대한 영향

VPC 서비스 제어가 사용 설정되었으면 인터넷 액세스가 사용 중지됩니다. Apigee 런타임은 공개 인터넷 대상과 더 이상 통신하지 않습니다. 커스텀 경로를 설정하여 VPC로 트래픽을 라우팅해야 합니다. 커스텀 경로 가져오기 및 내보내기를 참조하세요.

Apigee로 VPC 서비스 제어 설정

Apigee로 VPC 서비스 제어를 설정하는 일반적인 프로세스는 다음과 같습니다.

VPC 서비스 제어를 사용 설정합니다.
새 서비스 경계를 만듭니다.
서비스 경계를 구성합니다.

이러한 단계는 아래에 자세히 설명되어 있습니다.

Apigee로 VPC 서비스 제어를 설정하려면 다음 안내를 따르세요.

다음 명령어를 실행하여 네트워크에서 Apigee로 피어링된 연결에 VPC 서비스 제어를 사용 설정합니다.
```
gcloud services vpc-peerings enable-vpc-service-controls \
  --network=SHARED_VPC_NETWORK --project=PROJECT_ID
```
각 항목의 의미는 다음과 같습니다.
- SHARED_VPC_NETWORK은 공유 VPC 네트워크 이름입니다.
- PROJECT_ID는 공유 VPC 네트워크를 호스팅하는 프로젝트의 이름이며 Apigee 조직을 만드는 데 사용되는 프로젝트가 아닙니다.
이 명령어는 프로젝트에 VPC 서비스 제어를 사용 설정합니다. 이 명령어를 여러 번 실행하여 두 개 이상의 프로젝트에서 VPC 서비스 제어를 사용 설정할 수 있습니다.
VPC 서비스 제어 빠른 시작에 설명된 대로 새 경계를 만듭니다. 경계를 만들 때 해당 경계 내에 추가할 프로젝트와 보호할 서비스를 선택합니다.

Apigee와 Apigee Hybrid의 경우 Apigee API를 포함한 경계를 만들 때 모든 서비스를 보호하는 것이 좋습니다.

자세한 내용은 서비스 경계 만들기를 참조하세요.
서비스 경계 세부정보 및 구성에 설명된 대로 서비스 경계를 구성합니다.

경계 내에 통합 포털을 추가하려면 경계에 통합 포털 추가를 참조하세요.

Apigee Hybrid로 VPC 서비스 제어 설정

Apigee Hybrid는 VPC 서비스 제어를 지원하지만 추가로 수행해야 할 단계가 있습니다. Apigee Hybrid 및 VPC 서비스 제어를 통합하는 일반적인 프로세스는 다음과 같습니다.

비공개 연결을 설정합니다.
경계 내에서 추가 서비스를 보호합니다.
비공개 저장소를 설정합니다. (비공개 저장소는 경계 내에 있는 저장소이므로 경계 내에 있는 경우 로컬 저장소일 필요는 없습니다.)
Apigee 이미지를 비공개 저장소로 푸시합니다.
하이브리드 설치 및 구성 프로세스 중에 비공개 저장소를 사용하도록 재정의를 업데이트합니다.

이러한 각 단계는 다음 절차에서 자세히 설명합니다.

Apigee Hybrid로 VPC 서비스 제어를 설정하려면 다음 안내를 따르세요.

Google API 및 서비스로 비공개 연결 설정에 설명된 대로 하이브리드 네트워크 호스트의 비공개 IP 주소를 설정합니다. 여기에는 Google API가 이러한 비공개 IP에 액세스할 수 있도록 경로, 방화벽 규칙, DNS 항목을 구성하는 것이 포함됩니다.
Apigee로 VPC 서비스 제어 설정의 단계를 따릅니다.

이 프로세스 중에 경계 내에서 Apigee에 지정된 서비스 외에도 다음 서비스를 보호해야 합니다.
- Anthos Service Mesh
- Cloud Monitoring (Stackdriver)
- Google Kubernetes Engine(GKE에서 실행 중인 경우)
- Google Container Registry(로컬 저장소로 사용하는 경우)
이러한 서비스를 경계에 추가하려면 서비스 경계 세부정보 및 구성의 안내를 따르세요.

Apigee 이미지를 비공개 저장소에 복사합니다.

여기에 설명된 대로 Docker Hub에서 서명된 Apigee 이미지를 다운로드합니다. 최신 버전 번호를 지정해야 합니다.

예를 들면 다음과 같습니다.

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

이미지에 태그를 지정합니다.

다음 예시에서는 US 기반 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 또는 기타 식별 값을 포함하는 것이 좋습니다.

이미지를 비공개 저장소로 푸시합니다.

다음은 US 기반의 GCR 저장소로 이미지를 푸시하는 예시입니다.

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을 변경해야 합니다.

구성요소 이름(재정의 파일 내)	이미지 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-utility`
`connectAgent`	`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-sidecar`
`runtime`	`your_private_repo/apigee-runtime`
`synchronizer`	`your_private_repo/apigee-synchronizer`
`udca`	`your_private_repo/apigee-udca fluentd: your_private_repo/apigee-stackdriver-logging-agent`
`watcher`	`your_private_repo/apigee-watcher`

클러스터에 구성 적용에 설명된 대로 GCR의 새 이미지를 사용하여 변경사항을 적용합니다.

경계에 통합 포털 액세스 권한 부여

VPC-SC는 통합 포털에 VPC-SC 액세스 수준을 부여할 수 있지만 이 프로세스에는 이 섹션에 설명된 추가 단계가 필요합니다.

통합 포털에 액세스 수준을 부여하지 않으면 VPC-SC가 사용 설정된 Apigee 조직에서 통합 포털을 사용할 수 없습니다.

포털에 액세스 수준 부여:

통합 포털을 경계 내에 배치하지 않습니다.
경계 외부에서 통합 포털에 액세스할 수 있습니다.
VPC-SC로 보호되는 Apigee 데이터(예: 애플리케이션 데이터)가 VPC-SC 경계 외부의 포털 사용자에게 노출되도록 허용합니다.

자세한 내용은 서비스 경계 외부에서 보호된 리소스에 액세스 허용을 참조하세요.

기본 요건

통합 포털에 경계 액세스 권한을 부여하기 전에 프로젝트에 Access Context Manager API를 사용 설정해야 합니다(아직 사용 설정되지 않은 경우). 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 account     8675309-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                 ETAG
04081981      2244340           Default policy        421924c5a97c0Icu8
```
용어 참고사항 이 컨텍스트에서 정책이라는 용어는 경계와 동의어입니다.

VPC-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.com
```
members 섹션을 추가하는 것으로 충분합니다. 액세스 수준 섹션을 추가할 필요가 없습니다. 조건 파일을 만드는 방법에 대한 자세한 내용은 사용자 또는 서비스 계정별 액세스 제한을 참조하세요.
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은 액세스 수준의 제목입니다. 제목은 원하는 대로 지정할 수 있지만 본인 및 다른 관리자가 적용될 내용을 알 수 있도록 의미 있는 값을 제공하는 것이 좋습니다. 예를 들어 '내 포털 액세스 수준'입니다.
- 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-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가 사용 설정되지 않은 경우 gcloud는 정책을 나열하거나 설정하려고 할 때 API를 사용 설정하라는 메시지를 표시합니다.
조직에 대한 세부정보를 가져올 때 GCP 조직 ID가 아닌 GCP 조직 ID를 사용해야 합니다.
이 섹션에 설명된 일부 명령어에는 승격된 권한이 필요합니다. 예를 들어 프로젝트의 서비스 계정에 대한 세부정보를 가져오려면 해당 프로젝트의 소유자여야 합니다.
서비스 계정이 있는지 확인하려면 다음 예시와 같이 iam service-accounts describe 명령어를 실행합니다.
```
gcloud iam service-accounts describe service-8675309@gcp-sa-apigee.iam.gserviceaccount.com
```
gcloud는 서비스 계정에 대한 정보(표시 이름 및 해당 계정이 속한 프로젝트 ID 등)로 응답합니다. 서비스 계정이 없는 경우 gcloud는 NOT_FOUND 오류로 응답합니다.

제한사항

VPC 서비스 제어와 Apigee 통합에는 다음과 같은 제한사항이 있습니다.

통합 포털을 구성하려면 추가 단계가 필요합니다.
서비스 경계 내에 Drupal 포털을 배포해야 합니다.