AKS(Azure Kubernetes Service)의 인증 및 권한 부여 모범 사례

  • 아티클

AKS(Azure Kubernetes Service)에서 클러스터를 배포 및 유지 관리하는 경우 리소스 및 서비스에 대한 액세스를 관리하는 방법을 구현합니다. 이러한 컨트롤이 없으면 다음을 수행합니다.

  • 계정이 불필요한 리소스 및 서비스에 액세스할 수 있습니다.
  • 변경을 수행하는 데 사용된 자격 증명을 추적하는 것이 어려울 수 있습니다.

이 문서에서는 클러스터 운영자가 AKS 클러스터에 대한 액세스 및 ID를 관리하기 위해 따를 수 있는 권장 사례에 대해 설명합니다. 이 문서에서 배울 내용은 다음과 같습니다.

  • Microsoft Entra ID를 사용하여 AKS 클러스터 사용자를 인증합니다.
  • Kubernetes RBAC(Kubernetes 역할 기반 액세스 제어)를 사용하여 리소스에 대한 액세스를 제어합니다.
  • Azure RBAC를 사용하여 AKS 리소스, 대규모 Kubernetes API 및 kubeconfig에 대한 액세스를 세부적으로 제어합니다.
  • 워크로드 ID를 사용하여 Pod에서 Azure 리소스에 액세스합니다.

Warning

Azure Kubernetes Service의 오픈 소스 Microsoft Entra Pod 관리 ID(미리 보기)는 2022년 10월 24일 현재 더 이상 사용되지 않습니다.

AKS 클러스터에서 Microsoft Entra Pod 관리 ID를 사용하도록 설정했거나 구현을 고려 중인 경우 워크로드 ID 개요 문서를 검토하여 Microsoft Entra 워크로드 ID(미리 보기)를 사용하도록 클러스터를 설정하는 권장 사항 및 옵션을 이해하는 것이 좋습니다. 이 인증 방법은 Kubernetes 네이티브 기능과 통합되어 외부 ID 공급자와 페더레이션하는 Pod 관리 ID(미리 보기)를 대체합니다.

Microsoft Entra ID 사용

모범 사례 지침

Microsoft Entra 통합을 사용하여 AKS 클러스터를 배포합니다. Microsoft Entra ID를 사용하면 ID 관리 계층이 중앙 집중화됩니다. 사용자 계정 또는 그룹 상태의 변경 내용은 AKS 클러스터에 액세스할 때 자동으로 업데이트됩니다. 역할, ClusterRoles 또는 바인딩을 사용하여 사용자 또는 그룹의 범위를 최소 사용 권한 크기로 지정합니다.

Kubernetes 클러스터 개발자 및 애플리케이션 소유자는 다른 리소스에 액세스해야 합니다. Kubernetes에는 사용자가 상호 작용할 수 있는 리소스를 제어할 수 있는 ID 관리 솔루션이 없습니다. 대신 엔터프라이즈 지원 ID 관리 솔루션인 Microsoft Entra ID와 같은 기존 ID 솔루션과 클러스터를 통합할 수 있습니다.

AKS에서 Microsoft Entra 통합 클러스터를 사용하면 리소스에 대한 액세스 권한을 정의하는 역할 또는 ClusterRoles를 만듭니다. 그런 다음 Microsoft Entra ID의 사용자 또는 그룹에 역할을 바인딩 합니다. 다음 섹션에서 이러한 Kubernetes RBAC에 대해 자세히 알아봅니다. Microsoft Entra 통합 및 리소스에 대한 액세스를 제어하는 방법은 다음 다이어그램에서 확인할 수 있습니다.

Cluster-level authentication for Microsoft Entra integration with AKS

  1. 개발자는 Microsoft Entra ID를 사용하여 인증합니다.
  2. Microsoft Entra 토큰 발급 엔드포인트는 액세스 토큰을 발급합니다.
  3. 개발자는 Microsoft Entra 토큰(예: kubectl create pod.)을 사용하여 작업을 수행합니다.
  4. Kubernetes는 Microsoft Entra ID를 사용하여 토큰의 유효성을 검사하고 개발자의 그룹 멤버 자격을 가져옵니다.
  5. Kubernetes RBAC 및 클러스터 정책이 적용됩니다.
  6. 개발자의 요청은 Microsoft Entra 그룹 멤버 자격 및 Kubernetes RBAC 및 정책의 이전 유효성 검사에 따라 성공합니다.

