Locking Down the Lakehouse: Securing Apache Iceberg’s REST Catalog at Scaleㅇ며

• 1. Iceberg Catalog과 REST Catalog란?
• Iceberg Catalog
• 기존 Catalog의 문제점
• REST Catalog의 등장
• 2. REST Catalog 보안의 중요성
• 보안 미흡 시 위험
• 1) 컴플라이언스 (Compliance)
• 2) 멀티 테넌시 (Multi-tenancy)
• 3) 다층 보안 (Multi-layered Security)
• 3. REST 보안의 주요 과제
• 3.1 대규모 인증 (Authorization at Scale)
• 3.2 세밀한 액세스 제어 (Fine-grained Access Control)
• 3.3 자격증명 수명 주기 (Credential Lifecycling)
• 3.4 멀티 클라우드 복잡성 (Multi-cloud Complexity)
• 4. 보안 전략 및 패턴
• 4.1 컴퓨트 강제 권한 (Query Engine Client Compute-Enforced Permissions)
• 프로세스 흐름:
• 문제점:
• 4.2 카탈로그 레이어 거버넌스 (Catalog Layer Governance & Security)
• RFC 기반 토큰 위임 (Token Delegation)
• 주요 개선사항:
• 현재 상태:
• 5. StarRocks 4.0 구현
• StarRocks 소개
• JWT Token Session-Based Catalog Enforced Permissions
• 프로세스:
• Security Integration (3.5+, 4.0)
• 6. 모범 사례 (Best Practices)
• 6.1 단일 진실 공급원 (Single Source of Truth)
• 6.2 직접 데이터 액세스 (Direct Data Access)
• 6.3 중앙화된 권한 (Centralized Permissions)
• 6.4 통합된 멀티 클라우드 권한
• Q&A 주요 내용
• Q: Hive와 Iceberg 테이블을 모두 지원하려면 Hive Metastore만 선택해야 하나?
• Q: StarRocks 4.0에서 JWT Token Flow 설정 문서가 있나?
• Q: Token 교환에서 Super User 접근을 어떻게 우회하나?
• Q: 언제 완전히 구현되나?
• Q: Nessie와 Polaris 통합에 대해 더 설명해주세요
• Q: Security Integration이 작동하지 않는 경우?
• 추가 리소스
• 요약
• 핵심 메시지:
• 미래 방향:
• 비교표: 컴퓨트 강제 vs 카탈로그 강제

1. Iceberg Catalog과 REST Catalog란?

Iceberg Catalog

• 역할: Iceberg 테이블의 진입점 (Front door)
• 기능: 현재 메타데이터 포인터 보유
• 핵심 질문에 대한 답변: "테이블 X는 어디에 있고, 메타데이터는 무엇인가?"

아키텍처 구성:

Iceberg Catalog → Metadata Layer → Data Layer

기존 Catalog의 문제점

초기 구현:

• Hive, Glue, Nessie, JDBC 등 다양한 카탈로그
• 2018년경부터 각자의 스펙으로 구현 시작

발생한 문제:

• N개 엔진 × M개 카탈로그 = N×M개 구현 필요
• 각 카탈로그마다 다른 클라이언트 라이브러리 필요
• 언어 장벽 (Java, Python, Spark 등)
• 멀티 엔진 액세스 제한
• 불필요한 운영 복잡성 증가

REST Catalog의 등장

핵심 아이디어:

• HTTP 엔드포인트를 통한 범용 API 스펙
• 모든 클라이언트에 독립적인 표준화된 방식

장점:

• ✅ 표준화된 작업
• ✅ 언어 및 엔진 독립적
• ✅ 경량 종속성 관리
• ✅ 코드베이스 비대화 방지

주요 제공자:

• Gravitino
• Nessie
• Lakekeeper
• Polaris (Nessie와 통합 중)

2. REST Catalog 보안의 중요성

보안 미흡 시 위험

