왜 인증이 중요한가
Databricks는 데이터 레이크하우스의 모든 자산 — 테이블, 모델, 노트북, Job — 에 대한 접근을 API 기반 으로 제어합니다. 웹 UI에서 클릭하든, CLI에서 명령을 실행하든, CI/CD 파이프라인이 자동으로 배포하든, 결국은 REST API 호출이 발생하고, 그 호출에는 반드시 “누가(Who) 어떤 권한(What)으로 요청하는가” 를 증명하는 인증 토큰이 필요합니다. 인증이 부실하면 다음과 같은 문제가 연쇄적으로 발생합니다.
이 가이드에서 다루는 모든 인증 방법의 공통 목표는 하나입니다: Zero Trust 보안 모델 하에서, 모든 요청에 대해 신원을 검증하고, 최소한의 권한만 부여하며, 자격 증명의 수명을 최소화하는 것 입니다.
인증 방법 전체 비교
아래 테이블은 Databricks가 지원하는 네 가지 인증 방법의 핵심 차이를 한눈에 보여줍니다.
핵심 시사점: OAuth 기반 인증(U2M, M2M, Token Federation)은 모두 1시간 수명의 단기 토큰 을 사용합니다. 토큰이 유출되더라도 1시간 후 자동 만료되므로 피해 범위가 제한됩니다. 반면 PAT는 사용자가 설정한 수명(최대 무기한)까지 유효하며, 유출 시 수동으로 폐기하기 전까지 악용될 수 있습니다. Databricks는 모든 시나리오에서 OAuth를 강력히 권장 합니다.
어떤 인증을 선택해야 하는가?
의사결정은 “누가 인증하는가”와 “어떤 환경에서 실행되는가” 두 가지 축으로 결정됩니다.시나리오별 가이드
아래 테이블은 실무에서 자주 만나는 시나리오와 적합한 인증 방법을 매핑합니다.
위 테이블에서 알 수 있듯이, 프로덕션 환경에서는 PAT를 사용하는 시나리오가 없습니다. PAT는 개발 초기 단계의 빠른 검증용으로만 활용하고, 반드시 OAuth로 전환해야 합니다.
On-Behalf-Of (위임 인증) 개념
Databricks 인증에서 가장 중요하면서도 자주 혼동되는 개념이 On-Behalf-Of (OBO) 입니다.핵심 아이디어
사용자가 Databricks CLI를 실행하면, CLI 자체가 Databricks에 접근하는 것이 아닙니다. CLI는 사용자를 대신하여(on behalf of) API를 호출합니다. 즉:- 인증 주체: 사용자 본인 (브라우저로 로그인)
- 실행 주체: CLI/SDK/IDE (도구)
- 권한: 사용자 본인의 권한 그대로 적용
이 설명이 보여주듯, OBO는 보안과 감사의 핵심입니다. 도구에 독립적인 권한을 부여하지 않으므로, 사용자 퇴사 = 도구 접근 자동 차단 이 됩니다.
OBO vs Service Principal
다음 단계
각 인증 방법의 동작 원리, 설정 방법, 코드 예시를 상세히 다루는 서브페이지로 이동하세요.참고 권장 읽기 순서: 개발자라면 OAuth U2M → OAuth M2M → PAT & Token Federation 순서로 읽으세요. 플랫폼 관리자라면 이 README의 비교 테이블을 기준으로 팀에 적합한 인증 정책을 먼저 결정한 후, 해당 방법의 상세 가이드를 참고하세요.