주요 컨텐츠로 이동

서비스 주체를 위한 OAuth 2.0 Git 자격 증명 지원이 이제 일반적으로 사용 가능합니다

GitHub 및 Azure DevOps에서 짧은 수명을 가지고 자동으로 새로 고침되는 OAuth 토큰을 사용하여 Git 워크플로우를 자동화하십시오

OAuth 2.0 Git credential support for Service Principals is now Generally Available

Published: June 18, 2025

제품1분 이내 소요

Summary

  • 서비스 주체를 위한 OAuth Git 자격 증명이 이제 GitHub 및 Azure DevOps에서 GA입니다.
  • 토큰은 자동으로 새로 고쳐지며, 몇 시간 후에 만료되며, 저장소 범위로 지정될 수 있습니다.
  • 오래 지속되고 넓게 범위가 지정된 PATs와 수동 토큰 회전의 필요성을 제거합니다.

일반적으로, Databricks는 보안을 강화하기 위해 Databricks와의 인증에 개인 액세스 토큰(PATs) 대신 OAuth를 사용하는 것을 권장합니다. 이제 이 권장사항을 Databricks Git 자격 증명에 확장하고, Git 제공 업체와 인증할 때 Git 제공 업체의 PATs 대신 OAuth를 사용하도록 권장합니다.

오늘, 우리는 서비스 주체를 위한 OAuth Git 자격 증명 지원 의 일반적인 사용 가능성을 GitHubAzure DevOps와 함께 발표하게 되어 기쁩니다. 이는 자동화된 작업 부하를 위한 Git 연결 보안을 향상시킵니다.

Databricks Git 통합은 처음에는 인증을 위한 PATs만 지원했습니다. 사용자들은 Git 제공자와 함께 개인 접근 토큰을 생성하고 Databricks에 토큰을 저장했습니다. 이 방법은 몇 가지 이유로 더 이상 권장되지 않습니다, 포함하여:

  • [긴 수명] PATs는 짧은 수명의 토큰(시간/일)보다 더 긴 접근 기간(주/월)을 제공합니다. 관리자는 PAT 수명을 짧게 설정할 수 있지만, 이는 사용자가 만료 시 워크플로 실패를 피하기 위해 자주 Databricks Git 자격 증명을 업데이트해야 하는 운영상의 도전을 만듭니다.
  • [안전하지 않은 저장 및 전송] 사용자들은 종종 PATs를 수동으로 복사하는데, 이로 인해 클립보드와 문서에 흔적이 남을 수 있습니다.
  • [넓은 범위] 일부 PATs, 예를 들어 GitHub Classic PATs, 사용자가 접근할 수 있는 모든 저장소에 적용됩니다. 이 행동은 쉽게 의도하지 않은 권한 상승을 초래하고 측면 이동을 허용할 수 있습니다.
  • [서비스 주체 지원 누락] Azure DevOps와 같은 일부 Git 제공자는 서비스 주체에 대한 PATs 생성을 지원하지 않습니다.

가장 인기 있는 Git 제공 업체들은 PATs의 사용을 권장하지 않습니다: GitHubAzure DevOps 는 PAT를 오래 지속되는 통합에 사용하는 것을 권장하지 않습니다. Bitbucket 은 Bitbucket Cloud 통합 또는 앱 개발자가 액세스 토큰 대신 OAuth를 사용하여 사용자 인증을 사용하도록 권장합니다.

Databricks는 몇 년 동안 OAuth 2.0 기반 사용자 인증GitHubAzure DevOps 와 함께 지원했지만, 이 지원은 이전에는 대화형 사용자 세션에 한정되었습니다.

이제 서비스 주체 지원이 일반적으로 사용 가능하므로, 이러한 Git 제공 업체와 통합할 때 대화식 및 자동화된 워크플로우 모두에 대해 PATs 대신 OAuth를 사용하는 것이 우리의 권장사항입니다. 이점은 무엇인가요? 우리의 GitHub 앱 통합을 예로 들어 보겠습니다:

  • OAuth 토큰은 기본적으로 자동으로 새로 고쳐집니다. 사용자들은 더 이상 PAT 토큰이 만료될 때 오류를 마주치지 않습니다.
  • OAuth는 통합된 저장소의 보기 및 접근에 대해 향상된 관리 제어를 제공합니다.
  • OAuth를 사용하면 특정 GitHub 레포에 대한 액세스를 구성할 수 있습니다.
  • 액세스 토큰은 짧은 수명을 가지며(이 경우, 8시간), 이는 자격 증명 노출의 위험을 줄입니다.

일부 고객들은 SSH 인증 및 GPG 커밋 서명을 요청했습니다. 그러나, 우리는 SSH와 GPG 대신 OAuth 지원에 투자하기로 결정했습니다. 이는 사용자가 Databricks에 개인 키를 업로드해야 하며, 이는 PAT를 저장하는 것과 유사하게, 오래된 자격 증명과 수동 회전이라는 같은 단점을 초래하기 때문입니다. 더욱이, 부적절하게 범위가 지정된 SSH 키가 탈취되면, 공격자에게 Git 서버 호스트에 대한 직접적인 접근 권한을 부여할 수 있어, 악용 위험이 크게 증가합니다.

시작하기

GitHub의 경우, 사용자 설정과 유사한 과정을 따라 서비스 주체의 설정 페이지에서 서비스 주체 GitHub 앱 연결을 구성할 수 있습니다. Azure DevOps의 경우, 이제 OpenID Connect (OIDC)를 기반으로 한 연합 자격 증명을 사용하는 서비스 주체에 대한 OAuth 연결을 지원합니다. OIDC는 로그인한 사용자에 대한 로그인 및 프로필 정보를 제공하는 OAuth 2.0 위에 구축된 인증 프로토콜입니다. OIDC는 사용자가 신뢰할 수 있는 신원 제공자(IdP, 이 경우 Microsoft EntraID)와 한 번 인증하고 자격 증명을 다시 입력할 필요 없이 기억되도록 하여 안전하고 사용자 친화적인 로그인 경험을 가능하게 합니다. 이 새로운 기능은 이 블로그에서 설명된 이전의 스크립팅 기반 접근 방식을 대체하여, 이 중요한 사용자 여정을 몇 시간에서 몇 분으로 크게 단축하고 간소화합니다.

앞으로의 계획

우리는 OAuth 2.0 통합을 GitLab 및 Bitbucket과 같은 더 많은 Git 제공자, 그리고 지원되는 Git 제공자의 엔터프라이즈 및 자체 호스팅 솔루션에 확장할 계획입니다.

행동 요령

Databricks Git 자격 증명 OAuth 2.0 지원에 대한 자세한 안내를 위해 문서를 참조하십시오 그리고 Azure EntraID 서비스 주체에 대한 새로운 연합 신원 지원. 오늘날 당신의 Git 자격 증명을 PATs에서 OAuth 2.0으로 전환하고, Databricks Community에 피드백을 게시하여 당신의 생각을 공유하세요!

 

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

게시물을 놓치지 마세요

관심 있는 카테고리를 구독하고 최신 게시물을 받은편지함으로 받아보세요