본문 바로가기
WIKI 기술 지식 베이스

Azure DevOps Locations

원문 보기 위키 갱신

Azure DevOps 통합은 Azure DevOps에서 카탈로그 엔티티를 로드하는 것을 지원해요.

출처: 문서

본문

Azure DevOps 통합은 Azure DevOps에서 카탈로그 엔티티를 로드하는 것을 지원해요. 엔티티는 정적 카탈로그 구성에 추가하거나, catalog-import 플러그인으로 등록할 수 있어요.

인증

Azure 통합은 Azure DevOps에 대해 인증하는 여러 방법을 지원해요. 다음 섹션에서는 각 인증 방법에 대해 통합을 구성하는 방법을 설명해요.

서로 다른 Azure DevOps 조직에 별도의 인증 방법을 구성하는 것도 가능해요. 조직이 여럿 있고 각 조직마다 서로 다른(또는 서로 다른) 자격 증명을 사용하고 싶다면(또는 써야 한다면) 유용해요.

클라이언트 비밀이 있는 서비스 주체 사용하기

서비스 주체는 Azure DevOps에 대해 인증하는 데 사용할 수 있는 Entra ID ID예요. 서비스 주체는 Entra ID에서 만들어지며 클라이언트 ID와 클라이언트 비밀(사용자 이름과 비밀번호와 유사)을 가져요.

다음 구성은 서비스 주체를 사용해 Azure DevOps에 대해 인증하는 방법을 보여줘요.

integrations:  azure:    - host: dev.azure.com      credentials:        - clientId: ${AZURE_CLIENT_ID}          clientSecret: ${AZURE_CLIENT_SECRET}          tenantId: ${AZURE_TENANT_ID}

서비스 주체에 접근 권한을 부여하는 방법은 Azure DevOps 문서를 참고하세요.

시스템 할당 관리 ID 사용하기

시스템 할당 관리 ID는 특정 Azure 리소스에 연결되고 Azure가 관리하는 Entra ID ID예요. 사용자 할당 관리 ID와 달리, 시스템 할당 관리 ID는 할당된 리소스와 수명 주기를 공유하며 Azure는 그 ID를 특정 리소스만 사용할 수 있음을 보장해요.

다음 구성은 시스템 할당 관리 ID를 사용해 Azure DevOps에 대해 인증하는 방법을 보여줘요.

integrations:  azure:    - host: dev.azure.com      credentials:        - clientId: system-assigned

관리 ID에 접근 권한을 부여하는 방법은 Azure DevOps 문서를 참고하세요.

사용자 할당 관리 ID 사용하기

사용자 할당 관리 ID는 사용자가 독립 실행형 리소스로 만들고 하나 이상의 Azure 리소스에 할당하는 Entra ID ID예요. 이렇게 하면 여러 리소스에서 같은 관리 ID를 사용할 수 있어요.

다음 구성은 사용자 할당 관리 ID를 사용해 Azure DevOps에 대해 인증하는 방법을 보여줘요.

integrations:  azure:    - host: dev.azure.com      credentials:        - clientId: ${AZURE_CLIENT_ID}

관리 ID에 접근 권한을 부여하는 방법은 Azure DevOps 문서를 참고하세요.

개인용 액세스 토큰(PAT) 사용하기

개인용 액세스 토큰(PAT)은 특정 범위와 만료 날짜로 생성하는 토큰이에요. Backstage가 사용자를 대신해 Azure DevOps에 대해 인증할 수 있게 해줘요.

다음 구성은 개인용 액세스 토큰을 사용해 Azure DevOps에 대해 인증하는 방법을 보여줘요.

integrations:  azure:    - host: dev.azure.com      credentials:        - personalAccessToken: ${PERSONAL_ACCESS_TOKEN}

개인용 액세스 토큰을 만드는 방법은 Azure DevOps 문서를 참고하세요

관리 ID로 클라이언트 어서션을 생성하는 서비스 주체 사용하기

관리 ID로 클라이언트 어서션을 생성하는 것은 고급 시나리오예요. Azure Entra ID에서 앱 등록에 대한 페더레이션 자격 증명을 설정해야 해요.

이는 관리 ID 자체와 다른 테넌트에 있는 Azure DevOps 조직에 대해 인증하고 싶을 때 가장 유용해요. 그 외에는 일반 관리 ID가 더 적합한 선택일 가능성이 커요.

페더레이션 자격 증명 추가하기

