Skip to Content
Data EngineeringDatabricks Apps의 인증·권한과 시크릿 연결
📊 Data Engineering2026년 1월 6일

Databricks Apps의 인증·권한과 시크릿 연결

#databricks#databricks-apps#service-principal#secrets-management#unity-catalog

Databricks Apps를 연결할 때는 앱에 접속한 사람과 데이터에 접근하는 주체가 같다고 가정하면 안 됩니다. 앱은 자신의 Service Principal로 요청할 수도 있고, 사용자 권한을 전달받아 요청할 수도 있습니다.

개인 토큰으로 기능을 확인한 뒤 운영용 앱을 준비할 때도 이 구분이 필요했습니다. 인증에 성공하더라도 필요한 데이터에 접근할 권한은 따로 확인해야 했습니다. 이 글은 그때 확인한 내용에 2026년 10월 공식 문서의 설정 방법을 보태 정리했습니다.

앱과 사용자의 권한

Databricks 앱에는 전용 Service Principal이 생성됩니다. 앱 자체의 권한으로 접근하는 App authorization에서는 이 주체에 부여한 권한을 사용합니다. 사용자가 관리자라고 앱도 관리자 권한으로 실행되는 것은 아닙니다.

요청 방식Databricks가 평가하는 주체주로 검토할 상황
App authorization앱 전용 Service Principal공통 데이터와 백그라운드 작업
User authorization현재 사용자의 권한과 허용한 OAuth scope사용자별 데이터 접근 제한

앱 권한으로 조회하면 방문한 사용자의 행 필터가 그대로 적용된다고 가정할 수 없습니다. 사용자별 데이터 제한이 필요하다면 User authorization과 요청 코드에서 사용하는 인증 정보를 함께 확인해야 합니다. 사용자 권한 방식도 앱에 허용한 scope를 넘어서는 요청까지 가능해지는 것은 아닙니다.

앱 인증 정보의 사용

앱 런타임에는 DATABRICKS_CLIENT_ID와 DATABRICKS_CLIENT_SECRET이 자동으로 제공됩니다. 이를 직접 코드나 배포 설정에 복사하기보다 SDK의 unified authentication을 사용할 수 있습니다.

python
sample/app-client.py
from databricks.sdk import WorkspaceClient
 
client = WorkspaceClient()

이 코드는 클라이언트를 구성하는 최소 예시입니다. 데이터 조회를 실행하거나 성공을 확인한 코드는 아닙니다. 호출할 API와 그 리소스에 대한 권한을 별도로 맞춰야 합니다. 사용자 권한으로 요청할 코드라면 이 기본 클라이언트가 앱 주체로 인증되는 경로와 구분해야 합니다.

테이블과 실행 자원의 접근 권한

앱의 Authorization 화면에서 전용 Service Principal을 확인하고, 대상 리소스의 Permissions에서 같은 주체를 찾아 권한을 부여했습니다. 표시 이름과 실제 주체를 혼동하지 않도록 ID도 확인해야 했습니다.

아래는 읽기 전용 접근의 SQL 예시입니다. 자산 이름과 Service Principal의 application ID는 실제 대상으로 바꿔야 하며, 이 권한을 부여할 수 있는 주체가 실행해야 합니다.

sql
sample/app-read-permissions.sql
GRANT USE CATALOG ON CATALOG analytics
TO `<app-service-principal-application-id>`;
GRANT USE SCHEMA ON SCHEMA analytics.audit
TO `<app-service-principal-application-id>`;
GRANT SELECT ON TABLE analytics.audit.events
TO `<app-service-principal-application-id>`;

SQL warehouse를 사용하면 해당 warehouse의 CAN USE도 필요합니다. Unity Catalog 권한과 실행 자원의 권한을 함께 봐야 접근 오류를 구분할 수 있습니다.

외부 API 키와 시크릿 리소스

Databricks 인증과 외부 API 키는 관리 경로가 다릅니다. 외부 시크릿 저장소를 직접 읽는 구성이라면 네트워크 접근과 조회 권한도 필요합니다. 저장소 이름만 정하고 앱에서 실제로 읽을 경로를 확인하지 않으면 실행 중에 막힐 수 있습니다.

Databricks secret scope의 값을 사용할 때는 앱에 Secret 리소스를 추가하고 app.yaml의 valueFrom으로 참조할 수 있습니다. 아래는 external-api-key라는 리소스 키를 앱에 등록한 경우의 예시입니다.

yaml
sample/app.yaml
command: ["python", "app.py"]
env:
  - name: EXTERNAL_API_KEY
    valueFrom: external-api-key

원문 값을 value에 넣는 대신 리소스를 참조합니다. Secret 리소스의 접근 권한은 선택한 키 하나가 아니라 scope 단위로 부여되므로, 앱에 필요한 시크릿만 담은 scope를 사용하는지도 확인해야 합니다.

CLI를 통한 수정과 배포

auth login과 apps 명령은 신형 Databricks CLI를 기준으로 봐야 합니다. 구형 Python 패키지인 databricks-cli를 설치하는 명령과 섞으면 사용할 수 있는 명령이 다릅니다. 공식 설치 문서에서 운영체제에 맞는 CLI를 설치한 뒤 버전을 확인합니다.

bash
sample/apps-deploy.sh
databricks version
databricks auth login --host "https://<workspace-host>"
 
# 이미 생성한 앱에 준비된 워크스페이스 소스를 배포하는 예시
databricks apps deploy my-app   --source-code-path "/Workspace/Users/<user>/my-app"

로컬 수정 사항을 워크스페이스에 동기화하는 작업과 앱을 새 버전으로 배포하는 작업은 다릅니다. databricks sync --watch를 사용하더라도 배포 완료까지 자동으로 확인되는 것은 아닙니다.

배포 문제는 패키지 설치, 시작 명령, 환경 변수, 인증 주체, 데이터·실행 자원 권한으로 나눠 확인하는 편이 좋았습니다. 로그인이나 빌드 성공만으로 실제 데이터 조회까지 끝났다고 판단하지 않아야 합니다.

참고 자료

Last updated on