Dataflow 보안 및 권한

Dataflow 실행기를 사용하여 Dataflow 파이프라인을 로컬로 또는 관리형 Google Cloud 리소스에서 실행할 수 있습니다. 로컬 또는 클라우드에서 파이프라인을 실행 중인 경우 파이프라인과 작업자는 권한 시스템을 사용하여 파이프라인 파일 및 리소스에 대한 보안 액세스를 유지합니다. Dataflow 권한은 파이프라인 리소스에 액세스하는 데 사용되는 역할에 따라 지정됩니다. 이 문서에서는 다음 개념을 설명합니다.

• Dataflow VM 업그레이드
• 로컬 및 Google Cloud 파이프라인을 실행하는 데 필요한 역할 및 권한
• 파이프라인 리소스에 액세스하는 데 필요한 역할 및 권한
• Dataflow 서비스 및 데이터 보안에 사용되는 데이터 유형

시작하기 전에

Google Cloud 개요에서 Google Cloud 프로젝트 식별자에 대해 알아보세요. 식별자에는 프로젝트 이름, 프로젝트 ID, 프로젝트 번호가 포함됩니다.

Dataflow VM 업그레이드 및 패치 적용

Dataflow는 Container-Optimized OS를 사용합니다. Container-Optimized OS의 보안 프로세스도 Dataflow에 적용됩니다.

일괄 파이프라인은 시간이 제한적이며 유지보수가 필요하지 않습니다. 새 일괄 파이프라인이 시작되면 최신 Dataflow 이미지가 사용됩니다.

스트리밍 파이프라인의 경우 보안 패치가 즉시 필요하면 Google Cloud가 보안 게시판을 사용하여 알림을 표시합니다. 스트리밍 파이프라인의 경우 --update 옵션을 사용하여 최신 Dataflow 이미지로 작업을 다시 시작하는 것이 좋습니다.

Dataflow 컨테이너 이미지는 Google Cloud Console에서 확인할 수 있습니다.

로컬 파이프라인의 보안 및 권한

로컬로 실행하면 Apache Beam 파이프라인은 Google Cloud CLI 실행 파일로 구성된 Google Cloud 계정으로 실행됩니다. 로컬에서 실행되는 Apache Beam SDK 작업과 Google Cloud 계정은 동일한 파일 및 리소스에 액세스할 수 있습니다.

기본값으로 선택한 Google Cloud 계정을 나열하려면 gcloud config list 명령어를 실행합니다.

참고: 로컬 파이프라인은 로컬 파일과 같은 로컬 대상이나 Cloud Storage 또는 BigQuery와 같은 클라우드 대상으로 데이터를 출력할 수 있습니다. 로컬에서 실행되는 파이프라인이 Cloud Storage와 같은 클라우드 기반 리소스에 파일을 쓰는 경우 Google Cloud 계정 사용자 인증 정보와 구성된 Google Cloud 프로젝트를 Google Cloud CLI 기본값으로 사용합니다. Google Cloud 계정 사용자 인증 정보로 인증하는 방법에 대한 자세한 내용은 Java 빠른 시작, Python 빠른 시작, Go 빠른 시작 등 사용 중인 언어에 해당하는 빠른 시작을 참고하세요.

Google Cloud 파이프라인의 보안 및 권한

파이프라인을 실행하면 Dataflow는 두 가지 서비스 계정을 사용하여 보안 및 권한을 관리합니다.

• Dataflow 서비스 계정. Dataflow 서비스는 Dataflow 서비스 계정을 작업 생성 요청의 일부로 사용합니다(예: 프로젝트 할당량 확인 및 개발자 대신 작업자 인스턴스 생성). 또한 Dataflow는 작업 실행 중 작업을 관리하는 데 Dataflow 서비스 계정을 사용합니다. 이 계정을 Dataflow 서비스 에이전트라고도 합니다.

• 작업자 서비스 계정. 작업자 인스턴스는 개발자가 작업을 제출한 후 작업자 서비스 계정을 사용하여 입력 리소스와 출력 리소스에 액세스합니다. 기본적으로 작업자는 작업자 서비스 계정으로 프로젝트에 연결된 Compute Engine 기본 서비스 계정을 사용합니다. 권장사항은 기본 작업자 서비스 계정을 사용하는 대신 사용자 관리형 서비스 계정을 지정하는 것입니다.

