AKS(Azure Kubernetes Services)의 클러스터 보안 및 업그레이드 모범 사례

적용 대상: ✔️ AKS 자동 ✔️ AKS 표준

AKS(Azure Kubernetes Service)에서 클러스터를 관리할 때 워크로드 및 데이터 보안이 주요 고려 사항입니다. 논리적 격리를 사용하여 다중 테넌트 클러스터를 실행하는 경우 특히 리소스 및 워크로드 액세스를 보호해야 합니다. 최신 Kubernetes 및 노드 OS 보안 업데이트를 적용하여 공격 위험을 최소화합니다.

이 문서에서는 AKS 클러스터의 보안을 유지하는 방법을 중점적으로 설명합니다. 다음 방법을 알아봅니다:

컨테이너 이미지 관리 및 Pod 보안에 대한 모범 사례를 참조할 수도 있습니다.

AKS 클러스터 모드 보안 책임

AKS는 AKS 자동 및 AKS 표준의 두 가지 클러스터 모드를 지원합니다. 보안 목표는 두 모드 모두에서 동일하지만 구현 책임은 다릅니다.

AKS Automatic에는 지원되는 구성에서 더 많은 사전 구성된 제어 기능이 포함된 강화된 기본 구성이 포함되어 있습니다. AKS Standard는 보다 광범위한 직접 구성 제어를 제공하여 기준 설정 및 진행 중인 작업에 대한 운영자의 책임을 증가합니다.

위협 방지 사용

모범 사례 지침

컨테이너용 Defender를 사용하도록 설정하여 컨테이너를 보호할 수 있습니다. 컨테이너용 Defender는 클러스터 구성을 평가하고 보안 권장 사항을 제공하고 취약성 검사를 실행하고 Kubernetes 노드 및 클러스터에 대한 실시간 보호 및 경고를 제공할 수 있습니다.

이 지침은 두 모드 모두에 적용됩니다. AKS Automatic이 미리 구성된 보안 기본값을 제공하는 경우에도 위협 방지 온보딩 및 경고 응답 워크플로는 팀의 운영 책임으로 유지됩니다.

API 서버 및 클러스터 노드에 대한 액세스 보안 유지

모범 사례 지침

클러스터를 보호하는 가장 중요한 방법 중 하나는 Kubernetes API 서버에 대한 액세스를 보호하는 것입니다. API 서버에 대한 액세스를 제어하려면 Kubernetes RBAC를 Microsoft Entra ID와 통합합니다. 이러한 제어를 통해 Azure 구독에 대한 액세스를 보호하는 것과 동일한 방식으로 AKS를 보호할 수 있습니다.

Kubernetes API 서버는 클러스터 내의 작업 수행 요청에 대한 단일 연결점을 제공합니다. API 서버에 대한 액세스를 보호하고 감사하려면 액세스를 제한하고 가능한 가장 낮은 권한 수준을 제공합니다. 이 방식이 Kubernetes에만 해당하는 것은 아니지만 다중 테넌트 사용을 위해 AKS 클러스터를 논리적으로 격리한 경우에 특히 중요합니다.

Microsoft Entra ID는 AKS 클러스터와 통합되는 엔터프라이즈급 ID 관리 솔루션을 제공합니다. Kubernetes는 ID 관리 솔루션을 제공하지 않기 때문에 API 서버에 대한 액세스를 세부적으로 제한하기가 어려울 수 있습니다. AKS에서 Microsoft Entra 통합 클러스터를 사용하는 경우 기존 사용자 및 그룹 계정을 사용하여 API 서버에서 사용자를 인증합니다.

Kubernetes RBAC 및 Microsoft Entra ID 통합을 사용하면 API 서버를 보호하고 단일 네임스페이스와 같이 범위가 지정된 리소스 세트에 필요한 최소 권한을 제공할 수 있습니다. 다른 Microsoft Entra 사용자 또는 그룹에 다른 Kubernetes 역할을 부여할 수 있습니다. 세분화된 권한을 사용하여 API 서버에 대한 액세스를 제한하고 수행된 작업에 대한 명확한 감사 추적을 제공할 수 있습니다.

AKS 자동에서 권한 부여 및 보안 기준은 지원되는 구성에서 더 미리 구성되므로 운영자는 유효성 검사, 거버넌스 및 예외 처리에 집중합니다. AKS 표준에서 운영자는 일반적으로 이러한 컨트롤을 직접 구성하고 수명 주기 상태를 유지 관리합니다.

Microsoft Entra 통합, Kubernetes RBAC 및 Azure RBAC에 대한 자세한 내용은 AKS의 인증 및 권한 부여 모범 사례를 참조하세요.

Instance Metadata API에 대한 액세스 제한

모범 사례 지침

모든 사용자 네임스페이스에 네트워크 정책을 추가하여 메타데이터 엔드포인트로의 Pod 송신을 차단합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

AKS 표준에서 선택한 네트워크 모델 및 정책 엔진이 이 정책 경로를 지원하는지 확인합니다. AKS Automatic에서는 클러스터 구성에서 지원되는 경우 상응하는 네임스페이스 수준의 송신 제한을 적용합니다.

리소스에 대한 안전한 컨테이너 액세스

모범 사례 지침

컨테이너가 수행할 수 있는 작업에 대한 액세스를 제한합니다. 최소한의 권한을 제공하고 루트 액세스 또는 권한 상승을 사용하지 마십시오.

