이 문서에서는 Dataproc 클러스터 내 키 배포 센터(KDC) 및 Apache Ranger를 사용하여 Google Cloud의 Kerberos를 적용한 데이터 레이크의 네트워킹, 인증, 승인에 대한 개념, 권장사항, 참조 아키텍처를 설명합니다. Dataproc는 Google Cloud의 관리형 Hadoop 및 Spark 서비스입니다. 이 문서는 기존 Hadoop 및 Spark 클러스터를 Dataproc로 구성되는 최신 데이터 레이크로 마이그레이션하는 Apache Hadoop 관리자, 클라우드 설계자, 빅데이터 팀을 대상으로 합니다.
Google Cloud의 Kerberos를 적용한 데이터 레이크는 조직의 하이브리드 및 멀티 클라우드 배포를 지원하여 ID 및 액세스 제어 관리에 대한 기존 IT 투자를 확대하고 사용할 수 있게 해줍니다.
조직은 Google Cloud에서 필요한 만큼의 임시 작업 범위 클러스터를 팀에게 제공할 수 있습니다. 이 방법은 종속 항목과 소프트웨어 구성 상호작용이 늘어나는 단일 클러스터를 유지보수하는 데 따르는 복잡성을 상당 부분 없애 줍니다. 또한 조직은 여러 사용자와 서비스가 액세스할 수 있도록 장기 실행 클러스터를 만들 수 있습니다. 이 문서에서는 Kerberos 및 Apache Ranger와 같은 업계 표준 도구를 사용하여 Dataproc의 두 클러스터 사례에 대한 세부적인 사용자 보안(인증, 승인, 감사)을 보장하는 방법을 보여줍니다.
고객 사용 사례
기업들은 기존 클러스터를 관리할 때 발생하는 문제를 해결하기 위해 온프레미스 Hadoop 기반 데이터 레이크를 퍼블릭 클라우드 플랫폼으로 마이그레이션하고 있습니다.
이러한 회사 중에 온프레미스 Hadoop 시스템을 Google Cloud로 마이그레이션하기로 결정한 엔터프라이즈 소프트웨어 및 하드웨어 분야의 대형 기술 선두업체가 있습니다. 이 회사의 온프레미스 Hadoop 환경은 200여 명의 데이터 분석 팀원이 있는 사이버 보안팀을 포함하여 수백 개의 팀과 사업부의 분석 요구를 처리했습니다. 한 팀원이 레거시 데이터 레이크로 대규모 쿼리를 실행하면 리소스의 정적인 특성 때문에 문제가 발생했습니다. 이 조직은 온프레미스 환경을 사용하는 팀의 분석 요구를 충족시키는 데 어려움을 겪었고, 그 결과 Google Cloud로 전환했습니다. 이 조직은 Google Cloud로 전환하여 온프레미스 데이터 레이크에서 매월 보고되는 문제 수를 25%까지 줄일 수 있었습니다.
이 조직에서 Google Cloud로 마이그레이션은 팀의 워크로드에 따라 대규모 모놀리식 클러스터를 재구성 및 최적화하고, 클러스터 관리에서 벗어나 비즈니스 가치 실현에 집중해야 한다는 기초적인 결정에 따라 계획되었습니다. 몇 가지 대규모 클러스터는 더 작고 비용 효율적인 Dataproc 클러스터로 분할되었고 워크로드 및 팀은 다음 유형의 모델로 마이그레이션됩니다.
- 임시 작업 범위 클러스터: 가동 시간이 단 몇 분에 지나지 않는 임시 모델에서는 작업이 완료될 때 종료되는 전용 클러스터를 작업 또는 워크플로에 지정할 수 있습니다. 이 패턴은 Dataproc의 기본 제공되는 Hadoop용 Cloud Storage 커넥터를 사용하여 Hadoop 분산 파일 시스템(HDFS)을 Cloud Storage로 대체하여 컴퓨팅 노드에서 스토리지를 분리합니다.
- 준장기 실행 클러스터: 임시 작업 범위 클러스터가 사용 사례를 지원할 수 없으면 장기 실행 Dataproc 클러스터가 사용될 수 있습니다. 클러스터의 스테이트풀(Stateful) 데이터가 Cloud Storage로 오프로드되면 클러스터를 쉽게 종료할 수 있으며, 이러한 클러스터를 준장기 실행 클러스터로 간주합니다. 또한 스마트 클러스터 자동 확장에서는 이러한 클러스터를 처음에 작게 시작하고 특정 애플리케이션에 맞게 컴퓨팅 리소스를 최적화할 수 있게 해줍니다. 이러한 자동 확장은 YARN 큐 관리를 대체합니다.
하이브리드 보안 과제
이전 고객 시나리오에서 이 고객은 데이터 관리 시스템을 상당 부분 클라우드로 마이그레이션했습니다. 하지만 데이터 레이크에 데이터를 입력하는 기존 일부 운영 체제와 같이 조직 IT의 다른 부분에서는 온프레미스를 유지해야 할 필요가 있었습니다.
보안 아키텍처는 중앙의 온프레미스 LDAP 기반 ID 공급업체(IdP)가 데이터 레이크를 사용하는 회사 ID의 신뢰할 수 있는 소스를 유지하도록 확인해야 했습니다. 온프레미스 Hadoop 보안은 인증을 위한 Kerberos 및 LDAP(종종 조직의 Microsoft Active Directory(AD)에 포함된 경우가 많음) 및 Apache Ranger와 같은 다른 오픈소스 소프트웨어(OSS) 제품을 기반으로 합니다. 이 보안 방식은 데이터 레이크 클러스터에서 사용자 활동 및 팀 활동에 대한 승인 및 감사를 미세하게 조정하도록 허용합니다. Google Cloud에서 Identity and Access Management(IAM)는 Dataproc 및 Cloud Storage와 같은 특정 Google Cloud 리소스에 대한 액세스를 관리하는 데 사용됩니다.
이 문서에서는 Hadoop 클러스터 내부 및 외부 모두의 워크로드 및 데이터 보안을 돕기 위해 IAM과 함께 최고의 온프레미스 및 OSS Hadoop 보안(Kerberos, 기업 LDAP, Apache Ranger 중심)을 사용하는 보안 접근 방식에 대해 설명합니다.
아키텍처
다음 다이어그램은 대략적인 아키텍처를 보여줍니다.
앞의 다이어그램에서 클라이언트는 여러 팀 또는 단일 클러스터로 작업을 실행합니다. 클러스터는 기업 ID 공급업체와 함께 중앙 Hive Metastore 및 Kerberos 인증을 사용합니다.
구성요소
이 아키텍처는 이 문서의 뒷 부분에서 설명하는 여러 가지 작업 제출 방법을 인증하고 승인하기 위해 업계 표준의 오픈소스 도구와 IAM의 조합을 제안합니다. 다음은 Hadoop 클러스터에서 팀 및 사용자의 워크로드에 대해 미세 조정된 보안을 제공하기 위해 함께 작동하는 기본 구성요소들입니다.
Kerberos: Kerberos는 클라이언트/서버 애플리케이션에 강력한 인증을 제공하기 위해 보안 키 암호화를 사용하는 네트워크 인증 프로토콜입니다. Kerberos 서버는 키 배포 센터(KDC)로 알려져 있습니다.
Kerberos는 사용자, 서비스, 머신 인증을 위해 AD와 같은 온프레미스 시스템에서 널리 사용됩니다. 클라이언트 항목은 사용자 주 구성원으로 정의됩니다. Dataproc에서 Kerberos를 사용 설정하면 온프레미스 KDC를 만들기 위해 무료 Kerberos MIT 배포판이 사용됩니다. Dataproc의 클러스터 내 KDC는 Apache Hadoop YARN, HDFS, Apache Spark와 같이 클러스터 내에 있는 리소스에 대한 사용자 주 구성원의 액세스 요청을 처리합니다. 서버 리소스는 서비스 주 구성원으로 지정됩니다. Kerberos 교차 렐름 트러스트를 사용하면 한 렐름의 사용자 주 구성원을 다른 렐름에 연결할 수 있습니다.
Apache Ranger: Apache Ranger는 사용자가 Hadoop 서비스에서 특정 작업을 수행할 수 있도록 세부적인 승인을 제공합니다. 또한 사용자 액세스를 감사하고 관리 작업을 구현합니다. Ranger는 온프레미스 기업 LDAP 서버 또는 AD와 동기화되어 사용자 및 서비스 ID를 가져올 수 있습니다.
공유 Hive Metastore: Hive Metastore는 Apache Hive 및 기타 Hadoop 도구의 메타데이터를 저장하는 서비스입니다. 이러한 많은 도구가 이를 기반으로 빌드되기 때문에 Hive Metastore는 많은 데이터 레이크의 핵심 구성요소가 되었습니다. 제안된 아키텍처에서 Kerberos를 적용한 중앙 집중식 Hive Metastore는 여러 클러스터가 안전한 방식으로 메타데이터를 공유할 수 있게 해줍니다.
Kerberos, Ranger, 공유 Hive Metastore는 Hadoop 클러스터 내에서 세부적인 사용자 보안을 허용하기 위해 함께 작동하지만 IAM은 Google Cloud 리소스에 대한 액세스를 제어합니다. 예를 들어 Dataproc는 Dataproc 서비스 계정을 사용하여 Cloud Storage 버킷에서 읽기 및 쓰기를 수행합니다.
클러스터 측정기준
Dataproc 클러스터의 성격을 규정하는 측정기준은 다음과 같습니다.
- 테넌시: 여러 사용자(사람) 또는 서비스의 요청을 처리하는 클러스터는 멀티 테넌트이고, 단일 사용자 또는 서비스의 요청을 처리하는 클러스터는 단일 테넌트입니다.
- Kerberos: Dataproc에서 Kerberos를 사용 설정할 경우에는 클러스터에 Kerberos가 적용되고, Dataproc에서 Kerberos를 사용 설정하지 않을 경우에는 Kerberos가 적용되지 않습니다.
- 수명주기: 특정 작업 또는 워크플로 기간에만 생성되고, 작업을 실행하는 데 필요한 리소스만 포함하고, 작업이 완료될 때 종료되는 클러스터는 임시 클러스터입니다. 그렇지 않으면 클러스터가 준장기 실행 클러스터로 간주됩니다.
이러한 측정기준의 다양한 조합에 따라 특정 클러스터의 가장 적합한 사용 사례가 결정됩니다. 이 문서에서는 다음 대표 예시에 대해 설명합니다.
아키텍처에 표시된 샘플 멀티 팀 클러스터는 Kerberos를 적용한 멀티 테넌트 준장기 실행 클러스터입니다. 이러한 클러스터는 대화형 쿼리 워크로드에 가장 적합합니다. 예를 들어 장기 데이터 분석 및 비즈니스 인텔리전스(BI) 탐색 분석을 처리하는 경우입니다. 이 아키텍처에서 이러한 클러스터는 여러 팀이 공유하는 Google Cloud 프로젝트에 있으며, 이러한 팀의 요청을 처리합니다. 그래서 멀티 팀 클러스터라고 합니다.
이 문서에서 팀 또는 애플리케이션 팀이라는 용어는 조직에서 동일한 소프트웨어 구성요소로 작업을 수행하거나 하나의 기능 팀으로 작동하는 사람들의 그룹을 의미합니다. 예를 들어 팀은 마이크로서비스의 백엔드 개발자, 비즈니스 애플리케이션의 BI 분석가, 더 나아가 빅 데이터 인프라 팀과 같은 교차 기능 팀을 의미할 수 있습니다.
아키텍처에 표시된 샘플 단일 팀 클러스터는 멀티 테넌트(동일한 팀원용) 또는 단일 테넌트일 수 있는 클러스터입니다.
- 임시 클러스터로서 단일 팀 클러스터는 데이터 엔지니어가 Spark 일괄 처리 작업을 실행하거나 데이터 과학자가 모델 학습 작업을 실행하는 경우 등의 작업에 사용될 수 있습니다.
준장기 실행 클러스터로서 단일 팀 클러스터는 단일 팀 또는 사람으로 범위가 지정된 데이터 분석 및 BI 워크로드를 처리할 수 있습니다.
단일 팀 클러스터는 단일 팀에 속하는 Google Cloud 프로젝트에 있으며, 사용량 감사, 청구, 리소스 격리를 간소화합니다. 예를 들어 단일 팀의 구성원만 클러스터의 데이터를 유지하는 데 사용되는 Cloud Storage 버킷에 액세스할 수 있습니다. 이 방식에서는 단일 팀 클러스터에 Kerberos가 적용되지 않도록 애플리케이션 팀에 전용 프로젝트가 포함됩니다.
자세한 요구사항을 분석하고 상황에 가장 잘 맞는 측정기준 조합을 선택하는 것이 좋습니다.
작업 제출
사용자는 다음과 같은 다양한 도구를 통해 두 가지 유형의 클러스터 모두에 작업을 제출할 수 있습니다.
- REST 호출 또는 클라이언트 라이브러리를 사용하는 Dataproc API
- 로컬 터미널 창이나 로컬 브라우저에 열려 있는 Cloud Shell의 Google Cloud 콘솔에서 사용 가능한 Google Cloud CLI gcloud 명령줄 도구
- 작업 실행 위치에 관한 정보와 함께 작업 그래프를 정의하는 재사용 가능한 워크플로 구성인 Dataproc 워크플로 템플릿. 워크플로에 관리형 클러스터 옵션이 사용될 경우 임시 클러스터가 사용됩니다.
- Dataproc Operator를 사용하는 Cloud Composer. Dataproc 워크플로 템플릿을 조정하기 위해 Composer 방향성 비순환 그래프(DAG)를 사용할 수도 있습니다.
- 클러스터에서 마스터 노드로 SSH 세션을 열고 작업을 직접 제출하거나 Apache Beeline과 같은 도구를 사용하여 제출합니다. 이 도구는 일반적으로 관리자 및 고급 사용자를 위해 예약되어 있습니다. 고급 사용자 예시로는 한 서비스의 구성 매개변수 문제를 해결하고 마스터 노드에서 직접 테스트 작업을 실행하여 이를 확인하려는 개발자가 있습니다.
네트워킹
다음 다이어그램에는 아키텍처의 네트워킹 개념이 요약되어 있습니다.
이전 다이어그램에서 네트워킹 아키텍처에는 메시형 하이브리드 패턴이 사용됩니다. 여기에서 일부 리소스는 Google Cloud에 존재하고 다른 일부는 온프레미스에 존재합니다. 메시형 하이브리드 패턴에는 공유 VPC가 사용됩니다. 여기에는 각 Dataproc 클러스터 유형 및 팀에 대해 하나의 공통적인 호스트 프로젝트와 개별적인 프로젝트가 포함됩니다. 이 아키텍처에 대해서는 다음 Google Cloud 및 온프레미스 섹션에서 자세히 설명합니다.
Google Cloud
Google Cloud에서 이 아키텍처는 공유 VPC를 사용하여 구성됩니다. 공유 VPC를 사용하면 여러 프로젝트를 리소스를 하나의 공통적인 VPC 네트워크에 연결할 수 있습니다. 하나의 공통적인 VPC 네트워크를 사용하면 해당 네트워크의 내부 IP 주소를 사용하여 리소스가 서로 안전하게 효율적으로 통신할 수 있습니다. 공유 VPC를 설정하려면 다음 프로젝트를 만듭니다.
- 호스트 프로젝트: 호스트 프로젝트에는 모든 서비스 프로젝트에서 사용하는 하나 이상의 공유 VPC 네트워크가 포함되어 있습니다.
서비스 프로젝트: 서비스 프로젝트에는 관련된 Google Cloud 리소스가 포함됩니다. 공유 VPC 관리자는 서비스 프로젝트를 호스트 프로젝트에 연결하여 공유 VPC 네트워크의 서브넷 및 리소스를 사용할 수 있게 해줍니다. 이러한 연결은 단일 팀 클러스터가 중앙 집중식 Hive Metastore에 액세스하는 데 필수적입니다.
네트워킹 다이어그램에 표시된 것처럼 Hive Metastore 클러스터, 멀티 팀 클러스터, 각 개별 팀의 클러스터에 대해 별도의 서비스 프로젝트를 만드는 것이 좋습니다. 그러면 조직에서 각 팀의 구성원이 관련 프로젝트 내에 단일 팀 클러스터를 만들 수 있습니다.
하이브리드 네트워크 내의 구성요소가 통신할 수 있도록 하려면 다음 트래픽을 허용하도록 방화벽 규칙을 구성해야 합니다.
- HDFS DataNode와 통신하는 HDFS NameNode, YARN NodeManager와 통신하는 YARN ResourceManager를 포함한 Hadoop 서비스를 위한 클러스터 트래픽. 이러한 규칙에는 클러스터 서비스 계정을 사용한 필터링을 사용하는 것이 좋습니다.
- Hive Metastore(포트
tcp:9083,8020), 온프레미스 KDC(포트tcp:88), LDAP(포트636),와 통신하기 위한 특정 포트의 외부 클러스터 트래픽 및 Google Kubernetes Engine(GKE)의 Kafka와 같은 특정 시나리오에 사용하는 기타 중앙 집중화된 외부 서비스
이 아키텍처의 모든 Dataproc 클러스터는 내부 IP 주소만으로 생성됩니다. 클러스터 노드가 Google API 및 서비스에 액세스하도록 허용하려면 클러스터 서브넷에 대해 비공개 Google 액세스를 사용 설정해야 합니다. 관리자와 고급 사용자가 비공개 IP 주소 VM 인스턴스에 액세스하도록 허용하려면 IAP TCP 전달을 사용하여 암호화된 터널을 통해 SSH, RDP, 기타 트래픽을 전달합니다.
클러스터 애플리케이션 및 선택적인 구성요소의 클러스터 웹 인터페이스(예를 들어 Spark, Hadoop, Jupyter, Zeppelin)는 Dataproc 구성요소 게이트웨이를 통해 안전하게 액세스됩니다. Dataproc 구성요소 게이트웨이는 Apache Knox를 기반으로 하는 HTTP Inverting 프록시입니다.
온프레미스
이 문서에서는 온프레미스에 있는 리소스가 사용자 및 팀 서비스 주 구성원이 정의되는 기업 LDAP 디렉터리 서비스 및 기업 Kerberos 키 배포 센터(KDC)라고 가정합니다. 온프레미스 ID 공급업체를 사용할 필요가 없으면 Cloud ID와 Dataproc 클러스터 또는 가상 머신의 KDC를 사용하여 설정을 간소화할 수 있습니다.
온프레미스 LDAP 및 KDC와 통신하려면 Cloud Interconnect 또는 Cloud VPN을 사용합니다. 이 설정은 RFC 1918 IP 주소의 서브네트워크가 겹치지 않는 경우 환경 간 통신에 비공개 IP 주소가 사용되도록 보장하는 데 도움이 됩니다. 여러 연결 옵션에 대한 자세한 내용은 네트워크 연결 제품 선택을 참조하세요.
하이브리드 시나리오에서 인증 요청은 최소한의 지연 시간으로 처리되어야 합니다. 이 목적을 달성하기 위해서는 다음 기법을 사용할 수 있습니다.
- 클러스터 내 KDC에서 서비스 ID에 대해 모든 인증 요청을 처리하고, 사용자 ID에 대해 클러스터 외부의 ID 공급업체만 사용합니다. 대부분의 인증 트래픽은 서비스 ID로부터의 요청으로 예상됩니다.
- AD를 ID 공급업체로 사용할 경우 사용자 기본 이름(UPN)은 사용자(사람) 및 AD 서비스 계정을 나타냅니다. 온프레미스 AD에서 데이터 레이크 클러스터에 가까운 Google Cloud 리전으로 UPN을 복제하는 것이 좋습니다. 이 AD 복제본은 UPN에 대한 인증 요청을 처리하므로, 요청이 온프레미스 AD로 전송되지 않습니다. 각각의 온프레미스 KDC는 첫 번째 기법을 사용하여 서비스 기본 이름(SPN)을 처리합니다.
다음 다이어그램은 두 기법을 모두 사용하는 아키텍처를 보여줍니다.
앞의 다이어그램에서 온프레미스 AD는 UPN을 Google Cloud 리전의 AD 복제본으로 동기화합니다. AD 복제본은 UPN을 인증하고 클러스터 내 KDC는 SPN을 인증합니다.
Google Cloud에서 AD 배포에 대한 자세한 내용은 내결함성 Microsoft Active Directory 환경 배포를 참조하세요. 도메인 컨트롤러에 대한 인스턴스 수 크기 조정 방법은 MIT Kerberos 및 Active Directory 통합을 참조하세요.
인증
다음 다이어그램은 여러 Hadoop 클러스터에서 사용자를 인증하는 데 사용되는 구성요소를 보여줍니다. 인증을 사용하면 사용자가 Apache Hive 또는 Apache Spark와 같은 서비스를 사용할 수 있습니다.
다음 다이어그램에서 Kerberos 렐름의 클러스터는 Hive Metastore와 같은 다른 클러스터의 서비스를 사용하도록 교차 렐름 신뢰를 설정할 수 있습니다. Kerberos가 적용되지 않은 클러스터는 Kerberos 클라이언트 및 계정 keytab을 사용하여 다른 클러스터의 서비스를 사용할 수 있습니다.
공유 및 보안 Hive Metastore
중앙 집중식 Hive Metastore는 Apache Spark, Apache Hive/Beeline, Presto와 같은 다른 오픈소스 쿼리 엔진을 실행하는 여러 클러스터가 메타데이터를 공유할 수 있게 해줍니다.
Kerberos가 적용된 Dataproc 클러스터에 Hive Metastore 서버를 배포하고 Cloud SQL의 MySQL 인스턴스와 같이 원격 RDBMS에 Hive Metastore 데이터베이스를 배포합니다. 공유 서비스로서 Hive Metastore 클러스터는 인증된 요청만 처리합니다. Hive Metastore 구성에 대한 자세한 내용은 Dataproc에서 Apache Hive 사용을 참조하세요.
Hive Metastore 대신 완전 관리형의 고가용성(리전 내), 자동 복구, 서버리스 Apache Hive Metastore인 Dataproc Metastore를 사용할 수 있습니다. 또한 서비스에 Kerberos 구성에 설명된 것처럼 Dataproc Metastore 서비스에 대해 Kerberos를 사용 설정할 수 있습니다.
Kerberos
이 아키텍처에서 멀티 팀 클러스터는 분석 목적으로 사용되며 Dataproc 보안 구성 가이드에 따라 Kerberos가 적용됩니다. Dataproc 보안 모드는 클러스터 내 KDC를 만들고 Hadoop 보안 모드 사양에서 요구하는 대로 클러스터의 서비스 주 구성원 및 keytab을 관리합니다.
keytab은 하나 이상의 Kerberos 주 구성원과 해당 주 구성원의 키에 대한 암호화된 복사본 쌍을 하나 이상 포함하는 파일입니다. keytab은 kinit 명령어를 사용한 대화형 로그인이 불가능할 때 프로그래매틱 Kerberos 인증을 가능하게 해줍니다.
keytab에 액세스할 수 있으면 여기에 포함된 주 구성원을 가장할 수 있습니다. 따라서 keytab은 안전하게 전송하고 저장해야 하는 매우 중요한 파일입니다. Keytabs 콘텐츠를 관련 클러스터로 전송하기 전에 Secret Manager를 사용하여 저장하는 것이 좋습니다. keytab의 콘텐츠를 저장하는 방법은 서비스에 대해 Kerberos 구성을 참조하세요. keytab이 클러스터 마스터 노드에 다운로드된 후 파일에 제한된 파일 액세스 권한이 있어야 합니다.
클러스터 내 KDC는 해당 클러스터 내의 모든 서비스에 대해 인증 요청을 처리합니다. 대부분의 인증 요청은 이 요청 유형으로 예상됩니다. 지연 시간을 최소화하기 위해서는 KDC가 클러스터를 나가지 않고 이러한 요청을 해결하는 것이 중요합니다.
나머지 요청은 사용자(사람) 및 AD 서비스 계정에서 비롯됩니다. 이전 온프레미스 섹션에 설명된 것처럼 Google Cloud의 AD 복제본 또는 온프레미스의 중앙 ID 공급자가 이러한 요청을 처리합니다.
이 아키텍처에서 단일 팀 클러스터는 Kerberos가 적용되지 않으므로, KDC가 제공되지 않습니다. 이러한 클러스터가 공유된 Hive Metastore에 액세스하도록 허용하려면 Kerberos 클라이언트만 설치하면 됩니다. 액세스를 자동화하기 위해서는 팀의 keytab을 사용할 수 있습니다. 자세한 내용은 이 문서 뒷 부분에 있는 ID 매핑 섹션을 참조하세요.
멀티 팀 클러스터의 Kerberos 교차 렐름 신뢰
교차 렐름 신뢰는 워크로드가 하이브리드 또는 멀티 클라우드일 경우에 관련성이 높습니다. 교차 렐름 신뢰를 사용하면 중앙 기업 ID를 Google Cloud 데이터 레이크에서 사용 가능한 공유 서비스로 통합할 수 있습니다.
Kerberos에서 렐름은 공통 KDC에 속하는 시스템 그룹을 정의합니다. 교차 렐름 인증은 한 렐름의 사용자 주 구성원이 다른 렐름에서 인증하고 해당 서비스를 사용할 수 있게 해줍니다. 이를 구성하려면 렐름 간에 신뢰를 설정해야 합니다.
아키텍처에는 세 개의 렐름이 있습니다.
- EXAMPLE.COM: 사용자, 팀, 서비스에 대해 모든 Kerberos 사용자 주 구성원이 정의되는(UPN) 기업 렐름입니다.
- MULTI.EXAMPLE.COM: 멀티 팀 클러스터를 포함하는 렐름입니다. 클러스터는 Apache Spark 및 Apache Hive와 같은 Hadoop 서비스에 대한 서비스 주 구성원(SPN)으로 미리 구성됩니다.
- METASTORE.EXAMPLE.COM: Hive Metastore의 렐름입니다.
단일 팀 클러스터는 Kerberos가 적용되지 않으므로 렐름에 속하지 않습니다.
모든 클러스터에서 회사 사용자 주 구성원을 사용하려면 다음과 같은 단방향 교차 렐름 신뢰를 설정합니다.
회사 렐름을 신뢰하도록 멀티 팀 렐름 및 메타스토어 렐름을 구성합니다. 이 구성을 사용하면 회사 렐름에 정의된 주 구성원이 멀티 팀 클러스터와 메타스토어에 액세스할 수 있습니다.
신뢰가 전환될 수 있지만 기업 렐름에 대해 직접 신뢰를 갖도록 Metastore 렐름을 구성하는 것이 좋습니다. 이 구성을 사용하면 멀티 팀 렐름의 가용성에 의존할 필요가 없습니다.
멀티 팀 클러스터가 메타스토어에 액세스할 수 있도록 메타스토어 렐름이 멀티 팀 렐름을 신뢰하도록 구성합니다. 이 구성은 HiveServer2 주 구성원이 Metastore에 액세스하도록 허용하기 위해 필요합니다.
자세한 내용은 교차 렐름 신뢰를 사용하는 Kerberos 적용 dataproc 클러스터 시작과 GitHub 저장소의 해당 Terraform 구성 파일을 참조하세요.
멀티 팀 클러스터에 대해 기본 제공 또는 클라우드 기반 IAM 접근 방법을 선호하고 하이브리드 ID 관리가 필요하지 않으면 Dataproc 서비스 계정 기반의 보안 멀티테넌시를 사용하는 것이 좋습니다. 이러한 클러스터에서는 여러 IAM ID가 Cloud Storage 및 기타 Google 리소스에 서로 다른 서비스 계정으로 액세스할 수 있습니다.
단일 팀 클러스터의 ID 매핑
앞의 섹션에서는 아키텍처의 Kerberos 적용 부분의 구성을 살펴봤습니다. 하지만 단일 팀 클러스터는 Kerberos가 적용되지 않으므로, 이 에코시스템에 참여할 수 있도록 특별한 기법이 필요합니다. 이 기법은 Google Cloud 프로젝트 구분 속성 및 IAM 서비스 계정을 사용하여 애플리케이션 팀의 Hadoop 워크로드를 격리시키고 보호합니다.
앞의 네트워킹 섹션에 설명된 것처럼 각 팀에는 단일 팀 클러스터를 만들 수 있는 해당 Google Cloud 프로젝트가 있습니다. 단일 팀 클러스터 내에서 하나 이상의 팀 구성원은 클러스터의 테넌트입니다. 또한 이러한 프로젝트별 구분은 Cloud Storage 버킷(해당 클러스터에서 사용됨) 액세스를 해당 팀으로 제한합니다.
관리자는 서비스 프로젝트를 만들고 해당 프로젝트에서 팀 서비스 계정을 프로비저닝합니다. 클러스터를 만들 때 이 서비스 계정은 클러스터 서비스 계정으로 지정됩니다.
또한 관리자는 기업 렐름의 팀에 대해 Kerberos 주 구성원을 만들고 해당 keytab을 만듭니다. keytab은 Secret Manager에 안전하게 저장되고 관리자는 keytab을 클러스터 마스터 노드에 복사합니다. Kerberos 주 구성원은 단일 팀 클러스터의 Hive Metastore 액세스를 허용합니다.
자동화된 프로비저닝을 지원하고 관련된 ID 쌍을 쉽게 인식할 수 있도록 하려면 ID에 공통적인 명명 규칙을 사용해야 합니다. 예를 들면 다음과 같습니다.
- 팀 서비스 계정:
revenue-reporting-app@proj-A.iam.gserviceaccount.com - Kerberos 팀 주 구성원:
revenue_reporting/app@EXAMPLE.COM
이러한 ID 매핑 기법은 둘 다 동일한 팀에 속하는 서비스 계정에 Kerberos를 매핑하는 고유한 접근 방법을 제공합니다.
이러한 ID는 여러 방법으로 사용됩니다.
- Kerberos ID는 Hive Metastore와 같은 공유 Hadoop 리소스에 대해 액세스 권한을 클러스터에 부여합니다.
- 서비스 계정은 Cloud Storage와 같은 공유 Google Cloud 리소스에 대해 액세스 권한을 클러스터에 부여합니다.
이 기법을 사용하면 팀의 각 구성원에 대해 비슷한 매핑을 만들 필요가 없습니다. 하지만 이 기법에는 전체 팀에 대해 하나의 서비스 계정 또는 하나의 Kerberos 주 구성원이 사용되기 때문에 Hadoop 클러스터의 작업을 팀의 개별 구성원으로 추적할 수 없습니다.
Cloud Storage 버킷, 관리되는 서비스, VM과 같이 Hadoop 클러스터 범위 외부에 있는 팀 프로젝트에서 클라우드 리소스에 대한 액세스를 관리하기 위해 관리자는 팀 구성원을 Google 그룹에 추가합니다. 관리자는 Google 그룹을 사용하여 전체 팀이 클라우드 리소스에 액세스할 수 있도록 IAM 권한을 관리할 수 있습니다.
팀의 개별 구성원이 아니라 그룹에 IAM 권한을 부여하면 구성원이 애플리케이션 팀에 합류하거나 탈퇴할 때 사용자 액세스 권한을 간편하게 관리할 수 있습니다. 팀의 Google 그룹에 직접 IAM 권한을 부여하면 Cloud 감사 로그에서 작업 추적을 단순화하는 데 도움이 되도록 서비스 계정 가장을 사용 중지할 수 있습니다. 팀 구성원을 정의할 때는 해당 작업으로부터 파생되는 관리 노력에 따라 액세스 관리, 리소스 사용, 감사에 필요한 세분성 수준을 균형적으로 조절하는 것이 좋습니다.
클러스터가 팀이 아니라 엄격히 한 명의 사용자(사람)만 지원하는 경우(단일 테넌트 클러스터)에는 Dataproc 개인 클러스터 인증을 사용하는 것이 좋습니다. 클러스터에 개인 클러스터 인증을 사용 설정하면 단기 대화형 워크로드가 하나의 최종 사용자 ID로 안전하게 실행될 수 있습니다. 이러한 클러스터는 IAM 최종 사용자 인증 정보를 사용하여 Cloud Storage와 같은 다른 Google Cloud 리소스와 상호작용합니다. 클러스터는 클러스터 서비스 계정으로 인증하는 대신 최종 사용자로 인증됩니다. 이러한 유형의 클러스터에서는 Kerberos가 자동으로 사용 설정되고 개인 클러스터 내에서 안전하게 통신할 수 있게 구성됩니다.
인증 흐름
Dataproc 클러스터에서 작업을 실행하기 위해 사용자는 앞의 작업 제출 섹션에 설명된 것처럼 여러 옵션을 선택할 수 있습니다. 모든 경우에 사용자 계정 또는 서비스 계정은 클러스터에 액세스해야 합니다.
사용자가 멀티 팀 클러스터에서 작업을 실행하는 경우 다음 다이어그램에 나와 있는 것처럼, 두 가지 옵션 중 하나를 택하여 Kerberos 주 구성원을 사용할 수 있습니다.
위의 다이어그램은 다음 옵션을 보여줍니다.
- 사용자가 작업 요청을 제출하기 위해 Dataproc API, Cloud Composer, gcloud 명령줄 도구와 같은 Google Cloud 도구를 사용하는 경우 클러스터는 Dataproc Kerberos 주 구성원을 사용하여 KDC에 인증하고 Hive Metastore에 액세스합니다.
- 사용자가 SSH 세션에서 작업을 실행하는 경우 해당 세션에서 자체 사용자 Kerberos 주 구성원을 사용하여 작업을 직접 제출할 수 있습니다.
사용자가 단일 팀 클러스터에서 작업을 실행하는 경우에는 다음 다이어그램에 나와 있는 것처럼 팀 Kerberos 주 구성원이라는 하나의 Kerberos 주 구성원만 사용할 수 있습니다.
이전 다이어그램에서 작업은 공유 Hive Metastore에 액세스가 필요할 때 팀 Kerberos 주 구성원을 사용합니다. 그렇지 않으면 단일 팀 클러스터에 Kerberos가 적용되지 않기 때문에 사용자가 자신의 고유 사용자 계정을 사용하여 작업을 시작할 수 있습니다.
단일 팀 클러스터의 경우 클러스터를 만들 때 초기화 작업 과정에서 팀 주 구성원에 대해 kinit를 실행하는 것이 좋습니다. 클러스터를 만든 후에는 lifetime(-l) 명령어 옵션을 사용하여 정의된 티켓 전체 기간에 따라 cron 일정을 사용합니다.
kinit를 실행하기 위해 초기화 작업은 먼저 keytab을 클러스터 마스터 노드에 다운로드합니다.
보안을 위해서는 keytab에 대해 액세스를 제한하는 것이 필수적입니다.
kinit를 실행하는 계정에 대해서만 POSIX 읽기 권한을 부여합니다. 가능하면 keytab을 삭제하고 kinit -R을 사용하여 토큰을 갱신하여 최대 티켓 전체 기간에 도달할 때까지 cron 작업을 사용하여 해당 전체 기간을 연장합니다. 이 때 cron 작업은 keytab을 다시 다운로드하고 kinit를 다시 실행하며 갱신 주기를 다시 시작할 수 있습니다.
멀티 팀 및 단일 팀 클러스터 유형 모두 서비스 계정을 사용하여 Cloud Storage와 같은 다른 Google Cloud 리소스에 액세스합니다. 단일 팀 클러스터는 팀 서비스 계정을 커스텀 클러스터의 서비스 계정으로 사용합니다.
승인
이 섹션에서는 다음 다이어그램에 표시된 대로 각 클러스터에 대해 대략적인 승인과 세부적인 승인 메커니즘을 설명합니다.
위 다이어그램의 아키텍처는 대략적인 승인에 IAM을 사용하고 세부적인 승인에 Apache Ranger를 사용합니다. 이러한 승인 방법에 대해서는 대략적인 승인 및 세부적인 승인 섹션에서 설명합니다.
대략적인 승인
IAM을 사용하면 프로젝트 리소스에 대한 사용자 및 그룹 액세스를 제어할 수 있습니다. IAM은 권한과 이러한 권한을 부여하는 역할을 정의합니다.
관리자, 편집자, 뷰어, 작업자라는 4개의 미리 정의된 Dataproc 역할이 있습니다. 이러한 역할은 사용자 및 서비스 계정이 클러스터, 작업, 운영, 워크플로 템플릿에서 특정 작업을 수행하도록 허용하는 Dataproc 권한을 부여합니다. 이러한 역할은 작업을 수행하는 데 필요한 Google Cloud 리소스에 대한 액세스 권한을 부여합니다. 이러한 리소스 중 하나는 HDFS 대신 클러스터 스토리지 레이어로 사용하는 것이 권장되는 Cloud Storage입니다.
IAM Dataproc 권한의 세부사항은 각 클러스터에서 실행되는 Apache Hive 또는 Apache Spark와 같은 서비스 수준으로 확장되지 않습니다. 예를 들어 Cloud Storage 버킷에서 데이터에 액세스하도록 또는 작업을 실행하도록 특정 계정을 승인할 수 있습니다. 하지만 계정이 해당 작업으로 액세스하도록 허용되는 Hive 열을 지정할 수 없습니다. 다음 섹션에서는 클러스터에서 세부적인 승인을 구현하는 방법을 설명합니다.
세부적인 승인
세부적인 액세스를 승인하려면 Dataproc에서 Apache Ranger 사용 시 권장사항에 설명된 아키텍처에서 Dataproc Ranger 선택적 구성요소를 사용합니다. 이 아키텍처에서 Apache Ranger는 단일 및 멀티 팀의 각 클러스터에 설치됩니다. Apache Ranger는 서비스, 테이블, 열 수준에서 Hadoop 애플리케이션에 대해 세부적인 액세스 제어(승인 및 감사)를 제공합니다.
Apache Ranger는 기업 LDAP 저장소에서 제공되고 Kerberos 주 구성원으로 정의되는 ID를 사용합니다. 멀티 팀 클러스터에서는 Ranger UserSync 데몬이 회사 LDAP 서버의 Kerberos를 적용한 ID를 정기적으로 업데이트합니다. 단일 팀 클러스터에서는 팀 ID만 필요합니다.
임시 클러스터는 작업이 완료되면 종료되지만 관련 Ranger 정책과 관리자 로그를 분실하면 안 되므로 까다롭습니다. 이 문제를 해결하기 위해서는 정책을 중앙 Cloud SQL 데이터베이스로 외부화하고, 감사 로그를 Cloud Storage 폴더로 외부화해야 합니다. 자세한 내용은 Dataproc에서 Apache Ranger 사용 시 권장사항을 참조하세요.
승인 흐름
사용자가 하나 이상의 클러스터 서비스에 액세스하여 데이터를 처리하려는 경우 요청이 다음과 같은 흐름으로 진행됩니다.
- 사용자가 인증 흐름 섹션에 설명된 옵션 중 하나를 통해 인증합니다.
- 대상 서비스에서 사용자 요청을 수신하고 해당하는 Apache Ranger 플러그인을 호출합니다.
- 이 플러그인은 Ranger Policy Server에서 정기적으로 정책을 검색합니다. 이러한 정책은 사용자 ID가 특정 서비스에서 요청된 작업을 수행하도록 허용되었는지 확인합니다. 사용자 ID가 작업을 수행하도록 허용된 경우, 이 플러그인은 서비스가 요청을 처리하도록 허용하고 사용자에게 결과가 표시됩니다.
- Hadoop 서비스와 이루어지는 모든 사용자 상호작용은 허용 또는 거부 여부에 관계없이 Ranger Audit Server가 Ranger 로그에 기록합니다. 각 클러스터는 Cloud Storage에 자체 로그 폴더를 가지고 있습니다. Dataproc는 또한 Cloud Logging에서 확인, 검색, 필터링 및 보관할 수 있는 작업 및 클러스터 로그를 기록합니다.
이 문서에서 참조 아키텍처에는 멀티 팀 클러스터와 단일 팀 클러스터의 두 가지 유형의 Dataproc 클러스터가 사용되었습니다. 쉽게 프로비저닝 및 보호할 수 있는 여러 Dataproc 클러스터를 사용하여 조직은 기존의 중앙 집중화된 클러스터 대신 작업, 제품, 도메인 집중 접근 방법을 사용할 수 있습니다. 이러한 접근 방식은 전체 Data Mesh 아키텍처에 잘 맞으며, 팀이 데이터 레이크와 워크로드를 완전히 소유하고 보호하며 데이터를 서비스로 제공할 수 있게 해줍니다.
다음 단계
- 교차 렐름 신뢰를 사용하는 Kerberos 적용 Dataproc 클러스터 시작과 GitHub 저장소에서 해당하는 Terraform 구성 파일 읽어보기
- Dataproc에서 Apache Ranger 사용 권장사항 읽어보기
- Tableau 및 Looker와 같은 비즈니스 인텔리전스(BI) 도구를 사용하여 Dataproc에서 데이터 분석가의 보안 데이터 액세스를 설정하는 방법 읽어보기
- 온프레미스 Apache Hadoop 시스템을 Google Cloud로 이전하는 방법 읽어보기
- 외부 ID 공급업체와 Google Cloud를 페더레이션하는 경우의 권장사항 읽어보기.
- 클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기