관리 ID로 클라이언트 어서션을 생성하려면 Azure Entra ID에서 페더레이션 자격 증명을 만들어야 해요. 다음 단계를 따라가세요.

  • Entra ID에서 앱 등록을 만드세요(또는 기존 항목 사용).

  • 앱 등록의 "Certificates & secrets" 탭으로 이동하세요.

  • "Customer managed keys" 시나리오로 새 페더레이션 자격 증명을 추가하세요.

  • 클라이언트 어서션을 생성하는 데 사용할 관리 ID를 선택하세요.

  • 이름과 설명을 입력하세요.

  • "Add"를 클릭하세요.

이제 Backstage의 Azure DevOps 통합에 필요한 구성을 추가할 수 있어요. ${APP_REGISTRATION_CLIENT_ID}는 페더레이션 자격 증명을 추가한 Entra ID의 앱 등록 클라이언트 ID예요.

클라이언트 어서션을 생성하는 시스템 할당 관리 ID 사용하기

이것은 가장 안전한 옵션이에요. Azure는 그 ID를 특정 리소스만 사용할 수 있음을 보장하지만, 사용자 할당 관리 ID는 같은 테넌트의 아무 리소스에나 할당될 수 있기 때문이에요.

integrations:  azure:    - host: dev.azure.com      credentials:        - clientId: ${APP_REGISTRATION_CLIENT_ID}          managedIdentityClientId: system-assigned          tenantId: ${AZURE_TENANT_ID}

클라이언트 어서션을 생성하는 사용자 할당 관리 ID 사용하기

integrations:  azure:    - host: dev.azure.com      credentials:        - clientId: ${APP_REGISTRATION_CLIENT_ID}          managedIdentityClientId: ${MANAGED_IDENTITY_CLIENT_ID}          tenantId: ${AZURE_TENANT_ID}

여러 Azure DevOps 조직에 대해 인증하기

자격 증명에 organizations 필드를 지정하면 서로 다른 Azure DevOps 조직에 특정 자격 증명을 사용할 수 있어요.

integrations:  azure:    - host: dev.azure.com      credentials:        - organizations:            - my-org            - my-other-org          clientId: ${AZURE_CLIENT_ID}          clientSecret: ${AZURE_CLIENT_SECRET}          tenantId: ${AZURE_TENANT_ID}        - organizations:            - another-org          clientId: ${AZURE_CLIENT_ID}        - organizations:            - yet-another-org          personalAccessToken: ${PERSONAL_ACCESS_TOKEN}

organizations 필드를 지정하지 않으면 그 자격 증명은 다른 자격 증명이 구성되지 않은 모든 조직에 사용돼요.

다른 테넌트에 있는 Azure DevOps 조직에 대해 인증하기

서비스 주체와 다른 테넌트에 있는 Azure DevOps 조직에 대해 인증해야 한다면 다음 중 하나를 해야 해요.

  • Entra ID에서 다중 테넌트 애플리케이션을 만드세요.

  • 기존 애플리케이션을 다중 테넌트 애플리케이션으로 변환하세요.

note

애플리케이션이 Graph API 권한을 하나 이상 요청하는지 확인하세요. 다른 테넌트에 애플리케이션을 설치하려면 이 권한이 필요합니다. 요청할 수 있는 최소 권한은 Delegated 타입의 email 권한입니다. 이렇게 하면 애플리케이션이 로그인한 사용자의 이메일 주소를 읽을 수 있지만, openid 권한이 없으면 사용자가 실제로 로그인할 수는 없습니다.

그 후 다른 테넌트의 관리자가 요청된 권한에 대한 관리자 동의를 제공해 애플리케이션을 설치해야 해요. 이는 다음 URL을 방문해 할 수 있어요.

https://login.microsoftonline.com/<other-tenant-id>/oauth2/authorize?client_id=<client-id>&response_type=code&redirect_uri=<redirect-uri>

<other-tenant-id>는 다른 테넌트의 테넌트 ID, <client-id>는 애플리케이션의 클라이언트 ID(여러분의 테넌트에서), <redirect-uri>는 애플리케이션에 대해 구성된 리다이렉트 URI예요. 리다이렉트 URI는 앱 등록에서 유효한 URI여야 하지만, 이 목적으로는 https://backstage.io 같은 어떤 유효한 URI도 사용할 수 있어요.

관리자가 애플리케이션에 동의한 후, 다른 테넌트에는 원래 테넌트의 앱 등록과 같은 클라이언트 ID를 가진 엔터프라이즈 애플리케이션(서비스 주체라고도 함)이 생성돼요. 이제 다른 테넌트의 Azure DevOps 조직에 서비스 주체 접근 권한을 부여할 수 있어요. 다른 테넌트의 Azure DevOps 조직에 대해 인증하려면 이전과 같은 서비스 주체를 다른 테넌트의 테넌트 ID와 함께 사용할 수 있어요.