1) 컴플라이언스 (Compliance)

• 무단 액세스 시 모든 테이블/데이터베이스/스키마 나열 가능
• 데이터 위치의 정확한 경로 노출
• 규제 위반 위험:
• GDPR (EU)
• SOC 2
• HIPAA

2) 멀티 테넌시 (Multi-tenancy)

• 여러 팀이 하나의 카탈로그 공유
• 팀 간 격리 필요
• 자격증명 정책 시행 필요
• 예: 마케팅팀 ↔ 개발팀 액세스 분리

3) 다층 보안 (Multi-layered Security)

⚠️ 중요: 한 레이어만 보안하는 것으로는 부족

• 공격자가 테이블 경로를 파악하면 공격 초점 결정 가능
• 모든 레이어에서 보안 필요

3. REST 보안의 주요 과제

3.1 대규모 인증 (Authorization at Scale)

전통적 접근 방식의 문제:

• 엔진별 개별 사용자 계정 유지
• 신규 직원 수동 프로비저닝 (5개 이상 시스템)
• 좀비 계정 발생
• 비밀번호 재설정 복잡성
• MFA 등록 동기화 문제
• 역할 변경 시 모든 곳에서 동기화 필요

이상적 해결책:

• LDAP 또는 Kerberos 같은 범용 제공자
• 네이티브 계정에만 의존하지 않음

3.2 세밀한 액세스 제어 (Fine-grained Access Control)

필요한 권한 레벨:

• Namespace
• Table
• Column
• Row

전통적 모델의 문제:

• 각 엔진이 자체 권한 시스템 유지
• 중앙화된 진실의 원천(Single Source of Truth) 부재
• 엔진별 구현으로 인한 복잡성
• 실제 데이터 민감도를 반영하지 못함

3.3 자격증명 수명 주기 (Credential Lifecycling)

문제점:

Long-lived Cloud Credentials (엔진 설정에 하드코딩)
    ↓
높은 신뢰도 요구 + God User 권한
    ↓
대규모 자격증명 확산 (Credential Sprawl)
    ↓
엔진 침해 시 → 영구 스토리지 액세스 허용

위험:

• 자격증명이 영구적으로 존재
• 정책이 없으면 필요시까지 회전되지 않음
• 엔진 침해 시 치명적

3.4 멀티 클라우드 복잡성 (Multi-cloud Complexity)

현대 환경:

AWS (일부 서비스) + Azure (SharePoint 등) + GCP + Oracle + Confluent...

문제점:

• 각 클라우드 제공자마다 다른 권한 모델:
• AWS S3 Bucket Policy
• Azure RBAC
• GCS IAM
• 보안이 카탈로그/엔진에서 끝나지 않음
• 다른 구성 및 설정 필요

목표: REST 레이어와 카탈로그 레이어를 단순화하여 모든 클라우드와 쉽게 상호작용

4. 보안 전략 및 패턴

4.1 컴퓨트 강제 권한 (Query Engine Client Compute-Enforced Permissions)

아키텍처:

Query Engine (StarRocks)
    ↓
Identity Provider (IDP)
    ↓
REST Catalog Provider
    ↓
External Permission System (Apache Ranger / OPA)
    ↓
Storage (S3 등)

프로세스 흐름:

Step 1: Client Credential Flow 사용

Client ID + Client Secret → IDP → JWT Token 반환

Step 2: Super User로 토큰 전달

JWT Token (as Super User) → REST Catalog

⚠️ 문제: Super User(God-like) 권한으로 작동

Step 3: 토큰 검증

REST Catalog → IDP: "이 토큰이 유효한가?"
IDP → REST Catalog: "유효함, Super User임"

Step 4: 권한 시스템 검증

Token → Permission System: Super User가 할 수 있는 것은?
결과: 모든 것 가능 (Bob이든 Jane이든 동일)

Step 5: Vended Credentials 수신

Long-lived Storage Credentials → Query Engine

