AKS(Azure Kubernetes Service) 애플리케이션 및 클러스터에 대한 보안 개념

컨테이너 보안은 전체 엔드 투 엔드 파이프라인을 빌드에서 AKS(Azure Kubernetes Service) 실행 중인 애플리케이션 워크로드로 보호합니다.

보안 공급망에는 빌드 환경 및 레지스트리가 포함됩니다.

Kubernetes에는 Pod 보안 표준 및 비밀과 같은 보안 구성 요소가 포함됩니다. Azure Microsoft Entra ID, 컨테이너용 Microsoft Defender, Azure Policy, Azure Key Vault, 네트워크 보안 그룹 및 오케스트레이션된 클러스터 업그레이드와 같은 구성 요소가 포함됩니다. AKS는 이러한 보안 구성 요소를 결합하여 다음을 수행합니다.

• 전체 인증 및 권한 부여 사례를 제공합니다.
• AKS 기본 제공 Azure Policy 적용하여 애플리케이션을 보호합니다.
• Microsoft Defender for Containers를 통해 빌드부터 애플리케이션까지 엔드투엔드 가시성을 확보하세요.
• AKS 클러스터에서 최신 OS 보안 업데이트 및 Kubernetes 릴리스를 실행하도록 합니다.
• 보안 Pod 트래픽 및 중요한 자격 증명에 대한 액세스 권한을 제공합니다.

AKS는 AKS 자동 및 AKS 표준의 두 가지 클러스터 모드를 지원합니다. 이 문서의 보안 개념은 달리 명시되지 않는 한 두 모드에 모두 적용됩니다. AKS Automatic에는 기본적으로 미리 구성된 여러 컨트롤이 있는 강화된 보안 기준이 포함되어 있지만 AKS 표준은 더 많은 구성 유연성을 제공합니다.

이 문서에서는 AKS에서 애플리케이션을 보호하는 핵심 개념을 소개합니다.

보안을 구축하다

빌드 보안은 보안 공급망의 진입점입니다. 이미지가 배포 환경으로 승격되기 전에 CI에서 정적 분석 및 취약성 및 규정 준수 평가를 실행합니다.

두 AKS 모드 모두 취약성에 대한 모든 빌드를 차단하는 대신 위험 기반 심사를 사용합니다. 공급업체 상태 및 심각도를 사용하여 수정의 우선 순위를 지정하고 악용할 수 없는 예외 또는 시간 제한 예외에 대한 유예 기간을 적용합니다.

AKS Automatic은 미리 구성된 보안 제어를 사용하여 강화된 기준에서 클러스터를 시작하여 다운스트림 구성 드리프트를 줄이는 데 도움이 됩니다. 따라서 신뢰할 수 있는 이미지가 보안 런타임 기준선으로 더 일관되게 승격되므로 이미지 품질 및 정책 준수에 대한 빌드 시간 유효성 검사가 더욱 중요해집니다.

AKS 표준은 클러스터 수준 유연성을 더 제공하므로 빌드 파이프라인은 배포 전에 이미지 출처, 취약성 임계값 및 정책 게이트에 대한 조직 기준을 명시적으로 적용해야 합니다.

레지스트리 보안

레지스트리 보안은 신뢰할 수 있고 호환되는 이미지만 배포에 사용할 수 있는지 확인하고 빌드 후 드리프트를 감지하는 데 도움이 됩니다. 빌드 시뿐만 아니라 레지스트리의 이미지 취약성 상태를 지속적으로 평가합니다. 레지스트리 검사는 승인된 빌드 경로를 우회한 새로 공개된 취약성 및 이미지를 catch합니다. Notary V2와 같은 이미지 서명 및 확인을 사용하여 검증 가능한 출처가 있는 신뢰할 수 있는 원본에서 워크로드가 배포되도록 합니다.

여러 런타임 보안 기능이 미리 구성된 AKS Automatic의 경우 레지스트리 제어는 런타임 공급망을 깨끗하게 유지하기 위한 중요한 업스트림 게이트로 유지됩니다. AKS Standard의 경우 동일한 레지스트리 컨트롤을 적용하고 클러스터 허용 및 정책 구성에 맞게 조정하여 신뢰할 수 있는 이미지 사용을 일관되게 적용합니다.

클러스터 보안

AKS에서 Kubernetes 기본 구성 요소는 Microsoft 제공, 관리 및 유지 관리되는 관리 서비스의 일부입니다. 각 AKS 클러스터에는 API 서버, 스케줄러 등을 제공하는 자체 전용 단일 테넌트 Kubernetes 주 노드가 있습니다. 자세한 내용은 Azure Kubernetes Service의 취약성 관리를 참조하세요.

