IT/Azure

[Azure] AKS 생성

yskko 2021. 4. 9. 15:07

Azure API와 상호 작용을 하기 위해 AKS 클러스터에는 AD(Azure Active Directory) 서비스 주체 또는 관리 id가 필요하다.

Azure 부하분산 장치 또는 ACR(컨테이너 레지스트리)와 같은 다른 Azure리소스를 동적으로 만들고 관리하려면, 서비스 주체 또는 관리 id가 필요하다.

Azure AD 서비스 주체(service principal)를 만들려면 Azure AD 테넌트에 애플리케이션을 등록하고, 구독의 역할에 해당 Application을 할당할 수 있는 사용 권한이 있어야 한다. 필요한 사용 권한이 없다면, 사용권한을 할당하거나 AKS 클러스터로 사용하기 위한 서비스 주체를 미리 만들도록 Azure AD 또는 구독관리자에게 요청해야 한다.

다른 Azure AD 테넌트에서 서비스 주체를 사용하는 경우, 디렉터리 정보를 읽고 쓸 수 있는 권한이 필요하다. Azure CLI 버전 2.0.59 이상이 설치되고 구성되어야 한다.

Automatically create and use a service principal

Azure Portal 또는 az aks create 명령을 사용해 service principal을 자동으로 생성할 수 있다.

Azure CLI

az aks create --name myAKSCluster --resource-group myResourceGroup

Manualy create service principal

수동으로 service principal을 만들려면 az ad sp create-for-rbac 명령을 사용한다.

Azure CLI

az ad sp create-for-rbac --skip-assignment --name myAKSClusterServicePrincipal

다음 예제와 유사하게 출력된다. 사용자 고유의 appId 및 password를 기록해둬야 한다. 이 값은 AKS 클러스터를 만들 때 사용된다.

JSON

{
  "appId": "559513bd-0c19-4c1a-87cd-851a26afd5fc",
  "displayName": "myAKSClusterServicePrincipal",
  "name": "http://myAKSClusterServicePrincipal",
  "password": "e763725a-5eee-40e8-a466-dc88d980f415",
  "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db48"
}

AKS 클러스터에 대한 service principal 지정

az aks create 명령을 사용하여 AKS 클러스터를 만들 때 기존 service principal를 사용하려면 --service-principal 및 --client-secret 매개 변수를 사용하여 az ad sp create-for-rbac 명령의 출력에서 appId 및 password를 지정한다.
Azure CLI

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --service-principal <appId> \
    --client-secret <password>

Azure Portal을 사용하여 AKS 클러스터를 배포하는 경우 Kubernetes 클러스터 만들기 대화 상자의 _인증_페이지에서 service principal를 구성하도록 선택한다. 기존 항목 사용을 선택하고 다음을 지정한다.

service principal client ID는 사용자의 appID
service principal client password는 password

다른 Azure 리소스에 대한 액세스 권한 위임

AKS 클러스터에 대한 service principal를 사용하여 다른 리소스에 액세스할 수 있다. 기존 Azure 가상 네트워크 서브넷에 AKS 클러스터를 배포하거나 ACR(Azure Container Registry)에 연결하려는 경우 해당 리소스에 대한 액세스 권한을 위임해야 한다.

권한을 위임하려면 az role assignment create 커맨드를 사용한다. resource group이나 virtual network에 appID를 할당한다. 그러면 role은 service principal이 리소스에 가진 사용 권한을 정의한다.

Azure CLI

az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor

Azure Container Registry

Container imange repository로 ACR(Azure Container Registry)를 사용 하는 경우 이미지를 읽고 가져오도록 AKS 클러스터에 대한 service principal에게 사용 권한을 부여해야 한다.

Networking

가상 네트워크와 서브넷 또는 공용 IP 주소가 다른 리소스 그룹에 있는 고급 네트워킹을 사용할 수 있다. 가상 네트워크 내의 서브넷에서 네트워크 기여자 기본 제공 역할을 할당한다.

Storage

다른 리소스 그룹에 있는 리소스에 액세스해야 할 수 있다.

사용자 지정 역할을 만들고 역할 권한을 정의한다.
- Microsoft.Compute/disks/read
- Microsoft.Compute/disks/write
또는 리소스 그룹에 Storage 계정 기여자 기본 제공 역할을 할당한다.

Azure Container Instances

Virtual Kubelet을 사용하여 AKS와 통합하고 AKS 클러스터와 별도로 리소스 그룹에서 ACI(Azure Container Instances)를 실행하도록 선택하는 경우, AKS 서비스 주체에 ACI 리소스 그룹에 대한 ‘Contributor’ 권한을 부여해야 한다.

기타 고려 사항

Kubernetes에 대한 서비스 주체는 클러스터 구성의 일부이다. 그러나 클러스터를 배포하는 데에는 이 ID를 사용하면 안된다.
Service principal은 1년 동안 유효 하다. 언제든 자격 증명을 업데이트 할 수 있다.
모든 service principal는 Azure AD 애플리케이션과 연결된다.
Kubernetes 클러스터의 서비스 주체를 유효한 Azure AD 응용 프로그램 이름에 연결할 수 있다.
서비스 주체 클라이언트 ID 를 지정할 때 appId 값을 사용한다.
Kubernetes 클러스터의 에이전트 노드 Vm에서 서비스 주체 자격 증명은 파일에 저장 된다. /etc/kubernetes/azure.json
az aks create 명령을 사용하여 서비스 주체를 자동으로 생성하는 경우, 서비스 주체 자격 증명은 명령을 실행하는 데 사용되는 머신의 ~/.azure/aksServicePrincipal.json 파일에 기록된다.
AKS CLI 명령에서 서비스 주체를 특별히 전달 하지 않으면, 서비스 주체가 ~/.azure/aksServicePrincipal.json 사용 된다.
필요에 따라 파일에서 aksServicePrincipal.js를 제거 하 고 AKS에서 새 서비스 주체를 만들 수도 있다.
az aks create로 만든 AKS 클러스터를 삭제하는 경우 자동으로 생성된 서비스 주체는 삭제되지 않는다.
service principal을 삭제하려면 클러스터 servicePrincipalProfile를 쿼리한 다음, az ad sp delete를 사용하여 삭제한다.
Azure CLI
```
az ad sp delete --id $(az aks show -g myResourceGroup -n myAKSCluster --query servicePrincipalProfile.clientId -o tsv)
```