서비스 계정을 가장하려면 파이프라인을 시작하는 계정에 iam.serviceAccounts.actAs 역할이 있어야 합니다.

다른 프로젝트 권한에 따라 사용자 계정에도 roles/dataflow.developer 역할이 필요할 수 있습니다. 프로젝트 소유자나 편집자인 경우 roles/dataflow.developer 역할에 포함된 권한이 이미 있습니다.

권장사항

• 가능한 경우 작업자 서비스 계정에 기본 작업자 서비스 계정을 사용하는 대신 사용자 관리형 서비스 계정을 지정합니다.
• 리소스에 대한 권한을 부여할 때 태스크에 필요한 최소 권한이 포함된 역할을 부여합니다. 필요한 권한만 포함된 커스텀 역할을 만들 수 있습니다.
• 리소스에 액세스하는 역할을 부여할 때는 가능한 한 가장 낮은 리소스 수준을 사용합니다. 예를 들어 프로젝트 또는 폴더에 대한 roles/bigquery.dataEditor 역할을 부여하는 대신 BigQuery 테이블에 대한 역할을 부여합니다.
• Dataflow에 스테이징 버킷으로 사용할 프로젝트가 소유한 버킷을 만듭니다. 기본 버킷 권한을 사용하면 Dataflow가 버킷을 사용하여 파이프라인의 실행 파일을 스테이징할 수 있습니다.

Dataflow 서비스 계정

Dataflow Job 리소스를 사용한 적이 있는 모든 프로젝트에는 다음 이메일을 사용하는 Dataflow 서비스 에이전트라고도 하는 Dataflow 서비스 계정이 있습니다.

service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com

이 서비스 계정은 Google에서 만들고 관리하며 Dataflow Job 리소스를 처음 사용할 때 프로젝트에 자동으로 할당됩니다.

Dataflow 파이프라인을 실행하는 과정에서 Dataflow는 개발자를 대신하여 리소스를 조작합니다. 예를 들면 추가 VM을 만듭니다. Dataflow로 파이프라인을 실행하면 이 서비스 계정이 사용됩니다.

이 계정에는 프로젝트에 대한 Dataflow 서비스 에이전트 역할이 부여됩니다. Compute Engine 작업자 시작을 포함하여 프로젝트에서 Dataflow 작업을 실행하는 데 필요한 권한이 있습니다. 이 계정은 Dataflow에서만 사용되며 프로젝트에 따라 다릅니다.

Google Cloud 콘솔 또는 Google Cloud CLI에서 Dataflow 서비스 계정에 할당된 역할을 검토할 수 있습니다.

gcloud iam roles describe roles/dataflow.serviceAgent

Google Cloud 서비스에는 프로젝트 및 리소스에 대한 읽기 및 쓰기 액세스 권한이 있어야 하므로 프로젝트에 자동으로 설정된 기본 권한을 변경하지 않는 것이 좋습니다. Dataflow 서비스 계정이 프로젝트 권한을 잃으면 Dataflow는 VM을 시작하거나 다른 관리 작업을 수행할 수 없습니다.

Identity and Access Management(IAM) 정책에서 서비스 계정에 대한 권한을 삭제해도 Dataflow 서비스에서 계정을 소유하고 있으므로 계정이 현재 상태로 유지됩니다.

작업자 서비스 계정

Compute Engine 인스턴스는 클라우드에서 Apache Beam SDK 작업을 실행합니다. 이러한 작업자는 프로젝트의 작업자 서비스 계정을 사용해서 파일 및 파이프라인과 연관된 기타 리소스에 액세스합니다. 작업자 서비스 계정은 모든 작업자 VM의 ID로 사용되며 VM에서 시작된 모든 요청은 작업자 서비스 계정을 사용합니다. 이 서비스 계정은 또한 Cloud Storage 버킷 및 Pub/Sub 주제와 같은 리소스와 상호작용하는 데에도 사용됩니다.

• 작업자 서비스 계정에서 작업을 실행할 수 있으려면 roles/dataflow.worker 역할이 있어야 합니다.
• 작업자 서비스 계정에서 작업을 만들거나 조사할 수 있으려면 roles/dataflow.admin 역할이 있어야 합니다.