Microsoft Entra ID를 사용하는 AKS 클러스터를 만들려면 AKS와 Microsoft Entra ID 통합을 참조하세요.

Kubernetes 역할 기반 액세스 제어 사용(Kubernetes RBAC)

모범 사례 지침

Kubernetes RBAC를 사용하여 클러스터 리소스에 대한 사용자 또는 그룹 권한을 정의합니다. 필요한 최소 사용 권한을 할당하는 역할 및 바인딩을 만듭니다. Microsoft Entra ID와 통합하여 사용자 상태 또는 그룹 멤버 자격 변경을 자동으로 업데이트하고 클러스터 리소스에 대한 액세스를 최신 상태로 유지합니다.

Kubernetes에서는 클러스터 리소스에 대한 세분화된 액세스 제어를 제공합니다. 클러스터 수준 또는 특정 네임스페이스에 대한 권한을 정의합니다. 관리할 수 있는 리소스와 사용 권한을 결정합니다. 그런 다음 바인딩이 있는 사용자 또는 그룹에 이러한 역할을 적용합니다. Role, ClusterRole 및 Binding에 대한 자세한 내용은 AKS(Azure Kubernetes Service)의 액세스 및 ID 옵션을 참조하세요.

예를 들어, 다음 예제 YAML 매니페스트와 같이 finance-app이라는 네임스페이스에서 리소스에 대한 전체 액세스 권한을 부여하는 역할을 만듭니다.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

그런 다음 다음 YAML 매니페스트와 같이 RoleBinding을 만들고 Microsoft Entra 사용자를 developer1@contoso.com 바인딩합니다.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

developer1@contoso.com AKS 클러스터에 대해 인증되면 재무 앱 네임스페이스의 리소스에 대한 모든 권한이 있습니다. 이러한 방식으로 리소스에 대한 액세스를 논리적으로 분리하고 제어합니다. Microsoft Entra ID 통합과 함께 Kubernetes RBAC를 사용합니다.

Microsoft Entra 그룹을 사용하여 Kubernetes RBAC를 사용하여 Kubernetes 리소스에 대한 액세스를 제어하는 방법을 알아보려면 AKS에서 역할 기반 액세스 제어 및 Microsoft Entra ID를 사용하여 클러스터 리소스에 대한 액세스 제어를 참조하세요.

Azure RBAC 사용

모범 사례 지침

Azure RBAC를 사용하여 하나 이상의 구독에서 AKS 리소스에 대해 필요한 최소 사용자 및 그룹 권한을 정의합니다.

AKS 클러스터를 완전히 운영하려면 다음과 같이 두 가지 수준의 액세스가 필요합니다.

  • Azure 구독에서 AKS 리소스에 액세스.

    이 액세스 수준을 사용하면 다음을 수행할 수 있습니다.

    • AKS API를 사용하여 클러스터 크기 조정 또는 업그레이드 제어
    • 끌어오세요 kubeconfig.

    AKS 리소스 및 kubeconfig에 대한 액세스를 제어하는 방법은 클러스터 구성 파일에 대한 액세스 제한을 참조하세요.

  • Kubernetes API에 대한 액세스.

    이 액세스 수준은 다음을 통해 제어됩니다.

    • Kubernetes RBAC(일반적) 또는
    • Kubernetes 권한 부여를 위해 AKS와 Azure RBAC를 통합합니다.

    Azure RBAC를 사용하여 Kubernetes API에 권한을 세부적으로 부여하는 방법은 Kubernetes 인증에 Azure RBAC 사용을 참조하세요.

Pod 관리 ID 사용

Warning

Azure Kubernetes Service의 오픈 소스 Microsoft Entra Pod 관리 ID(미리 보기)는 2022년 10월 24일 현재 더 이상 사용되지 않습니다.

