90DaysOfDevOps (Day 74)

고태규·2026년 1월 19일
devops

DevOps

목록 보기
69/87
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 74 - Workload Identity Federation with Azure DevOps and Terraform

1. Workload Identity Federation 이란?

해당 프레젠테이션은 Azure 클라우드 환경에서 보안의 핵심 트렌드로 자리 잡은 '워크로드 아이덴티티 페더레이션(Workload Identity Federation)'에 대해 다룬다.

기존의 서비스 연결 방식이 가진 보안 취약점을 해결하고, 이 복잡한 설정 과정을 테라폼으로 자동화하는 방법, 그리고 실제 적용 시 주의해야 할 트러블슈팅 사례까지 상세히 정리한다.

시작에 앞서, 워크로드 아이덴티티 페더레이션(Workload Identity Federation)과 페더레이션 자격 증명(Federated Credentials)이 무엇인지, 왜 필요한지 정리해보겠다.

1-1. 기존 방식의 문제점 (Secret 기반)

기존에 Azure DevOps 파이프라인이 Azure 리소스에 접근하려면 서비스 주체를 만들고 Secret이라고 불리는 비밀번호를 발급받아야 했다.

  • 방식: 아이디(App ID) + 비밀번호(Secret)를 Azure DevOps에 저장해두고 로그인하는 방식.

  • 문제점:

    • 비밀번호는 유효기간이 있어 주기적으로 갱신해야 한다(관리 부담).

    • 비밀번호가 유출되면 누구나 해당 권한을 사용할 수 있다(보안 위험).

1-2. 워크로드 아이덴티티 페더레이션 (OIDC 기반)

해당 방식은 비밀번호를 주고받는 것이 아니라 Azure DevOps을 신뢰하는 것이다.

이를 기술적으로 OIDC(OpenID Connect) 프로토콜을 사용해 구현한다.

  • 개념: Azure AD(Entra ID)에게 "나는 Azure DevOps라는 곳에서 발행한 토큰을 믿겠다"라고 설정하는 것. 이를 'Federation(연합) 관계를 맺는다'고 한다.

  • 작동 원리:

    1. Azure DevOps 파이프라인이 실행되면 Azure DevOps가 "이건 내가 보증하는 파이프라인이야"라는 토큰을 발행한다.

    2. 이 토큰을 Azure AD에 건넨다.

    3. Azure AD는 미리 설정된 페더레이션 자격 증명 정보(발급자, 대상 등)와 토큰을 대조한다

    4. 정보가 일치하면 비밀번호 없이도 접속을 허용한다.

  • 장점: Secret이 아예 존재하지 않으므로, 유출될 키가 없고, 만료일 관리도 필요 없다. (Passwordless)

2. 수동 설정의 번거로움과 Terraform으로 자동화

자동화 코드를 이해하기 위해서는 Azure AD와 Azure DevOps가 어떻게 OIDC(OpenID Connect)를 통해 인증하는지 그 흐름을 알아야 한다.

2-0. Azure와 DevOps 간의 신뢰 관계 (OIDC)

  • Azure AD (Entra ID):

    • Azure 리소스에 대한 접근 권한(IAM)을 관리하는 Identity Provider

    • Azure AD에서 앱 등록(Service Principal)을 생성해야 Azure 리소스에 접근할 수 있는 주체가 생긴다.

  • Azure DevOps:

    • CI/CD를 수행하는 플랫폼이다. 배포 작업을 수행할 때 Azure AD에게 인증을 받아야 한다.

  • Trust Relationship (신뢰 관계)

    • 기존에는 Secret을 주고받았음.

    • WIF (Workload Identity Federation) 방식에서는 "Azure DevOps의 특정 리포지토리/브랜치에서 발생한 토큰은 유효하다"라는 규칙인 Federated Credential을 Azure AD에 등록


2-1. 수동 설정 프로세스 (복잡함)

Tech Community 가이드에 따른 수동 설정은 두 플랫폼을 오가는 컨텍스트 스위칭이 발생한다.

  1. [Azure Portal] 앱 등록을 생성하여 Client ID, Tenant ID 확보.

  2. [Azure DevOps] 서비스 연결 생성 메뉴 진입 -> 'Workload Identity Federation (Manual)' 선택.

  3. [Azure DevOps] 화면에 생성된 Issuer URL과 Subject Identifier(주체 식별자) 문자열을 복사.

  4. [Azure Portal] 앱 등록 > 인증서 및 암호 > '페더레이션 자격 증명' 탭으로 이동하여 복사한 값 붙여넣기

  5. [Azure DevOps] 다시 돌아와서 연결 저장 및 검증

2-2. 자동화 전략

프레젠테이션에서는 Terraform의 Provider들을 조합하여 이 상호 의존적인 설정을 한 번에 처리한다.

핵심은 azuread 프로바이더로 Azure 측 설정을 하고, 생성된 정보를 azuredevops 프로바이더로 넘겨주는 것이다.

