Skip to main content
이 문서는 Unity Catalog 섹션의 일부입니다.

Storage Credential이란?

Storage Credential(Storage Credential) 은 Unity Catalog가 클라우드 스토리지(S3, ADLS, GCS)에 접근할 때 사용하는 인증 정보 객체 입니다. External Location(External Location)을 생성하려면 반드시 Storage Credential이 필요합니다.
💡 비유: Storage Credential은 “건물 마스터키”와 같습니다. 이 키가 있어야 External Location(건물 내 특정 사무실)에 접근할 수 있습니다. Databricks는 사용자의 클라우드 자격 증명 대신, Unity Catalog가 관리하는 자격 증명으로 스토리지에 접근합니다.

클라우드별 인증 방식

각 클라우드 환경마다 지원하는 인증 방식이 다릅니다.

AWS: IAM Role

AWS 환경에서는 IAM Role 을 사용하여 S3 버킷에 접근합니다. Databricks가 이 역할을 Assume(위임) 하여 스토리지에 접근합니다.

Azure: Managed Identity / Service Principal

Azure 환경에서는 Managed Identity 또는 Service Principal 을 사용합니다.

GCP: Service Account

GCP 환경에서는 Service Account 를 사용하여 GCS 버킷에 접근합니다.

Storage Credential 생성

SQL 문법

실전 예시


Storage Credential과 External Location 연결

Storage Credential을 생성한 후, 이를 사용하여 External Location을 등록합니다.

권한 모델

Storage Credential 권한

권한 부여 예시


Storage Credential 관리

조회

수정 및 삭제


AWS IAM Role 신뢰 정책 설정

AWS에서 Storage Credential을 사용하려면, IAM Role의 신뢰 정책(Trust Policy) 에 Databricks를 추가해야 합니다.
<external-id-from-databricks>는 Storage Credential 생성 시 Databricks가 제공하는 고유 식별자입니다. 이 값을 IAM Role의 신뢰 정책에 추가해야 안전한 위임이 가능합니다.

모범 사례


실전 인사이트: IAM Role을 하나만 만들어서 모든 버킷에 접근하게 한 실수

초기 Databricks 도입 시 가장 흔한 실수가 **“편의를 위해 하나의 IAM Role에 모든 S3 버킷 접근 권한을 몰아주는 것”**입니다.

사고 사례

한 고객이 위와 같은 IAM 정책으로 Storage Credential을 생성했습니다. 처음에는 “어차피 Unity Catalog가 External Location 단위로 접근을 제어하니까 IAM은 넓게 열어도 괜찮다”고 생각했습니다. 그런데 문제가 발생한 상황은 다음과 같습니다:

올바른 설계: 용도별 Credential 분리

💡 원칙: Credential은 용도(analytics, ML, raw data)와 환경(dev, staging, prod) 별로 분리하세요. 하나의 Credential이 접근할 수 있는 범위가 좁을수록, 사고 시 피해 범위도 좁아집니다.

실전 인사이트: 크로스 계정 접근의 실전 구성

대규모 조직에서는 AWS 계정이 여러 개로 분리되어 있는 경우가 대부분입니다. Databricks가 있는 계정(Account A)에서 데이터가 있는 계정(Account B)의 S3에 접근해야 하는 시나리오입니다.

크로스 계정 구성 단계

역할 체인: UC Master Role → Credential Role → Data Role
⚠️ 크로스 계정 접근 시 주의사항:
  • STS 토큰 만료: AssumeRole 체인이 길어지면 토큰 갱신이 빈번해집니다. 장시간 배치 잡에서 토큰 만료 에러가 날 수 있으므로, 세션 기간(Duration)을 충분히 설정하세요 (최대 12시간)
  • 리전 일치: S3 버킷과 IAM Role이 같은 리전에 있어야 지연이 최소화됩니다
  • CloudTrail 양쪽 활성화: Account A와 B 모두에서 AssumeRole 이벤트를 추적할 수 있도록 CloudTrail을 활성화하세요

실전 인사이트: Credential 라이프사이클 관리

Storage Credential은 생성 후 “방치”되기 쉬운 객체입니다. 시간이 지나면 IAM Role이 삭제되거나, 정책이 변경되어 접근이 실패하는 경우가 발생합니다.

월간 점검 체크리스트

Credential 변경 시 영향 분석

IAM Role 정책을 변경하기 전에, 해당 Credential을 사용하는 모든 External Location과 테이블을 파악해야 합니다.
💡 실전 팁: Credential이나 IAM Role을 변경할 때는 반드시 dev 환경에서 먼저 테스트 하세요. 프로덕션에서 VALIDATE가 실패하면 모든 외부 테이블 쿼리가 즉시 실패합니다. Terraform이나 Databricks Asset Bundles로 Credential을 코드로 관리하면, 변경 이력 추적과 롤백이 용이합니다.

정리


참고 링크