AKS 클러스터에서 Microsoft Entra Pod 관리 ID를 사용하도록 설정했거나 구현을 고려 중인 경우 워크로드 ID 개요 문서를 검토하여 Microsoft Entra 워크로드 ID(미리 보기)를 사용하도록 클러스터를 설정하는 권장 사항 및 옵션을 이해하는 것이 좋습니다. 이 인증 방법은 Kubernetes 네이티브 기능과 통합되어 외부 ID 공급자와 페더레이션하는 Pod 관리 ID(미리 보기)를 대체합니다.

노출 또는 남용의 위험이 있으므로 Pod 또는 컨테이너 이미지 내에서 고정 자격 증명을 사용하지 마세요. 대신 Pod ID를 사용하여 Microsoft Entra ID를 사용하여 액세스를 자동으로 요청합니다 .

Azure Cosmos DB, Key Vault 또는 Blob Storage 등의 다른 Azure 리소스에 액세스하려면 Pod에 인증 자격 증명이 필요합니다. 컨테이너 이미지로 인증 자격 증명을 정의하거나 Kubernetes 비밀로 삽입할 수 있습니다. 어느 쪽이든 수동으로 만들고 할당해야 합니다. 일반적으로 이러한 자격 증명은 Pod에서 다시 사용되며 정기적으로 회전되지 않습니다.

Azure 리소스에 대한 Pod 관리 ID(미리 보기)를 사용하면 Microsoft Entra ID를 통해 서비스에 대한 액세스를 자동으로 요청합니다. Pod 관리 ID는 현재 AKS에 대해 미리 보기로 제공됩니다. 시작하려면 Azure Kubernetes Service(미리 보기) 설명서에서 Microsoft Entra Pod 관리 ID 사용을 참조하세요.

Microsoft Entra Pod 관리 ID(미리 보기)는 두 가지 작업 모드를 지원합니다.

  • 표준 모드: 이 모드에서는 다음 두 구성 요소가 AKS 클러스터에 배포됩니다.

    • MIC(관리 ID 컨트롤러): Kubernetes API 서버를 통해 Pod, AzureIdentity 및 AzureIdentityBinding에 대한 변경 내용을 감시하는 Kubernetes 컨트롤러입니다. 관련 변경 내용이 감지되면 MIC는 필요에 따라 AzureAssignedIdentity를 추가하거나 삭제합니다. 특히 Pod가 예약되면 MIC는 만들기 단계 중 노드 풀에서 사용하는 기본 VMSS에 Azure의 관리 ID를 할당합니다. ID를 사용하는 모든 Pod가 삭제되면 동일한 관리 ID가 다른 Pod에서 사용되지 않는 한 노드 풀의 VMSS에서 ID를 제거합니다. MIC는 AzureIdentity 또는 AzureIdentityBinding을 만들거나 삭제할 때도 유사한 작업을 수행합니다.

    • NMI(노드 관리 ID): AKS 클러스터의 각 노드에서 DaemonSet으로 실행되는 Pod입니다. NMI는 각 노드의 Azure Instance Metadata Service에 대한 보안 토큰 요청을 가로챌 수 있습니다. 요청 자체를 리디렉션하고 Pod가 토큰을 요청하는 ID에 액세스할 수 있는지 확인하고 애플리케이션을 대신하여 Microsoft Entra 테넌트에서 토큰을 가져옵니다.

  • 관리형 모드: 이 모드에는 NMI만 있습니다. 사용자가 ID를 수동으로 할당하고 관리해야 합니다. 자세한 내용은 관리형 모드의 Pod ID를 참조하세요. 이 모드에서 az aks pod-identity add 명령을 사용하여 Azure Kubernetes Service(AKS) 클러스터에 Pod ID를 추가하면 --namespace 매개 변수로 지정된 네임스페이스에 AzureIdentity 및 AzureIdentityBinding을 만들고 AKS 리소스 공급자는 --identity-resource-id 매개 변수로 지정된 관리 ID를 AKS 클러스터에서 각 노드 풀의 가상 머신 확장 집합에 할당합니다.

참고 항목