Step 6: Super User 권한 확인

Query Engine → External Permission System
(쿼리별 번역 필요)

Step 7: 데이터 조회

문제점:

• ❌ 암묵적 쿼리 엔진 신뢰
• ❌ 전체 시스템 액세스 권한
• ❌ 쿼리별 특정 구현
• ❌ 범용 스펙이 아님

4.2 카탈로그 레이어 거버넌스 (Catalog Layer Governance & Security)

이상적인 접근 방식

장점:

• ✅ 엔진 간 일관된 인증
• ✅ 보안되고 단순화된 스토리지
• ✅ 쿼리 엔진에 대한 암묵적 신뢰 불필요
• ✅ 쿼리 번역 레이어 불필요

RFC 기반 토큰 위임 (Token Delegation)

핵심 개념: Super User 대신 실제 사용자로 가장

프로세스 흐름:

Step 1: 사용자별 토큰 요청

Client ID + Authorization Flow (추가 컨텍스트)
    ↓
IDP → User A용 JWT Token 반환

Step 2: User A로 토큰 전달

JWT Token (as User A) → REST Catalog

✅ Super User 아님!

Step 3: 토큰 검증

REST Catalog → IDP: "이 토큰이 User A인가?"
IDP → REST Catalog: "확인됨, User A임"

Step 4: User A 권한 검증

Token → Permission System
카탈로그 레벨에서 직접 User A 권한 확인

✅ 외부 권한 시스템과의 쿼리별 번역 불필요

Step 5: 임시 Vended Credentials

Temporary Credentials → Query Engine

✅ 장기 자격증명 아님!

Step 6: 데이터 조회

주요 개선사항:

1. ✅ Super User 자격증명 없음
2. ✅ 쿼리별 번역 불필요
3. ✅ 임시 자격증명 사용

현재 상태:

• 이론적으로 작동
• Lakekeeper에서 일부 구현
• RFC for Token Exchange/Delegation 아직 널리 채택되지 않음
• 카탈로그가 유일한 권한 검증 엔터티로서의 역할이 아직 표준화되지 않음

5. StarRocks 4.0 구현

StarRocks 소개

• OLAP 데이터베이스 (실시간 분석용)
• Sub-second 쿼리 설계
• 온더플라이 조인
• 비정규화 파이프라인 불필요
• 컬럼형 스토리지에서 직접 변경 가능한 실시간 데이터
• SIMD 최적화
• 스토리지-컴퓨팅 분리 아키텍처

JWT Token Session-Based Catalog Enforced Permissions

StarRocks 4.0의 혁신:

• Token Exchange 프로토콜 대신 JWT Token 사용
• 더 안전한 서명된 JWT Token

프로세스:

Step 1: Pre-signed JWT Token

Identity Provider에서 사전 서명된 JWT Token
(사용자 로컬 또는 IDP 시스템에 저장)

Step 2: JWT Token 전달

Pre-signed JWT Token → REST Catalog

Step 3: 권한 시스템과 직접 검증

REST Catalog → Permission System
(즉시 검증)

Step 4: 임시 자격증명 수신

Temporary Credentials → Query Engine

✅ 장기 자격증명 아님!

Step 5: 데이터 조회

Security Integration (3.5+, 4.0)

기능:

• 외부 Identity Provider와 StarRocks 연동
• 원하는 Identity Provider 사용 가능
• 선택한 REST Catalog Provider와 통신
• JWT Token Bearer Flow를 통한 보안 액세스

주요 장점:

• ✅ Super User 불필요
• ✅ 실제 사용자 식별
• ✅ 카탈로그 강제 거버넌스 및 보안 구현
• ✅ 사전 IDP 서명으로 JWT Token 설정

6. 모범 사례 (Best Practices)

6.1 단일 진실 공급원 (Single Source of Truth)

Identity Provider = 신원의 권위 있는 소스
    ↓
사용자 IDP에서 제거 시
    ↓