integrations:  azure:    - host: dev.azure.com      credentials:        - clientId: ${APP_REGISTRATION_CLIENT_ID}          managedIdentityClientId: system-assigned          tenantId: ${OTHER_TENANT_ID}

여기서 ${APP_REGISTRATION_CLIENT_ID}는 여러분이 자신의 테넌트에서 만든 다중 테넌트 앱 등록의 클라이언트 ID이고, ${OTHER_TENANT_ID}는 . 테넌트의 테넌트 ID예요.

note

위 예시는 클라이언트 어서션을 생성하는 데 시스템 할당 관리 ID를 사용합니다. 클라이언트 어서션을 생성하는 데 사용자 할당 관리 ID를 사용하거나 애플리케이션에 대해 인증하는 데 클라이언트 비밀을 사용할 수도 있습니다.

하지만 시스템 할당 관리 ID가 가장 안전한 옵션입니다.

  • Azure는 그 ID를 특정 리소스만 사용할 수 있음을 보장하지만, 사용자 할당 관리 ID는 어떤 리소스에서도 사용될 수 있습니다.

  • 기저의 비밀을 관리할 필요가 없습니다. Azure가 그걸 처리해 주니까요.

레거시 {org}.visualstudio.com 도메인

Backstage는 앞서 언급한 모든 인증 옵션과 함께 레거시 {org}.visualstudio.com 도메인을 지원해요. 단, 각 Azure DevOps 조직은 단일 자격 증명과 함께 구성에 정의되어야 해요.

예를 들어, 이것은 동작해요.

integrations:  azure:    - host: my-org.visualstudio.com      credentials:        - clientId: ${AZURE_CLIENT_ID}          clientSecret: ${AZURE_CLIENT_SECRET}          tenantId: ${AZURE_TENANT_ID}

이것도 동작해요.

integrations:  azure:    - host: my-other-org.visualstudio.com      credentials:        - personalAccessToken: ${PERSONAL_ACCESS_TOKEN}

하지만 이것은 동작하지 않아요.

integrations:  azure:    - host: my-org.visualstudio.com      credentials:        - organizations:            - my-org            - my-other-org          clientId: ${AZURE_CLIENT_ID}          clientSecret: ${AZURE_CLIENT_SECRET}          tenantId: ${AZURE_TENANT_ID}

구성 스키마

구성은 다음 요소들을 가진 구조예요.

  • credentials: (선택) 다음 중 하나여야 해요.

  • 클라이언트 비밀을 사용하는 서비스 주체

  • 관리 ID 클라이언트 어서션을 사용하는 서비스 주체

  • 관리 ID

  • 개인용 액세스 토큰

credentials 요소는 배열이며, 각 항목은 다음 요소들을 정확히 가진 구조예요.

  • 클라이언트 비밀이 있는 서비스 주체:

  • clientId: 서비스 주체의 클라이언트 ID

  • clientSecret: 서비스 주체의 클라이언트 비밀

  • tenantId: 서비스 주체의 테넌트 ID

  • 관리 ID 클라이언트 어서션이 있는 서비스 주체:

  • clientId: 서비스 주체의 클라이언트 ID

  • managedIdentityClientId: 클라이언트 어서션 토큰을 생성하는 데 사용되는 관리 ID의 클라이언트 ID. 시스템 할당 관리 ID에는 system-assigned를 사용하거나 사용자 할당 관리 ID의 클라이언트 ID를 사용하세요.

  • tenantId: 서비스 주체의 테넌트 ID

  • 관리 ID:

  • clientId: 클라이언트 어서션 토큰을 생성하는 데 사용되는 관리 ID의 클라이언트 ID.

  • 개인용 액세스 토큰:

  • personalAccessToken: 개인용 액세스 토큰

note

  • Azure DevOps Server(온프레미스) 조직에는 서비스 주체나 관리 ID를 사용할 수 없습니다

  • Microsoft Entra ID(이전 Azure Active Directory) 기반 Azure DevOps 조직에서만 서비스 주체나 관리 ID를 사용할 수 있습니다

  • 조직이 지정되지 않은 채 호스트당 자격 증명 하나만 지정할 수 있습니다

  • 개인용 액세스 토큰은 Azure DevOps가 생성한 원시 토큰을 base64 인코딩 없이 raw_token 형식으로 제공하면 됩니다. 형식 지정과 base64 인코딩은 Azure DevOps API를 처리하는 종속 라이브러리가 처리합니다

  • 클라이언트 어서션을 생성하는 데 사용되는 관리 ID는 앱 등록과 같은 Entra ID 테넌트에 있어야 합니다

더 알아보기 (Learn more)