또한 Apache Beam 파이프라인이 Google Cloud 리소스에 액세스할 때 Dataflow 프로젝트의 작업자 서비스 계정에 필요한 역할을 부여해야 합니다. 작업자 서비스 계정은 Dataflow 작업을 실행하는 중 리소스에 액세스할 수 있어야 합니다. 예를 들어 작업이 BigQuery에 기록되는 경우 서비스 계정에도 최소한 BigQuery 테이블에 대한 roles/bigquery.dataEditor 역할이 있어야 합니다. 리소스 예시는 다음과 같습니다.

• Cloud Storage 버킷
• BigQuery 데이터 세트
• Pub/Sub 주제 및 구독
• Firestore 데이터 세트

기본 작업자 서비스 계정

기본적으로 작업자는 프로젝트의 Compute Engine 기본 서비스 계정을 작업자 서비스 계정으로 사용합니다. 이 서비스 계정은 다음과 같은 이메일을 사용합니다.

PROJECT_NUMBER-compute@developer.gserviceaccount.com

이 서비스 계정은 Google Cloud 콘솔의 API 라이브러리에서 프로젝트의 Compute Engine API를 사용 설정할 때 자동으로 생성됩니다.

Compute Engine 기본 서비스 계정을 Dataflow 작업자 서비스 계정으로 사용할 수 있지만 필요한 역할과 권한만 있는 전용 Dataflow 작업자 서비스 계정을 만드는 것이 좋습니다.

조직 정책 구성에 따라 프로젝트에 대한 편집자 역할이 기본 서비스 계정에 자동으로 부여될 수 있습니다. iam.automaticIamGrantsForDefaultServiceAccounts 조직 정책 제약조건을 적용하여 자동 역할 부여를 중지하는 것이 좋습니다. 2024년 5월 3일 이후에 조직을 만든 경우 기본적으로 이 제약조건이 적용됩니다.

자동 역할 부여를 중지한 경우 기본 서비스 계정에 부여할 역할을 결정한 후 직접 이러한 역할을 부여해야 합니다.

기본 서비스 계정에 이미 편집자 역할이 있으면 편집자 역할을 권한이 더 낮은 역할로 바꾸는 것이 좋습니다. 서비스 계정 역할을 안전하게 수정하려면 정책 시뮬레이터를 사용하여 변경사항의 영향을 확인한 후 적절한 역할을 부여하고 취소합니다.

사용자 관리형 작업자 서비스 계정 지정

세분화된 액세스 제어로 리소스를 만들고 사용하려면 사용자 관리형 서비스 계정을 만들 수 있습니다. 이 계정을 작업자 서비스 계정으로 사용합니다.

1. 사용자 관리 서비스 계정이 없으면 서비스 계정을 만듭니다.

2. 서비스 계정에 필요한 IAM 역할을 설정합니다.

   • 작업자 서비스 계정에서 작업을 실행할 수 있으려면 roles/dataflow.worker 역할이 있어야 합니다.
   • 작업자 서비스 계정에서 작업을 만들거나 조사할 수 있으려면 roles/dataflow.admin 역할이 있어야 합니다.
   • 또는 필요한 권한이 있는 커스텀 IAM 역할을 만듭니다. 필요한 권한 목록은 역할을 참조하세요.
   • BigQuery, Pub/Sub 또는 Cloud Storage와 같은 작업 요구 사항에 따라 서비스 계정에 Google Cloud 리소스를 사용할 수 있는 추가 역할이 필요할 수 있습니다. 예를 들어 BigQuery에서 작업을 읽는 경우 서비스 계정에도 최소한 BigQuery 테이블에 대한 roles/bigquery.dataViewer 역할이 있어야 합니다.
   • 사용자 관리 서비스 계정에 Dataflow 작업에 지정된 스테이징 및 임시 위치에 대해 읽기 및 쓰기 액세스 권한이 있는지 확인합니다.
   • 서비스 계정을 가장하려면 사용자 계정에 iam.serviceAccounts.actAs 권한이 있어야 합니다.

3. 사용자 관리형 작업자 서비스 계정이 포함된 프로젝트에서 Dataflow 서비스 계정(service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com), Compute Engine 서비스 에이전트(service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com)에는 다음 역할이 있어야 합니다. PROJECT_NUMBER는 Dataflow 작업이 실행되는 프로젝트의 ID입니다. 두 계정 모두 서비스 에이전트입니다.

   • 서비스 계정 토큰 생성자 역할 (iam.serviceAccountTokenCreator)
   • 서비스 계정 사용자 역할 (iam.serviceAccountUser)

   Dataflow 작업이 실행되는 프로젝트에서 계정에는 기본적으로 이러한 역할이 있습니다. 사용자 관리형 작업자 서비스 계정과 작업이 다른 프로젝트에 있는 경우 사용자 관리형 작업자 서비스 계정에 사용되는 Google 관리형 서비스 계정에도 이러한 역할을 부여합니다. 이러한 역할을 부여하려면 서비스 계정 액세스 관리 페이지의 단일 역할 부여 섹션에 나온 단계를 따르세요.