모든 시스템에서 액세스 자동 취소

구현:

• 엔터프라이즈에서 하나의 진실된 Identity Provider 연결

6.2 직접 데이터 액세스 (Direct Data Access)

Multiple Tools/Query Engines
    ↓
Direct Access to Data

피해야 할 것:

• ❌ 중앙 컴퓨팅 병목
• ❌ 테이블을 차단하는 게이트웨이

목표:

• 여러 도구/쿼리 엔진이 데이터에 직접 액세스

6.3 중앙화된 권한 (Centralized Permissions)

Permissions (Table, Namespace 등)
    ↓
한 번 정의
    ↓
Catalog를 통해 평가
    ↓
Catalog Level Governance

장점:

• 권한 부여의 중앙 권한
• 여러 도구에 걸쳐 시행 가능
• Bob과 Jane이 개별 프로필을 가지지만 Super User로 취급되는 상황 방지

6.4 통합된 멀티 클라우드 권한

Data: AWS + Azure + GCP + Oracle + Confluent
    ↓
Unified Permissions
    ↓
물리적 위치와 무관하게 권한 유지

목표:

• 데이터가 여러 클라우드/환경에 있어도
• 권한은 물리적 위치와 관계없이 통합 유지

Q&A 주요 내용

Q: Hive와 Iceberg 테이블을 모두 지원하려면 Hive Metastore만 선택해야 하나?

A: 아니요. StarRocks는 External Catalog 개념을 사용합니다.

• Glue, JDBC 등 원하는 카탈로그 제공자 사용 가능
• CREATE EXTERNAL CATALOG 명령으로 연결
• Hive에만 국한되지 않음

Q: StarRocks 4.0에서 JWT Token Flow 설정 문서가 있나?

A: 예, 4.0용 JWT Flow 문서가 있습니다.

• JWT 인증 관련 상세 가이드 제공

Q: Token 교환에서 Super User 접근을 어떻게 우회하나?

A:

• Pre-signed JWT Token 사용 (클라이언트 측 또는 LDAP 시스템)
• Security Integration 기능 활용
• JWT Token Session 사용으로 Super User 불필요

Q: 언제 완전히 구현되나?

A:

• Token Flow는 4.0에 이미 구현됨
• 사용자 질문/문제는 엔지니어링과 협력하여 해결 가능
• 4.0의 새로운 제공 기능이지만 완전히 구현됨

Q: Nessie와 Polaris 통합에 대해 더 설명해주세요

A:

• Nessie가 개발 중단 중
• 많은 기능이 Polaris로 통합 중
• Snowflake 관련 (세부 사항은 추가 확인 필요)

Q: Security Integration이 작동하지 않는 경우?

A:

• Slack을 통해 직접 문의
• 엔지니어와 함께 문제 해결
• Security Integration은 정상 작동해야 함

추가 리소스

• Slack 커뮤니티: 기술 지원 및 질문
• RFC 문서: Token Exchange/Delegation RFC 참조
• 데모 영상: 곧 출시 예정 (End-to-end 설정 데모)
• 공식 문서: StarRocks 4.0 JWT Authentication Guide

요약

핵심 메시지:

1. REST Catalog는 Iceberg 보안의 핵심
2. 전통적인 Super User 방식은 보안 위험
3. Catalog Layer Governance가 이상적인 접근 방식
4. StarRocks 4.0은 JWT Token Bearer Flow로 이를 구현
5. 보안은 다층적 접근이 필요 (Catalog + Cloud)

미래 방향:

• Token Delegation RFC의 업계 표준화
• Catalog가 권한의 단일 권위 소스로 자리잡기
• 더 나은 멀티 클라우드 통합

비교표: 컴퓨트 강제 vs 카탈로그 강제

본 문서는 StarRocks Iceberg REST Catalog 보안 웨비나 내용을 정리한 것입니다.최신 정보는 공식 StarRocks 문서를 참조하세요.