기본적으로 Kubernetes API 서버는 공용 IP 주소 및 FQDN(정규화된 도메인 이름)을 사용합니다. 권한 있는 IP 범위를 사용하여 API 서버 엔드포인트에 대한 액세스를 제한할 수 있습니다. 또한 완전한 프라이빗 클러스터를 만들어 가상 네트워크에 대한 API 서버 액세스를 제한할 수 있습니다.

AKS 자동의 경우 API 서버 가상 네트워크 통합은 기본 보안 상태의 일부로 미리 구성됩니다. AKS Standard에서 동일한 기능을 사용할 수 있으며 네트워크 디자인 및 보안 요구 사항에 따라 사용하도록 설정할 수 있습니다.

Kubernetes RBAC(Kubernetes 역할 기반 액세스 제어) 및 AZURE RBAC를 사용하여 API 서버에 대한 액세스를 제어할 수 있습니다. AKS 자동에서 kubernetes 권한 부여에 대한 AZURE RBAC가 미리 구성됩니다. AKS 표준에서는 환경에 가장 적합한 권한 부여 모델을 선택하고 구성할 수 있습니다. 자세한 내용은 Microsoft Entra와 AKS의 통합을 참조하세요.

AKS 자동 보안 기본값

AKS Automatic에는 다음을 포함하여 기본적으로 미리 구성된 보안 컨트롤이 있는 강화된 기준이 포함되어 있습니다.

• Kubernetes 권한 부여를 위한 Azure RBAC
• API 서버 가상 네트워크 통합
• 워크로드 ID 및 OIDC 발급자
• 배포 보호 장치 및 강제 적용 모드의 기준 Pod 보안 표준
• 사용되지 않는 취약한 이미지를 제거하기 위한 이미지 클리너
• 고객 워크로드와 AKS 관리형 인프라 간의 경계를 유지하는 관리되는 시스템 노드 풀 보안 제한 사항

AKS Standard는 구현 유연성이 향상되어 이러한 기능을 지원하지만 명시적 사용 및 운영 관리가 필요할 수 있습니다.

노드 보안

AKS 노드는 Azure 가상 머신(VM)입니다. AKS 표준에서는 노드 풀 구성 및 수명 주기 옵션을 관리합니다. AKS Automatic에서 AKS는 관리되는 시스템 인프라에 대한 보안 제한과 함께 크기 조정 및 업그레이드를 포함하여 사용자 대신 시스템 노드 풀 및 핵심 시스템 구성 요소를 관리합니다.

Linux 노드는 최적화된 버전의 Ubuntu 또는 Azure Linux를 실행합니다. Windows Server 노드는 containerd 컨테이너 런타임을 사용하여 최적화된 Windows Server 릴리스를 실행합니다.

AKS 클러스터가 생성되거나 강화되면 노드는 최신 OS 보안 업데이트 및 구성을 사용하여 자동으로 배포됩니다.

Linux 및 Windows 작업자 노드의 보안 업그레이드 프로세스에 대한 자세한 내용은 보안 패치 노드 참조하세요.

Azure 2세대 VM을 실행하는 AKS 클러스터에는 Trusted Launch 대한 지원이 포함됩니다. 이 기능은 보안 부팅 및 vTPM(신뢰할 수 있는 플랫폼 모듈)의 가상화된 버전과 같이 독립적으로 사용하도록 설정할 수 있는 기술을 결합하여 고급 및 영구 공격 기술로부터 보호합니다. 관리자는 확인되고 서명된 부팅 로더, OS 커널 및 드라이버가 있는 AKS 작업자 노드를 배포하여 기본 VM의 전체 부팅 체인의 무결성을 보장할 수 있습니다.

컨테이너 및 보안 최적화 OS 옵션

Azure ACL(Container Linux)은 AKS용 변경할 수 없는 컨테이너 최적화 OS입니다. ACL은 Flatcar Container Linux 프로젝트에서 파생되며, Azure Linux 패키지, 서비스 및 플랫폼 통합에서 계층화하면서 플랫카의 입증된 컨테이너 우선 변경할 수 없는 디자인을 기반으로 합니다. 이를 통해 ACL은 Azure 프로덕션, 보안 및 규정 준수 요구 사항을 충족하면서 업스트림 Flatcar 혁신과 긴밀하게 일치할 수 있습니다. Flatcar Container Linux에 대한 자세한 내용은 Flatcar 설명서를 참조하세요.

ACL은 AKS v1.34부터 AKS의 OS 옵션으로 GA(일반 공급)됩니다. 새 AKS 클러스터에 ACL 노드 풀을 배포하고, 기존 클러스터에 ACL 노드 풀을 추가하고, 기존 Linux 노드 풀을 ACL로 마이그레이션할 수 있습니다.

ACL에 대한 자세한 내용은 AKS용 Azure Container Linux(ACL) 개요를 참조하세요.

노드 권한 부여