4. 사용자 관리형 작업자 서비스 계정과 작업이 다른 프로젝트에 있는 경우 사용자 관리형 서비스 계정을 소유하는 프로젝트에 iam.disableCrossProjectServiceAccountUsage 불리언 제약조건이 적용되지 않도록 합니다. 자세한 내용은 프로젝트 간 서비스 계정 연결 사용 설정을 참조하세요.

5. 파이프라인 작업을 실행할 때 서비스 계정을 지정합니다.

   자바

   명령줄에서 파이프라인 작업을 실행할 때 --serviceAccount 옵션을 사용하여 서비스 계정을 지정하세요: --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   Flex 템플릿으로 파이프라인을 실행할 때 --service-account-email 옵션을 사용하여 서비스 계정을 지정하세요: --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   Python

   파이프라인 작업을 실행할 때 --service_account_email 옵션을 사용하여 서비스 계정을 지정하세요: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

   Go

   파이프라인 작업을 실행할 때 --service_account_email 옵션을 사용하여 서비스 계정을 지정하세요: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

사용자 관리형 서비스 계정은 작업과 동일한 프로젝트 또는 다른 프로젝트에 있을 수 있습니다. 서비스 계정과 작업이 다른 프로젝트에 있는 경우 작업을 실행하기 전에 서비스 계정을 구성해야 합니다.

역할 추가

프로젝트에 역할을 추가하려면 다음 단계를 따르세요.

Google Cloud 리소스 액세스

Apache Beam 파이프라인은 동일한 Google Cloud 프로젝트 또는 다른 프로젝트의 Google Cloud 리소스에 액세스할 수 있습니다. 이러한 리소스는 다음과 같습니다.

• Artifact Registry 저장소
• Cloud Storage 버킷
• BigQuery 데이터 세트
• Pub/Sub 주제 및 구독
• Firestore 데이터 세트

Apache Beam 파이프라인에서 이러한 리소스에 액세스할 수 있게 하려면 리소스 각각의 액세스 제어 메커니즘을 사용하여 Dataflow 프로젝트의 작업자 서비스 계정에 대한 액세스 권한을 명시적으로 부여해야 합니다.

주권 제어가 포함된 EU 리전 및 지원과 같이 Dataflow에 Assured Workloads 기능을 사용할 경우 파이프라인에서 액세스하는 모든 Cloud Storage, BigQuery, Pub/Sub, I/O 커넥터, 기타 리소스가 조직의 Assured Workloads 프로젝트 또는 폴더에 있어야 합니다.

사용자 관리형 작업자 서비스 계정을 사용하거나 다른 프로젝트의 리소스에 액세스하는 경우에는 추가 작업이 필요할 수 있습니다. 다음 예시에서는 Compute Engine 기본 서비스 계정이 사용된다고 가정하지만 사용자 관리형 작업자 서비스 계정을 사용할 수도 있습니다.

Artifact Registry 저장소 액세스

Dataflow와 함께 커스텀 컨테이너를 사용하면 Artifact Registry 저장소에 아티팩트를 업로드할 수 있습니다.

Artifact Registry를 Dataflow와 함께 사용하려면 Dataflow 작업을 실행하는 작업자 서비스 계정에 최소한 Artifact Registry 작성자 액세스 권한(role/artifactregistry.writer)을 부여해야 합니다.

모든 저장소 콘텐츠는 Google 소유 및 Google 관리 키 또는 고객 관리 암호화 키를 통해 암호화됩니다. Artifact Registry는 기본적으로 Google 소유 및 Google 관리 키를 사용하며 이 옵션을 구성할 필요가 없습니다.

Cloud Storage 버킷 액세스

