일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- AZ-104
- POD
- AZURE
- 자바스크립트
- Deployment
- docker
- AZ-900
- IAM
- ebs
- EC2
- Service
- elasticsearch
- Role
- RBAC
- DevOps
- ansible
- K8S
- dockerfile
- Kubernetes
- FastAPI
- leetcode
- asyncio
- EKS
- terraform
- Python
- IAC
- AWS
- asgi
- Django
- Network
- Today
- Total
궁금한게 많은 개발자 노트
[ Azure ] Service Principal, Role, Action 본문
Azure의 Resource 권한 관리는 다른 CSP와 같이 Role기반으로 이루어지며 특정 리소스에 대한 접근은 해당 Identity에 Role이 부여되었는지 아닌지에 따라 결정됩니다.
아래 그림과 같이 각 리소스에 대한 Action을 선택하여 Action들의 집합인 Role을 생성할 수 있고, Service Principal에 필요한 Role을 부여하여 각 Identity에 서비스 주체(Service Principal)를 부여하는 방식으로 각 Identity가 접근 가능한 리소스에 대한 제어(RBAC)를 관리할 수 있습니다.


Security Principal에는 User, Group, Service Principal, Managed Identity가 있으며 User는 Azure의 사용자이고, 여러 사용자를 성격 별로 묶어 관리할 수 있는 개체가 Group이며 Application을 구분하는 Identity의 경우 Service Principal과 Managed Identity로 나눌 수 있는데 Service Principal은 Application이나 직접 hosting하는 서비스 그리고 Jenkins, Terraform과 같은 자동화 툴에 대한 Identity를 의미합니다. Managed Identity는 VM, App Service와 같이 Azure에서 제공하는 서비스에만 부여할 수 있는 특수한 Service Principal입니다. (즉, Managed Identity도 내부적으로는 Service Principal로 동작합니다)

또한 Security Principal에 어떤 Role을 부여하는지에 따라, 해당 Identity가 접근할 수 있는 리소스와 작업 권한이 결정됩니다.

Identity마다 어떤 Role이 부여되어 있는지, Scope는 어느 범위까지 적용되는지가 달라질 수 있습니다. Azure의 리소스는 관리 그룹 > 구독 > 리소스 그룹 > 리소스와 같은 구조를 갖게 되는데 상위 개체에 지정된 Role Assignment는 하위 개체에도 그대로 상속됩니다.
예를 들어 구독에 Owner Role을 할당 받은 사용자는 하위 개체인 리소스 그룹, 각 리소스에 대해서도 Owner Role을 갖게 됩니다.
위와 같은 대략적인 Azure의 RBAC관리 체계를 이해하여 적절한 권한을 갖고 운영할 수 있으면 좋을 것 같습니다. 감사합니다.
'DevOps' 카테고리의 다른 글
[ AZ-104 ] Entra ID, Domain Service (0) | 2025.01.18 |
---|---|
[ AZ-104 ] Azure Cloud Shell, PowerShell, JSON ARM (0) | 2025.01.17 |
Service Mesh, Istio란? (0) | 2025.01.14 |
Azure Fundamentals (AZ-900) 스토리지 (0) | 2025.01.08 |
Azure Fundamentals (AZ-900) - 클라우드 개념 (0) | 2025.01.06 |