노드 권한 부여는 East-West 공격으로부터 보호하기 위해 kubelet API 요청을 특별히 권한 부여하는 특수 목적의 권한 부여 모드입니다. 노드 권한 부여는 AKS 1.24 이상 클러스터에서 기본적으로 사용하도록 설정됩니다.

노드 배포

노드는 공용 IP 주소가 할당되지 않은 상태에서 프라이빗 가상 네트워크 서브넷에 배포됩니다. 문제 해결 및 관리를 위해 SSH는 기본적으로 사용하도록 설정되어 있으며 내부 IP 주소를 사용해서만 액세스할 수 있습니다. 클러스터 및 노드 풀을 만드는 동안 또는 기존 클러스터 또는 노드 풀에 대해 SSH를 사용하지 않도록 설정하는 것은 미리 보기 상태입니다. 자세한 내용은 SSH 액세스 관리를 참조하세요.

노드 스토리지

스토리지를 제공하기 위해 노드는 Azure Managed Disks 사용합니다. 대부분의 VM 노드 크기에서 Azure Managed Disks 고성능 SSD에서 지원되는 프리미엄 디스크입니다. 관리 디스크에 저장된 데이터는 Azure 플랫폼 내에서 미사용 시 자동으로 암호화됩니다. 중복성을 개선하기 위해 Azure Managed Disks Azure 데이터 센터 내에서 안전하게 복제됩니다.

적대적인 다중 테넌트 작업 부하

현재 Kubernetes 환경은 악의적인 다중 테넌트 사용에 대해 안전하지 않습니다. 노드에 대한 ‘Pod 보안 정책’이나 Kubernetes RBAC 같은 추가 보안 기능을 통해 악용을 효율적으로 차단할 수 있습니다. 악의적인 다중 테넌트 워크로드를 실행할 때의 진정한 보안을 위해서는 하이퍼바이저만 신뢰하세요. Kubernetes의 보안 도메인은 개별 노드가 아닌 전체 클러스터가 됩니다.

이러한 유형의 악의적인 다중 테넌트 워크로드의 경우 물리적으로 격리된 클러스터를 사용해야 합니다. 워크로드를 격리하는 방법에 대한 자세한 내용은 AKS의 클러스터 격리에 대한 모범 사례를 참조하세요.

컴퓨팅 격리

규정 준수 또는 규정 요구 사항으로 인해 특정 워크로드에서는 다른 고객 워크로드와 높은 수준의 격리를 요구할 수 있습니다. 이러한 워크로드의 경우 Azure 다음을 제공합니다.

• AKS 클러스터에서 에이전트 노드로 사용할 커널 격리 컨테이너 이러한 컨테이너는 특정 하드웨어 유형으로 완전히 격리되고 Azure 호스트 패브릭, 호스트 운영 체제 및 하이퍼바이저에서 격리됩니다. 단일 고객 전용입니다. AKS 클러스터를 만들거나 노드 풀을 추가할 때 격리된 VM 크기 중 하나를 노드 크기로 선택합니다.
• 기밀 컨테이너(미리 보기)는 Kata 기밀 컨테이너를 기반으로 컨테이너 메모리를 암호화하고 계산 중 메모리의 데이터가 명확한 텍스트, 읽기 가능한 형식 및 변조되지 않도록 방지합니다. 다른 컨테이너 그룹/Pod 및 VM 노드 OS 커널에서 컨테이너를 격리하는 데 도움이 됩니다. 기밀 컨테이너(미리 보기)는 하드웨어 기반 메모리 암호화(SEV-SNP)를 사용합니다.
• Pod 샌드박싱(미리 보기)은 컨테이너 애플리케이션과 컨테이너 호스트의 공유 커널 및 컴퓨팅 리소스(CPU, 메모리 및 네트워크) 간에 격리 경계를 제공합니다.

네트워크 보안

온-프레미스 네트워크와의 연결 및 보안을 위해 AKS 클러스터를 기존 Azure 가상 네트워크 서브넷에 배포할 수 있습니다. 이러한 가상 네트워크는 Azure 사이트간 VPN 또는 Express Route를 사용하여 온-프레미스 네트워크에 다시 연결합니다. 서비스 액세스를 내부 네트워크 연결로 제한하도록 개인, 내부 IP 주소를 사용하여 Kubernetes 수신 컨트롤러를 정의합니다.

AKS 자동에서 관리형 가상 네트워크 기능과 핵심 수신 및 송신 기본값은 보안 기준을 제공하도록 미리 구성됩니다. AKS Standard에서 네트워킹 모델 및 송신/수신 컨트롤은 더 유연하며 보안 아키텍처에 따라 선택해야 합니다.

Azure 네트워크 보안 그룹