Dataflow 프로젝트에 Cloud Storage 버킷에 대한 액세스 권한을 부여하려면 버킷이 해당 Dataflow 프로젝트의 작업자 서비스 계정에 액세스할 수 있게 합니다. 서비스 계정에는 최소한 버킷과 해당 콘텐츠 모두에 대한 읽기/쓰기 권한이 있어야 합니다. Cloud Storage에 대한 IAM 권한을 사용하여 필요한 액세스 권한을 부여할 수 있습니다.

작업자 서비스 계정에 버킷에서 읽고 쓰는 데 필요한 권한을 부여하려면 gcloud storage buckets add-iam-policy-binding 명령어를 사용합니다. 이 명령어는 Dataflow 프로젝트 서비스 계정을 버킷 수준 정책에 추가합니다.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE

다음을 바꿉니다.

• BUCKET_NAME: Cloud Storage 버킷 이름
• PROJECT_NUMBER: Dataflow 프로젝트 번호. 프로젝트 번호를 찾으려면 프로젝트 식별을 참조하거나 gcloud projects describe 명령어를 사용합니다.
• SERVICE_ACCOUNT_ROLE: IAM 역할(예: storage.objectViewer)

Google Cloud 프로젝트의 Cloud Storage 버킷 목록을 검색하려면 gcloud storage buckets list 명령어를 사용합니다.

gcloud storage buckets list --project= PROJECT_ID

PROJECT_ID를 프로젝트의 ID로 바꿉니다.

리소스 공유를 제한하는 조직 정책에 의해 제한되지 않는 한 Dataflow 파이프라인과 다른 프로젝트에 있는 버킷에 액세스할 수 있습니다. 도메인 제한사항에 대한 자세한 내용은 도메인별 ID 제한을 참조하세요.

버킷이 없으면 새 버킷을 만듭니다. 그런 다음 작업자 서비스 계정에 버킷에서 읽고 쓰는 데 필요한 권한을 부여합니다.

Google Cloud 콘솔에서도 버킷 권한을 설정할 수 있습니다. 자세한 내용은 버킷 권한 설정을 참조하세요.

Cloud Storage는 버킷과 객체에 액세스할 수 있는 권한을 사용자에게 부여하는 데 사용되는 두 시스템, IAM과 액세스제어 목록(ACL)을 제공합니다. 대부분의 경우 IAM은 리소스에 대한 액세스를 제어하는 데 권장되는 방법입니다.

• IAM은 Google Cloud에서 권한을 제어하며 버킷 및 프로젝트 수준에서 권한을 부여할 수 있습니다. Cloud Storage와 관련된 IAM 역할 목록과 각 역할에 포함된 권한은 Cloud Storage에 대한 IAM 역할을 참조하세요. 권한을 보다 세부적으로 제어해야 하는 경우에는 커스텀 역할을 만듭니다.

• ACL을 사용하여 액세스를 제어하는 경우 작업자 서비스 계정 권한이 IAM 설정과 일치하는지 확인하세요. IAM 정책과 ACL 정책 간의 불일치로 인해 Cloud Storage 버킷이 세분화된 액세스에서 균일한 버킷 수준 액세스로 마이그레이션되면 Cloud Storage 버킷에서 Dataflow 작업에 액세스하지 못할 수 있습니다. 자세한 내용은 일반적인 오류 안내를 참조하세요.

BigQuery 데이터 세트 액세스

BigQueryIO API를 사용하여 Dataflow를 사용하는 같은 프로젝트 또는 다른 프로젝트에서 BigQuery 데이터 세트에 액세스할 수 있습니다. BigQuery 소스와 싱크가 제대로 작동하려면 다음 두 계정이 Dataflow 작업에서 읽고 쓰는 모든 BigQuery 데이터세트에 액세스할 수 있어야 합니다.

• Dataflow 작업을 실행하기 위해 사용하는 Google Cloud 계정입니다.
• Dataflow 작업을 실행하는 작업자 서비스 계정입니다.

이러한 계정에 명시적으로 액세스 권한을 부여하려면 BigQuery를 구성해야 합니다. BigQuery 페이지 또는 BigQuery API를 사용하여 BigQuery 데이터 세트에 대한 액세스 권한을 부여하는 방법을 자세히 알아보려면 BigQuery 액세스 제어를 참조하세요.

필요한 BigQuery 권한 중 파이프라인이 BigQuery 데이터 세트에 액세스하기 위해 bigquery.datasets.get IAM 권한이 필요합니다. 일반적으로 대부분의 BigQuery IAM 역할에 bigquery.datasets.get 권한이 포함되지만 roles/bigquery.jobUser 역할은 예외입니다.

