Service Principal vs managed Identity

1. Managed Identity의 주요 ID 값

Managed Identity는 System-assigned (시스템 할당)과 User-assigned (사용자 할당) 두 가지 유형이 있으며, 각각 다음과 같은 ID 값을 가집니다.

ID	유형	예시
Principal ID	Managed Identity의 고유 식별자 (RBAC에서 사용)	37e96e2b-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Client ID	Managed Identity가 Azure AD에서 인증할 때 사용	5500b6f8-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Tenant ID	Managed Identity가 속한 Azure AD 테넌트의 ID	72f988bf-xxxx-xxxx-xxxx-xxxxxxxxxxxx

즉, Managed Identity도 "Client ID"와 "Principal ID"를 모두 가짐

• Principal ID: Managed Identity의 Azure AD 오브젝트 ID (RBAC 역할 할당 시 사용됨)
• Client ID: Managed Identity가 OAuth2 인증을 받을 때 사용되는 애플리케이션 ID

 2. Managed Identity의 ID 확인 방법

 1. Azure CLI를 사용하여 확인

Azure CLI를 사용하여 특정 리소스에 할당된 Managed Identity의 ID 값을 확인할 수 있습니다.

az identity show --name <ManagedIdentityName> --resource-group <ResourceGroup>

 

출력 예제