가상 네트워크 트래픽 흐름을 필터링하기 위해 Azure 네트워크 보안 그룹 규칙을 사용합니다. 이러한 규칙은 리소스에 대한 액세스가 허용되거나 거부된 원본 및 대상 IP 범위, 포트 및 프로토콜을 정의합니다. 기본 규칙은 Kubernetes API 서버에 대한 TLS 트래픽을 허용하도록 생성됩니다. 부하 분산 장치, 포트 매핑 또는 수신 경로를 사용하여 서비스를 만듭니다. AKS는 트래픽 흐름에 대한 네트워크 보안 그룹을 자동으로 수정합니다.

AKS 클러스터(Azure CNI 또는 Kubenet 사용 여부)에 고유한 서브넷을 제공하는 경우 AKS에서 관리하는 NIC 수준 네트워크 보안 그룹을 수정하지 않습니다. 대신 트래픽 흐름을 수정하는 서브넷 수준 네트워크 보안 그룹을 더 많이 만듭니다. 부하 분산 장치 액세스, 컨트롤 플레인과의 통신 또는 송신 등 클러스터를 관리하는 데 필요한 트래픽을 방해하지 않는지 확인합니다.

Kubernetes 네트워크 정책

클러스터의 Pod 간 네트워크 트래픽을 제한하기 위해 AKS는 Kubernetes 네트워크 정책을 지원합니다. 네트워크 정책을 사용하면 네임스페이스 및 레이블 선택기에 따라 클러스터 내의 특정 네트워크 경로를 허용하거나 거부할 수 있습니다.

애플리케이션 보안

AKS에서 실행되는 Pod를 보호하려면 컨테이너용 Microsoft Defender를 사용하여 Pod에서 실행되는 애플리케이션에 대한 사이버 공격을 감지하고 제한하는 것이 좋습니다. 지속적인 검사를 실행하여 애플리케이션의 취약성 상태에서 드리프트를 감지하고 "파란색/녹색/카나리아" 프로세스를 구현하여 취약한 이미지를 패치하고 바꿉니다.

AKS 자동에서 워크로드 ID 및 OIDC 발급자는 Azure 서비스에 대한 보안 워크로드 액세스를 간소화하도록 미리 구성됩니다. AKS Standard에서 이러한 기능을 사용할 수 있으며 기준 보안 상태의 일부로 사용하도록 설정할 수 있습니다.

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

사용자나 그룹에 필요한 최소한의 권한을 부여해야 하듯이 컨테이너를 필요한 작업과 프로세스로만 제한해야 합니다. 공격 위험을 최소화하려면 상승된 권한이나 루트 액세스가 필요한 애플리케이션 및 컨테이너를 구성하지 마십시오. AppArmor 및 seccomp와 같은 기본 제공 Linux 보안 기능은 리소스에 대한 컨테이너 액세스를 보호하는모범 사례로 권장됩니다.

Kubernetes 비밀

Kubernetes ‘비밀’을 사용하여 액세스 자격 증명이나 키와 같은 중요한 데이터를 Pod에 삽입합니다.

1. Kubernetes API를 사용하여 비밀을 만듭니다.
2. Pod 또는 배포를 정의하고 특정 비밀을 요청합니다.
   • 비밀은 이를 요구하는 예약된 Pod가 있는 노드에만 제공됩니다.
   • 비밀은 디스크에 기록되지 않고 tmpfs에 저장됩니다.
3. 비밀을 요구하는 노드에서 마지막 Pod를 삭제하면 해당 비밀이 노드의 tmpfs에서 삭제됩니다.
   • 비밀은 지정된 네임스페이스 내에 저장되며 동일한 네임스페이스 내의 Pod에서만 액세스할 수 있습니다.

비밀을 사용하면 Pod 또는 서비스 YAML 매니페스트에 정의되는 중요한 정보가 줄어듭니다. 대신 Kubernetes API 서버에 저장된 비밀을 YAML 매니페스트의 일부로 요청합니다. 이 방법은 비밀에 대한 특정 Pod 액세스만 제공합니다.

Kubernetes 비밀은 분산 키-값 저장소인 etcd에 저장됩니다. AKS는 고객 관리형 키를 사용하여 etcd의 나머지 비밀 암호화를 허용합니다.

관련 콘텐츠

AKS 클러스터의 보안을 유지하려면 AKS 클러스터 업그레이드를 참조하세요.

모드별 기본값 및 운영 책임을 평가하는 경우 AKS(Azure Kubernetes Service) 자동이란?을 참조하세요.

관련 모범 사례는 AKS의 클러스터 보안 및 업그레이드 모범 사례 및 AKS의 Pod 보안 모범 사례를 참조하세요.

핵심 Kubernetes 및 AKS 개념에 대한 자세한 내용은 다음을 참조하세요.

• Kubernetes/AKS 클러스터 및 워크로드
• Kubernetes/AKS ID
• Kubernetes/AKS 가상 네트워크
• Kubernetes/AKS 스토리지
• Kubernetes/AKS 크기 조정