사용자나 그룹에 필요한 최소한의 권한을 부여해야 하듯이 컨테이너를 필요한 작업과 프로세스로만 제한해야 합니다. 공격 위험을 최소화하려면 상승된 권한이나 루트 액세스가 필요한 애플리케이션 및 컨테이너를 구성하지 마십시오.

사용자 네임스페이스를 사용하여 호스트 격리를 개선하고 컨테이너 중단 시 횡적 이동을 제한합니다. 이러한 개선 사항은 Pod가 루트로 실행되는지 여부에 관계없이 중요합니다.

컨테이너 작업을 훨씬 더 세부적으로 제어하기 위해 AppArmor 및 seccomp와 같은 기본 제공 Linux 보안 기능을 사용할 수도 있습니다.

AKS Automatic이 강화된 기본값을 제공하는 경우에도 워크로드 수준 보안 제어는 애플리케이션 및 플랫폼 팀의 책임으로 유지됩니다.

자세한 내용은 리소스에 대한 컨테이너 액세스 보호를 참조하세요.

최신 버전의 Kubernetes로 정기적으로 업데이트

모범 사례 지침

새로운 기능 및 버그 수정을 최신 상태로 유지하려면 AKS 클러스터에서 Kubernetes 버전을 정기적으로 업그레이드하세요.

Kubernetes는 보다 일반적인 인프라 플랫폼보다 더 빠른 속도로 새 기능을 릴리스합니다. Kubernetes 업데이트에는 다음이 포함됩니다.

• 새로운 기능
• 버그 또는 보안 수정

새로운 기능은 일반적으로 안정되기 전에 알파 및 베타 상태를 거치게 됩니다. 일단 안정되면 일반 공급되며 프로덕션용으로 권장됩니다. Kubernetes의 새로운 기능 릴리스 주기 덕분에 호환성을 깨는 변경 사항을 자주 겪거나 배포 구성과 템플릿을 조정하지 않고도 Kubernetes를 업데이트할 수 있습니다.

AKS는 Kubernetes의 3개의 부 버전을 지원합니다. 새로운 부 패치 버전이 릴리스되면 지원되는 가장 오래된 부 버전 및 패치 릴리스는 사용 중지됩니다. 사소한 Kubernetes 업데이트는 정기적으로 발생합니다. 지원 범위 내에서 유지하려면 필요한 업그레이드를 확인하는 거버넌스 프로세스가 있는지 확인하십시오. 자세한 내용은 지원되는 Kubernetes 버전 AKS를 참조하세요.

AKS 자동에서 업그레이드 관련 동작은 지원되는 구성에서 더 미리 구성되며 운영자는 워크로드 준비 유효성 검사 및 릴리스 거버넌스에 집중해야 합니다. AKS Standard에서 운영자는 업그레이드 전략 및 롤아웃 타이밍을 더 직접적으로 선택하고 제어합니다.

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Get-AzAksUpgradeProfile -ResourceGroupName myResourceGroup -ClusterName myAKSCluster |
Select-Object -Property Name, ControlPlaneProfileKubernetesVersion -ExpandProperty ControlPlaneProfileUpgrade |
Format-Table -Property *

AKS의 업그레이드에 대한 자세한 내용은 AKS의 지원되는 Kubernetes 버전 및 AKS 클러스터 업그레이드를 참조하세요.

Linux 노드 업데이트 처리

매일 저녁 AKS의 Linux 노드는 배포판 업데이트 채널을 통해 보안 패치를 받습니다. 이 동작은 노드가 AKS 클러스터에 배포되면 자동으로 구성됩니다. 실행 중인 워크로드 중단 및 잠재적인 영향을 최소화하기 위해 보안 패치 또는 커널 업데이트에 필요한 경우에도 노드가 자동으로 다시 부팅되지 않습니다. 노드 다시 부팅을 처리하는 방법에 대한 자세한 내용은 AKS에서 노드에 보안 및 커널 업데이트 적용을 참조하세요.

AKS 자동에서 노드 업데이트 동작은 지원되는 구성에서 더 미리 구성됩니다. AKS 표준에서 운영자는 일반적으로 명시적 운영 제어를 사용하여 패치 및 다시 부팅 거버넌스를 정의합니다.

노드 이미지 업그레이드

자동 업그레이드는 Linux 노드 OS에 업데이트를 적용하지만 클러스터에 대한 노드를 만드는 데 사용되는 이미지는 변경되지 않습니다. 새 Linux 노드가 클러스터에 추가되면 원래 이미지를 사용하여 노드를 만듭니다. 이 새 노드는 매일 밤 자동 검사 중에 사용 가능한 모든 보안 및 커널 업데이트를 받지만 모든 검사와 다시 시작이 완료될 때까지 패치되지 않습니다. 노드 이미지 업그레이드를 사용하여 클러스터에서 사용하는 노드 이미지를 검사하고 업데이트할 수 있습니다. 노드 이미지 업그레이드에 대한 자세한 내용은 AKS(Azure Kubernetes Service) 노드 이미지 업그레이드를 참조하세요.

Windows Server 노드 업데이트 처리

Windows Server 노드의 경우 노드 이미지 업그레이드 작업을 정기적으로 수행하여 안전하게 pod를 차단 및 드레이닝하고 업데이트된 노드를 배포합니다.

관련 콘텐츠

AKS 및 AKS 클러스터 보안에 대한 자세한 내용은 다음 문서를 참조하세요.

• AKS 자동 및 AKS 표준 기능 비교
• AKS의 인증 및 권한 부여 모범 사례