Azure를 사용하여 클라우드 인프라를 운영하고 있으며, 이를 효율적으로 관리하고 보안을 강화하는 것이 중요합니다. 이 과정에서 Azure의 Service Principal은 필수적인 인증 방식으로 자리잡고 있습니다. 특히, CI/CD 파이프라인에서 Service Principal을 사용하면, 보안성과 관리 효율성을 극대화할 수 있습니다.
이 글에서는 Service Principal이 무엇인지, 왜 중요한지, 그리고 Azure 및 GitHub Actions와 같은 CI/CD 도구에서 어떻게 사용하는 것이 적절한지 구체적인 예시와 함께 설명해드리겠습니다. 이를 통해 Azure 리소스를 더욱 안전하게 관리하고, 일관된 인증 방식을 적용하는 방법을 알아보겠습니다.
보안 강화
- Service Principal은 Azure Active Directory(AAD)에서 제공하는 Azure 리소스에 대한 보안 관리 계정입니다. Service Principal을 사용하면 해당 계정에 대해 필요한 최소 권한만 부여할 수 있습니다.
- Access Key나 Admin 계정처럼 전체 리소스에 대한 권한을 부여하지 않고, 특정 리소스에만 권한을 할당할 수 있어 보안이 강화됩니다.
Service Principal을 통해 특정 Azure Container Registry(ACR)에만 읽기/쓰기 권한을 부여하는 방식
az role assignment create \
--assignee <SERVICE_PRINCIPAL_ID> \
--role Contributor \
--scope /subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.ContainerRegistry/registries/{acr-name}관리 편의성
- 서비스 프린시펄은 Azure AD에 의해 중앙에서 관리되며, 비밀번호나 비밀키(Client Secret)를 주기적으로 교체할 수 있습니다. 이를 통해 장기적인 키 관리가 가능하며, 보안 이벤트가 발생하면 즉시 액세스를 철회할 수 있습니다.
- 반면, Access Key나 Admin 계정을 사용할 경우 모든 리소스에 대해 권한을 부여하게 되며, 이를 교체하는 것이 복잡할 수 있습니다.
steps:
- name: 'Login to Azure Container Registry'
uses: azure/docker-login@v1
with:
login-server: ${{ secrets.AZURE_ACR_SERVER }}
client-id: ${{ secrets.AZURE_CLIENT_ID }}
client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}GitHub Actions에서 Client ID와 Client Secret을 사용해 ACR에 로그인하며, 서비스 프린시펄을 통한 안전한 인증 방식으로 관리됩니다. 이는 비밀 관리와 인증 방식을 일원화할 수 있어 관리 편의성이 높습니다.
역할 기반 액세스 제어 (RBAC) 지원
- Azure의 RBAC(Role-Based Access Control)를 통해 서비스 프린시펄은 역할(Role)을 부여받습니다. 이 역할은 특정 Azure 리소스에 대한 접근 권한을 세밀하게 제어할 수 있어, 불필요한 권한이 부여되는 것을 방지합니다.
- 예를 들어, 리더(Reader) 역할만 부여하면 읽기만 가능하게 할 수 있고, 컨트리뷰터(Contributor) 역할을 부여하면 읽기/쓰기 권한을 부여할 수 있습니다.
az role assignment create \
--assignee <SERVICE_PRINCIPAL_ID> \
--role Reader \
--scope /subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.ContainerRegistry/registries/{acr-name}Service Principal은 해당 리소스 그룹 내에서 ACR에 대해 읽기 권한만 가지게 됩니다.
감사 로그 및 모니터링
- 서비스 프린시펄을 사용하면 Azure AD를 통해 누가 언제 무엇을 했는지에 대한 감사 로그(Audit Log)를 남길 수 있습니다. 이를 통해 보안 감사나 이슈가 발생했을 때 빠르게 추적할 수 있습니다.
- 반면, Access Key는 특정 작업에 대한 로그를 남기기가 어렵고, 권한이 유출되면 누가 어떤 작업을 수행했는지 파악하기 힘듭니다.
Blob Storage와 ACR 모두 Service Principal을 통해 인증하여 관리하는 예시
steps:
- name: 'Az CLI login'
uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: 'Upload JAR to Blob Storage'
run: |
az storage blob upload \
--account-name ${{ secrets.AZURE_STORAGE_ACCOUNT }} \
--container-name ${{ secrets.AZURE_CONTAINER_NAME }} \
--file ./path-to-file.jar \
--name jarfile.jar
- name: 'Login to ACR'
uses: azure/docker-login@v1
with:
login-server: ${{ secrets.AZURE_ACR_SERVER }}
client-id: ${{ secrets.AZURE_CLIENT_ID }}
client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
Service Principal을 사용하면 보안, 관리 편의성, RBAC 지원, 감사 로그 및 모니터링, 일관된 인증 방식 등 여러 측면에서 이점이 있습니다. 이를 통해 Azure 리소스에 대한 접근을 세밀하게 제어하고, 안전하게 관리할 수 있습니다. GitHub Actions나 CI/CD 환경에서도 Service Principal을 사용해 일관성 있는 인증 체계를 적용하는 것이 바람직합니다.