Pub/Sub 주제 및 구독 액세스

Pub/Sub 주제 또는 구독에 액세스하려면 Pub/Sub의 Identity and Access Management 기능을 사용하여 작업자 서비스 계정에 대한 권한을 설정하세요.

다음 Pub/Sub 역할의 권한이 관련 있습니다.

• roles/pubsub.subscriber은 데이터를 사용하기 위한 필수 역할입니다.
• roles/pubsub.editor는 Pub/Sub 구독을 만들기 위한 필수 역할입니다.
• roles/pubsub.viewer 역할이 있으면 Dataflow가 주제 및 구독 구성을 쿼리하기에 좋습니다. 이 구성의 두 가지 이점은 다음과 같습니다.
  • Dataflow는 예상대로 작동하지 않을 수 있는 구독에서 지원되지 않는 설정을 확인할 수 있습니다.
  • 구독에서 기본 확인 기한인 10초를 사용하지 않으면 성능이 향상됩니다. Dataflow는 파이프라인에서 처리되는 동안 메시지의 확인 기한을 반복적으로 연장합니다. pubsub.viewer 권한이 없으면 Dataflow는 확인 기한을 쿼리할 수 없으므로 기본 기한을 가정해야 합니다. 이 구성을 사용하면 Dataflow가 필요한 것보다 많은 modifyAckDeadline 요청을 실행합니다.
  • 구독 또는 주제를 소유한 프로젝트에서 VPC 서비스 제어가 사용 설정된 경우 IP 주소 기반 인그레스 규칙은 Dataflow가 구성을 쿼리하도록 허용하지 않습니다. 이 경우 작업자 서비스 계정을 기반으로 하는 인그레스 규칙이 필요합니다.

Pub/Sub의 Identity and Access Management 기능의 사용 방법을 보여주는 몇 가지 코드 예시와 자세한 내용은 샘플 사용 사례: 프로젝트 간 통신을 참조하세요.

Firestore 액세스

Firestore 데이터베이스(기본 모드 또는 Datastore 모드)에 액세스하려면 Dataflow 작업자 서비스 계정(예:PROJECT_NUMBER-compute@developer.gserviceaccount.com)을 데이터베이스를 소유한 프로젝트의 편집자로 추가하거나 roles/datastore.viewer와 같이 더 제한적인 Datastore 역할을 사용합니다. 또한 Google Cloud 콘솔에서 API 라이브러리의 두 프로젝트 모두에서 Firestore API를 사용 설정합니다.

신뢰할 수 있는 이미지 정책이 있는 프로젝트의 이미지 액세스

프로젝트에 신뢰할 수 있는 이미지 정책이 설정되어 있고 부팅 이미지가 다른 프로젝트에 있다면 신뢰할 수 있는 이미지 정책이 이미지에 액세스할 수 있도록 구성되어 있는지 확인합니다. 예를 들어 템플릿 Dataflow 작업을 실행하는 경우 정책 파일에 dataflow-service-producer-prod 프로젝트에 대한 액세스 권한이 포함되어 있는지 확인합니다. 이 Google Cloud 프로젝트에는 템플릿 작업의 이미지가 포함되어 있습니다.

데이터 액세스 및 보안

Dataflow 서비스는 두 종류의 데이터와 함께 작동합니다.

• 최종 사용자 데이터. 이 데이터는 Dataflow 파이프라인에서 처리됩니다. 일반적인 파이프라인은 하나 이상의 소스에서 데이터를 읽고, 데이터의 변환을 구현하고, 결과를 하나 이상의 싱크에 씁니다. 모든 소스와 싱크는 Dataflow에서 직접 관리하지 않는 스토리지 서비스입니다.

• 운영 데이터. 이 데이터에는 Dataflow 파이프라인을 관리하는 데 필요한 모든 메타데이터가 포함됩니다. 이 데이터에는 작업 이름 또는 파이프라인 옵션과 같은 사용자 제공 메타데이터와 작업 ID와 같은 시스템 생성 메타데이터가 모두 포함됩니다.

Dataflow 서비스는 여러 보안 메커니즘을 사용하여 데이터를 안전하게 비공개로 유지합니다. 이러한 메커니즘은 다음 상황에 적용됩니다.

