AZ-400 시험에서 인증과 시크릿 관리 파트는 '파이프라인이 Azure 리소스에 어떻게 신원을 증명하는가'를 반복적으로 묻습니다. 오래된 방식은 단순했습니다. 비밀번호처럼 생긴 클라이언트 시크릿을 GitHub Secrets나 파이프라인 변수에 저장해두고 꺼내 쓰는 것이었습니다. 문제는 그 시크릿이 외부 시스템에 존재하는 한 언제든 노출될 수 있다는 점이었습니다. 이 글은 그 위험을 없애는 세 가지 방법인 Managed Identity, Workload Identity Federation(OIDC), Azure Key Vault를 시나리오와 함께 정리합니다.
사원증 vs 방문증 — Service Principal과 Managed Identity 고르기
회사에 처음 입사한 신입 사원은 정식 사원증을 받습니다. 유효 기간이 있고, 만료되면 재발급 신청을 해야 합니다. 반면 사내 복합기는 아무도 신청한 적 없는데도 네트워크 드라이브에 접근합니다. 건물 인프라가 그 권한을 자동으로 관리하기 때문입니다. Service Principal은 사원증, Managed Identity는 건물이 직접 발급하고 관리하는 장비 인증 카드에 해당합니다.
Service Principal은 Microsoft Entra ID에 등록된 비대화형 ID입니다. Azure VM, 온프레미스 서버, GitHub Actions 러너 등 어느 환경에서도 동작합니다. 단점은 클라이언트 시크릿을 주기적으로 갱신해야 한다는 것입니다. 갱신을 놓치면 자정에 파이프라인이 조용히 실패합니다.
Managed Identity는 Azure 플랫폼이 직접 생성·갱신·폐기합니다. 코드에 자격 증명이 전혀 없어도 Azure 리소스에 인증할 수 있습니다. 두 가지 유형이 있습니다.
Managed Identity는 특정 Azure 리소스(VM, App Service 등)에 직접 결합됩니다. 리소스가 삭제되면 함께 사라집니다.
Managed Identity는 독립 리소스로 만들어지며 여러 VM·App Service·AKS 파드에 동시에 할당할 수 있습니다. '여러 리소스가 동일한 ID를 공유해야 한다'는 조건이 보이면 user-assigned를 선택합니다.
| 상황 | 선택 | |------|------| | Azure 외부 환경에서 Azure 접근 | Service Principal | | Azure 리소스 단독 사용 | System-assigned Managed Identity | | 여러 리소스가 동일 ID 공유 | User-assigned Managed Identity |
!Service Principal vs Managed Identity
자물쇠 없는 금고 — Workload Identity Federation과 OIDC
은행 금고에 열쇠 없이 들어가는 방법이 있다면 어떨까요? 정확한 얼굴 인식과 보안팀의 실시간 승인으로 열쇠 자체를 없애는 방식입니다. Workload Identity Federation은 바로 그 개념입니다. 클라이언트 시크릿이라는 열쇠를 아예 없애고, OIDC 토큰이라는 신원 확인서로 교체합니다.
GitHub Actions나 Azure Pipelines가 실행되면, 플랫폼은 서명된 OIDC 토큰을 자동으로 발급합니다. 이 JWT 안에는 리포지토리 이름·브랜치·조직·워크플로 컨텍스트가 담겨 있습니다. 파이프라인은 이 토큰을 Azure STS에 제출하고, Azure는 사전 설정된 의 issuer·subject 클레임이 일치하는지 검증한 뒤 Access Token을 발급합니다. 이 과정 어디에도 클라이언트 시크릿은 존재하지 않습니다.
GitHub Actions 설정 순서: Microsoft Entra ID에서 App registration 생성 Federated Identity Credential 추가 — Issuer: , Subject: Service Principal에 Azure RBAC 역할 부여 GitHub Secrets에 Client ID·Tenant ID·Subscription ID만 저장 (시크릿 값 없음) 워크플로에서 액션에 세 값 전달
Azure Pipelines는 Service Connection 생성 시 Workload Identity Federation을 선택하면 Federated Identity Credential 등록을 자동으로 처리합니다.
시험 포인트: Subject 클레임과 실제 실행 브랜치가 불일치하는 것이 OIDC 인증 실패의 가장 흔한 원인입니다.
은행 금고의 세 칸 — Key Vault Secret, Key, Certificate
은행 금고에는 현금을 넣는 칸, 중요 서류를 봉인하는 칸, 도장과 인감을 관리하는 칸이 따로 있습니다. Azure Key Vault도 용도별로 세 가지 객체를 구분합니다.
은 임의의 문자열입니다. 데이터베이스 연결 문자열, API 키, 비밀번호가 여기에 속합니다. 파이프라인에서 가장 많이 사용하는 유형입니다.
는 RSA 또는 EC 비대칭 키입니다. 암호화·복호화·서명·서명 검증에 사용합니다. HSM 보호 키는 Key Vault 외부로 내보내지지 않으므로 키 자체가 노출될 위험이 없습니다.
는 X.509 TLS/SSL 인증서입니다. 생성·갱신·자동 순환을 지원합니다. TLS 인증서나 mTLS 인증서를 관리해야 한다면 Certificate를 선택합니다.
접근 제어 모델
는 Key Vault 고유의 권한 시스템입니다. ID별로 Get·List·Set·Delete 등 세부 작업을 개별 지정하며, Azure RBAC와 독립적으로 동작합니다.
는 2023년부터 신규 Key Vault의 기본 모델입니다. Microsoft Entra ID와 완전 통합되며 다른 Azure 리소스와 동일한 IAM 인터페이스를 사용합니다. 주요 역할: (Secret 읽기), (읽기+쓰기), (전체 관리).
ARM 템플릿에서 Key Vault Secret을 참조하려면 Key Vault에서 를 활성화해야 합니다. 신규 Key Vault에서는 기본적으로 비활성화되어 있어 이 설정 없이 배포하면 즉시 실패합니다.
창고 관리 대장 — 파이프라인 시크릿 통합
물류 창고에서는 어떤 물건이 어디에 있는지 한 장의 대장으로 관리합니다. 파이프라인 시크릿도 마찬가지입니다. 개별 파이프라인마다 시크릿을 따로 관리하면 갱신 누락·불일치가 쌓입니다. Variable Group은 그 대장 역할을 합니다.
Azure Pipelines Variable Group을 Key Vault에 연결하면, 파이프라인 YAML에는 변수 그룹 이름만 남고 시크릿 값은 실행 시점에 Key Vault에서 동적으로 조회됩니다. 동일 프로젝트의 여러 파이프라인이 같은 그룹을 재사용하며, Key Vault에서 Secret이 갱신되면 다음 실행부터 즉시 반영됩니다.
GitHub Actions에서는 로 배포 환경별 시크릿을 분리합니다. Environment Secrets는 해당 환경이 활성화된 잡에서만 접근 가능하며, 필수 검토자·대기 시간·IP 제한 같은 보호 규칙과 결합하면 프로덕션 배포 게이팅이 구현됩니다.
Azure Pipelines의 은 외부 시스템(Azure 구독, GitHub, Docker 레지스트리 등)에 인증하는 구성 단위입니다. 권한 계층: Reader → User → Creator → Administrator. 파이프라인 실행에는 User 권한으로 충분하고, 편집·삭제·공유에는 Administrator가 필요합니다.
시험 핵심 정리
'클라이언트 시크릿 없이 Azure 인증' -- Workload Identity Federation (OIDC) '여러 Azure 리소스가 동일 ID 공유' -- User-assigned Managed Identity 'Azure VM·App Service가 자격 증명 없이 Key Vault 접근' -- System-assigned Managed Identity 'GitHub Actions → Azure 배포 + secretless' -- Workload Identity Federation 'OIDC 인증 실패 원인' -- Subject 클레임과 실제 브랜치 불일치 'Key Vault 연결 문자열·API 키 저장' -- Secret 'Key Vault 암호화·서명 키 저장' -- Key 'Key Vault TLS 인증서 저장' -- Certificate 'ARM 배포 시 Key Vault Secret 참조 실패' -- Enable for template deployment 비활성화 '여러 파이프라인에서 Key Vault Secret 공유' -- Variable Group linked to Key Vault 'Microsoft Entra ID 통합 + 표준 Azure 권한 모델' -- Azure RBAC (Key Vault) '파이프라인 실행 시 Service Connection 최소 권한' -- User