2-3. 자동화 코드 1: Azure AD 설정 (Entra ID)

Azure 리소스에 접근할 수 있는 논리적인 자격 증명 주체를 생성하는 단계이다.

  • App Registration 생성:

    • Azure API를 호출할 수 있는 애플리케이션 개체를 생성

  • Federated Credentials 설정:

    • Secret을 생성하는 대신 azuread_application_federated_identity_credential 리소스를 사용

    • repo:<조직>/<프로젝트>:ref:refs/heads/main과 같이 Azure DevOps가 발행할 토큰의 대상을 명시하여 Azure AD에 등록

    • 즉, "이 경로에서 오는 요청은 인증해라"라는 정책을 심는 과정


2-4. 자동화 코드 2: Azure DevOps 설정

Azure AD에 등록된 정보를 바탕으로, Azure DevOps 파이프라인이 사용할 연결 객체를 만든다.

  • Service Connection 생성:

    • azuredevops_serviceendpoint_azurerm 리소스를 생성한다.

    • 앞서 생성한 App Registration의 Application ID(Client ID)와 Tenant ID를 주입

    • service_endpoint_authentication_scheme 속성을 WorkloadIdentityFederation으로 설정하여, Secret 기반 인증이 아님을 명시

  • 권한 부여:

    • 생성된 서비스 연결을 파이프라인들이 승인 없이 사용할 수 있도록 azuredevops_resource_authorization 리소스를 통해 권한을 열어준다.

2-5. 자동화 코드 3: Azure 리소스 권한 부여 (RBAC)

인증은 2-3, 2-4에서 해결되었으나, 실제 리소스를 조작할 수 있는 권한은 별도로 부여해야 한다.

  • 구독 범위 권한:

    • Contributor: Terraform이 리소스 그룹, 네트워크 등을 생성/삭제하기 위한 필수 권한

    • User Access Administrator: Terraform이 배포 과정에서 또 다른 IAM 할당을 수행해야 할 경우 필요

  • 스토리지 계정(Storage Account):

    • Storage Blob Data Contributor

    • Terraform은 인프라의 현재 상태를 tfstate 파일로 관리하며, 해당 파일은 Azure Storage Blob에 저장된다.

    • 단순 Contributor 권한은 Control Plane 권한이므로, 실제 데이터인 Blob 파일을 읽고 쓰기 위해서는 Data Plane 권한인 이 역할이 반드시 필요하다.

3. WIF 서비스 연결을 이용한 테라폼 배포 방법

해당 방법을 통해 보안이 강화된(WIF 기반) 서비스 연결이 준비되었다.

이를 사용하여 실제 인프라(예: VM, VNet 등)를 배포하는 파이프라인을 구성할 때 지켜야 할 4가지 필수 조건이 있다.

  1. RBAC 권한 확인:

    • 사용할 서비스 주체(App)가 구독에 대한 Contributor 권한을 가지고 있어야 한다.

  2. 상태 파일 접근 권한:

    • 테라폼 백엔드로 사용할 스토리지 계정에 대해 Storage Blob Data Contributor 권한이 있어야 한다. (단순 Contributor로는 데이터 접근이 안 될 수 있음)

  3. 테라폼 태스크 버전 업데이트:

    • Azure DevOps 파이프라인(YAML)에서 사용하는 테라폼 태스크 버전을 TerraformTaskV4@4 (버전 4) 이상으로 사용해야 한다. (Microsoft가 WIF 지원을 위해 업데이트함).

  4. 환경 변수 설정 (가장 중요):

    • 테라폼이 시크릿 키를 찾지 않고 OIDC 토큰을 사용하도록 환경 변수를 명시해야 한다.

    • ARM_USE_OIDC = true 또는 AZURE_RM_USE_AZURE_AD = true

4. 정리

  • WIF 도입의 의의: 기존 Secret 기반 인증의 보안 취약점과 관리 부담을 해소하기 위해 OIDC 기반의 Workload Identity Federation을 도입하여 암호 없는 인증 체계를 구축한다.

  • 자동화의 효율성: Azure AD(신분증 발급)와 Azure DevOps(신분증 사용) 간의 복잡한 수동 연결 과정을 Terraform으로 일원화하여 설정 오류를 줄이고 배포 속도를 높인다.

  • 권한 분리의 중요성: 인증 설정 후에도 실제 인프라 제어(Contributor)와 상태 파일 관리(Storage Blob Data Contributor)를 위한 권한을 명확히 구분하여 할당해야 한다.

  • 실전 적용 포인트: 실제 파이프라인 적용 시에는 Terraform Task v4 이상 사용과 OIDC 환경 변수 활성화(ARM_USE_OIDC = true)가 필수적이다.


profile
고태규
이전 포스트

90DaysOfDevOps (Day 73)

다음 포스트

90DaysOfDevOps (Day 75)

0개의 댓글