설명
AKS가 Azure 리소스에 접근할 때 서비스 주체를 사용하면 해당 자격 증명의 보호와 회전을 직접 관리해야 합니다. 관리 ID는 Azure가 자격 증명을 관리하므로 이 부담을 줄이지만, 필요한 권한만 부여하는 작업은 여전히 필요합니다.
잠재적 영향
- 서비스 주체 비밀정보의 유출이나 회전 누락이 리소스 접근과 서비스 운영에 영향을 줄 수 있습니다.
- 클러스터와 kubelet에 과도한 역할을 부여하면 관리 ID를 사용해도 피해 범위가 커질 수 있습니다.
해결 방법
- 사용 목적에 맞는
identity블록을 설정하고 SystemAssigned 또는 승인된 UserAssigned ID를 선택하세요. 클러스터와 kubelet ID의 Azure RBAC 역할을 각각 최소화하세요. - 서비스 주체에서 전환할 때 리소스 권한과 노드 풀 전환 절차를 확인하세요. 새 ID로 실제 작업이 동작하는지 확인한 뒤 더 이상 사용하지 않는 자격 증명을 정리하세요.
예시
ID 설정의 일부를 비교합니다. 변경 전에는 관리 ID와 서비스 주체가 모두 생략되어 있어 완전한 배포 구성이 아닙니다. AzureRM은 둘 중 하나를 요구합니다.
변경 전
hcl
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
dns_prefix = "exampleaks"
default_node_pool {
name = "default"
node_count = 1
vm_size = "Standard_D2_v2"
}
}
변경 후
hcl
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
dns_prefix = "exampleaks"
default_node_pool {
name = "default"
node_count = 1
vm_size = "Standard_D2_v2"
}
identity {
type = "SystemAssigned"
}
}
설명:
- 변경 전: 클러스터 인증 ID가 이 발췌에 정의되지 않았습니다.
- 변경 후: 시스템 할당 관리 ID를 선택합니다. 리소스 접근에 필요한 역할은 별도로 부여해야 합니다.