AKS 클러스터 추가 기능을 사용하여 Microsoft Entra Pod 관리 ID를 설치하기로 결정한 경우 설치 프로그램에서 이 모드를 managed 사용합니다.

이 모드는 managed 다음과 같은 이점을 제공합니다.standard

  • 노드 풀의 가상 머신 확장 집합에서 ID를 할당하려면 40~60초 걸릴 수 있습니다. ID에 대한 액세스 권한이 필요하고 할당 지연을 허용할 수 없는 애플리케이션이나 cronjobs의 경우 ID가 노드 풀의 가상 머신 확장 집합에 미리 할당되는 managed 모드를 사용하는 것이 가장 좋습니다. 수동으로 또는 az aks pod-identity add 명령을 사용합니다.
  • standard 모드에서 MIC에는 AKS 클러스터에서 사용하는 가상 머신 확장 집합에 대한 쓰기 권한과 사용자가 할당한 관리 ID에 대한 Managed Identity Operator 권한이 필요합니다. managed mode에서 실행하는 경우 MIC가 없으므로 역할 할당이 필요하지 않습니다.

Pod에 대한 자격 증명을 수동으로 정의하는 대신 Pod 관리 ID는 실시간으로 액세스 토큰을 요청하여 할당된 리소스에만 액세스합니다. AKS에는 Pod가 관리 ID를 사용할 수 있도록 작업을 처리하는 두 가지 구성 요소가 있습니다.

  • NMI(노드 관리 ID) 서버는 AKS 클러스터의 각 노드에서 DaemonSet으로 실행되는 Pod입니다. NMI 서버는 Azure 서비스에 대한 Pod 요청을 수신 대기합니다.
  • Azure 리소스 공급자는 Kubernetes API 서버를 쿼리하고 Pod에 해당하는 Azure ID 매핑을 검사.

Pod가 Azure 리소스에 액세스하기 위해 Microsoft Entra ID에서 보안 토큰을 요청하는 경우 네트워크 규칙은 트래픽을 NMI 서버로 리디렉션합니다.

  1. NMI 서버:

    • 원격 주소를 기반으로 Azure 리소스에 대한 액세스를 요청하는 Pod를 식별합니다.
    • Azure 리소스 공급자를 쿼리합니다.

  2. Azure 리소스 공급자는 AKS 클러스터의 Azure ID 매핑에 대한 검사.

  3. NMI 서버는 Pod의 ID 매핑에 따라 Microsoft Entra ID에서 액세스 토큰을 요청합니다.

  4. Microsoft Entra ID는 Pod에 반환되는 NMI 서버에 대한 액세스를 제공합니다.

    • 이 액세스 토큰은 이후 Pod가 Azure의 리소스에 대한 액세스를 요청하는 데 사용할 수 있습니다.

다음 예제에서 개발자는 관리 ID를 사용하여 Azure SQL Database에 대한 액세스를 요청하는 Pod를 만듭니다.

Pod identities allow a pod to automatically request access to other resources.

  1. 클러스터 운영자는 Pod가 리소스에 대한 액세스를 요청할 때 ID를 매핑하는 서비스 계정을 만듭니다.
  2. NMI 서버는 Microsoft Entra ID에 대한 액세스 토큰을 위해 Azure 리소스 공급자와 함께 모든 Pod 요청을 릴레이하기 위해 배포됩니다.
  3. 개발자는 NMI 서버를 통해 액세스 토큰을 요청하는 관리 ID가 있는 Pod를 배포합니다.
  4. 토큰은 Pod에 반환되고 Azure SQL Database에 액세스하는 데 사용됩니다.

Pod 관리 ID를 사용하려면 Azure Kubernetes Service(미리 보기)에서 Microsoft Entra Pod 관리 ID 사용을 참조하세요.

다음 단계

이 모범 사례 문서는 클러스터 및 리소스에 대한 인증 및 권한 부여에 초점을 맞췄습니다. 이러한 모범 사례 중 일부를 구현하려면 다음 문서를 참조하세요.

AKS의 클러스터 작업에 대한 자세한 내용은 다음 모범 사례를 참조하세요.