• 서비스에 파이프라인 제출
• 파이프라인 평가
• 파이프라인 실행 중 및 실행 후에 원격 분석 및 측정항목에 대한 액세스 요청
• Shuffle 또는 Streaming Engine 엔진과 같은 Dataflow 서비스 사용

데이터 지역

Dataflow의 모든 핵심 데이터 처리는 파이프라인 코드에 지정된 리전에서 수행됩니다. 리전을 지정하지 않으면 기본 리전 us-central1이 사용됩니다. 파이프라인 코드에 이 옵션을 지정하면 파이프라인 작업이 선택적으로 다른 리전의 소스 및 싱크에서 읽기 및 쓰기를 수행할 수 있습니다. 그러나 실제 데이터 처리는 Dataflow VM을 실행하도록 지정된 리전에서만 수행됩니다.

파이프라인 논리는 개별 작업자 VM 인스턴스에서 평가됩니다. 이러한 인스턴스가 위치한 영역과 인스턴스가 통신하는 비공개 네트워크를 지정할 수 있습니다. 플랫폼의 보조 계산은 Cloud Storage 위치 또는 파일 크기와 같은 메타데이터에 따라 다릅니다.

Dataflow는 리전 서비스입니다. 데이터 지역 및 리전에 대한 자세한 내용은 Dataflow 리전을 참고하세요.

파이프라인 데이터 제출

Google Cloud 프로젝트의 IAM 권한은 Dataflow 서비스에 대한 액세스를 제어합니다. 프로젝트에 대해 편집자 또는 소유자 권한이 부여된 모든 주 구성원이 파이프라인을 서비스에 제출할 수 있습니다. 파이프라인을 제출하려면 Google Cloud CLI를 사용하여 인증해야 합니다. 인증 후에는 HTTPS 프로토콜을 사용하여 파이프라인을 제출할 수 있습니다. Google Cloud 계정 사용자 인증 정보로 인증하는 방법에 대한 자세한 내용은 현지 언어로 된 빠른 시작을 참고하세요.

파이프라인 데이터 평가

파이프라인 평가 일환으로 임시 데이터가 생성되어 작업자 VM 인스턴스 또는 Cloud Storage에 로컬로 저장될 수 있습니다. 임시 데이터는 저장 상태에서 암호화되며 파이프라인이 평가된 후에는 유지되지 않습니다. 이러한 데이터는 Dataflow 파이프라인에 지정된 것과 동일한 리전에서 Shuffle 서비스 또는 Streaming Engine 서비스(서비스를 선택한 경우)에 저장할 수도 있습니다.

파이프라인 로그 및 원격 분석의 데이터

Cloud Logging에 저장된 정보는 주로 Dataflow 프로그램의 코드를 통해 생성됩니다. Dataflow 서비스는 Cloud Logging에서 경고 및 오류 데이터를 생성할 수 있지만 이 데이터는 서비스가 로그에 추가하는 유일한 중간 데이터입니다. Cloud Logging은 글로벌 서비스입니다.

원격 분석 데이터와 관련 측정항목은 저장 상태에서 암호화되며 이 데이터에 대한 액세스는 Google Cloud 프로젝트의 읽기 권한으로 제어됩니다.

Dataflow 서비스의 데이터

파이프라인에 Dataflow Shuffle 또는 Dataflow Streaming을 사용하는 경우, 영역 파이프라인 옵션을 지정하지 마세요. 대신 리전을 지정하고 Shuffle 또는 Streaming을 사용할 수 있는 리전 중 하나로 값을 설정합니다. 지정된 리전에서 Dataflow가 영역을 자동 선택합니다. 전송 중인 최종 사용자 데이터는 작업자 VM 및 동일한 영역에 유지됩니다. 이러한 Dataflow 작업은 VM 영역 외부에 있는 소스와 싱크를 계속 읽고 쓸 수 있습니다. 전송 중 데이터를 Dataflow Shuffle 또는 Dataflow Streaming 서비스로 보낼 수도 있지만 데이터는 항상 파이프라인 코드에 지정된 리전에 남아 있습니다.

권장사항

파이프라인의 기본 클라우드 리소스에 있는 보안 메커니즘을 사용하는 것이 좋습니다. 이러한 메커니즘으로는 데이터 소스 및 싱크의 데이터 보안 기능을 갖춘 BigQuery 및 Cloud Storage 등이 포함됩니다. 또한 단일 프로젝트에서 서로 다른 신뢰 수준을 혼용하지 않아야 합니다.