{ "clientId": "5500b6f8-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "id": "/subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<ManagedIdentityName>", "name": "<ManagedIdentityName>", "principalId": "37e96e2b-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "tenantId": "72f988bf-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "type": "Microsoft.ManagedIdentity/userAssignedIdentities" }

 여기서:

• "clientId": OAuth 2.0 인증에서 사용하는 Client ID
• "principalId": Azure RBAC에서 역할 할당 시 사용하는 Principal ID
• "tenantId": Managed Identity가 속한 Azure AD 테넌트 ID

---

 2. Azure Portal에서 확인

1. Azure Portal에 로그인합니다.
2. Managed Identity를 확인하려는 리소스(VM, App Service 등)로 이동합니다.
3. Identity 섹션으로 이동합니다.
4. System-assigned 또는 User-assigned 탭에서 Client ID와 Principal ID를 확인할 수 있습니다.

 

Managed Identity의 인증 방식

Managed Identity는 Client ID를 사용하여 OAuth 2.0을 통해 Azure AD에서 인증받습니다. 하지만 RBAC 역할을 부여할 때는 Principal ID를 사용합니다.

Managed Identity를 사용하여 Azure Key Vault 인증

from azure.identity import ManagedIdentityCredential
from azure.keyvault.secrets import SecretClient

# Managed Identity 인증 (Client ID 사용)
credential = ManagedIdentityCredential(client_id="5500b6f8-xxxx-xxxx-xxxx-xxxxxxxxxxxx")

# Azure Key Vault에 연결
key_vault_url = "https://<your-keyvault-name>.vault.azure.net"
client = SecretClient(vault_url=key_vault_url, credential=credential)

# Key Vault에서 비밀 값 가져오기
secret = client.get_secret("my-secret")
print(secret.value)

 

RBAC 역할 할당 시에는 Principal ID 사용

az role assignment create \ --assignee 37e96e2b-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ --role "Storage Blob Data Contributor" \ --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.S

---

3. 기존 방식: Service Principal + Client Secret

Azure에서 애플리케이션이 특정 리소스에 접근하려면, 보통 Service Principal(Azure AD에서 발급된 앱 계정)과 함께 Client ID와 Client Secret(또는 Certificate)을 사용했었다.

문제점

1. Client Secret 만료: Client Secret은 일정 기간 후 만료되므로, 이를 지속적으로 관리해야 함.
2. 보안 위험: Secret이 코드, 환경 변수 등에 저장되면 유출될 위험이 있음.
3. 관리 오버헤드: 조직에서 여러 개의 애플리케이션을 운영할 경우, Secret을 갱신하는 과정이 번거로움.

---

4. Managed Identity가 자동으로 인증을 관리하는 원리

Managed Identity를 사용하면 Azure가 자동으로 ID를 생성하고, 인증을 수행하며, Access Token을 갱신해줍니다.

(1) Managed Identity 인증 과정

 System-assigned Managed Identity 예제

• Azure VM이 Azure Storage에 접근해야 한다고 가정
• VM이 직접 인증 정보를 관리하지 않음
• Azure가 자동으로 Access Token을 관리하고, 인증을 수행

Step 1: MID 활성화

• Azure Portal 또는 CLI에서 Managed Identity를 활성화

 

az vm identity assign -g MyResourceGroup -n MyVM

• 이 명령어를 실행하면, 해당 VM에 대해 Azure AD에서 자동으로 ID가 생성됨.

Step 2: 애플리케이션에서 Access Token 요청 VM 내부에서 다음과 같은 명령어를 실행하면, Azure AD로부터 Access Token을 받을 수 있음.

curl -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?resource=https://storage.azure.com&api-version=2019-08-01"

이 호출을 하면, Azure가 자동으로 Access Token을 발급해줌.
응답 예시:

{ "access_token": "eyJ0eXA... (중략) ...", "expires_in": "3600", "resource": "https://storage.azure.com", "token_type": "Bearer" }

• access_token: Azure AD에서 발급한 인증 토큰
• expires_in: 3600초 (1시간 후 만료)
• token_type: Bearer (OAuth 2.0 표준 방식)

Step 3: Access Token을 사용하여 Azure Storage 접근 Access Token을 사용하여 Storage에 접근할 수 있음.

curl -H "Authorization: Bearer <access_token>" \ "https://myaccount.blob.core.windows.net/containername?restype=container&comp=list"

정리

1. 애플리케이션이 직접 Client ID/Secret을 관리하지 않아도 됨.
2. Access Token은 자동으로 발급 및 갱신됨 (기본적으로 1시간마다 만료됨).
3. Azure AD가 토큰의 유효성을 검사하고, 적절한 권한이 있는지 확인함.

---

5. 자동 토큰 갱신 원리

Access Token이 만료되면 어떻게 되나?

Access Token은 기본적으로 1시간 후 만료됩니다.
하지만, Managed Identity를 사용하면 애플리케이션이 직접 새 토큰을 요청할 필요가 없습니다.

 Azure의 자동 토큰 갱신 과정

1. 애플리케이션이 http://169.254.169.254/metadata/identity/oauth2/token 엔드포인트를 호출하면 Azure AD가 자동으로 새 Access Token을 발급.
2. 애플리케이션이 이 토큰을 사용하여 Azure Storage 등 리소스에 접근.
3. 토큰이 만료되기 전에 애플리케이션이 같은 요청을 다시 수행하면 새 토큰을 받을 수 있음.
4. Azure는 이 과정을 백그라운드에서 자동으로 처리.

즉, 애플리케이션 입장에서 보면 Access Token을 갱신하기 위한 추가적인 코드 작성이 필요 없음.
Azure가 자체적으로 ID를 유지하면서 토큰을 발급하고, 유효성을 관리하기 때문.

---

6. Managed Identity vs Service Principal 비교

기능	Managed Identity (MID)	기존 Service Principal
인증 방식	Azure AD가 자동으로 관리	Client ID + Secret 직접 관리
Secret 관리	불필요 (Azure가 처리)	필요 (Secret 갱신 필수)
토큰 갱신	자동으로 처리됨	애플리케이션이 직접 갱신해야 함
보안성	Secret 유출 가능성 없음	Secret이 유출될 가능성 있음

 

 

구분	Client ID	Principal ID
정의	Managed Identity의 애플리케이션 ID	Azure AD 내에서 오브젝트를 식별하는 ID
사용 목적	Azure AD 인증 (OAuth 2.0)	RBAC 역할 할당
사용 예시	ManagedIdentityCredential(client_id=client_id)	az role assignment create --assignee principal_id
예제 값	5500b6f8-xxxx-xxxx-xxxx-xxxxxxxxxxxx	37e96e2b-xxxx-xxxx-xxxx-xxxxxxxxxxxx

 

---

7. 결론

• Managed Identity는 Azure가 자동으로 ID를 관리하는 기능.
• Access Token은 Azure AD에서 발급되며, 자동으로 갱신됨.
• 애플리케이션에서 ID/Secret을 직접 저장하지 않고도 Azure 리소스에 접근 가능.
• 보안성이 뛰어나고, 관리 부담이 줄어듦.