AKS(Azure Kubernetes Service)의 애플리케이션 및 클러스터에 대한 보안 개념
컨테이너 보안은 전체 엔드투엔드 파이프라인을 빌드에서 AKS(Azure Kubernetes Service)에서 실행되는 애플리케이션 워크로드로 보호합니다.
보안 공급망에는 빌드 환경 및 레지스트리가 포함됩니다.
Kubernetes에는 Pod 보안 표준 및 비밀과 같은 보안 구성 요소가 포함됩니다. Azure에는 Active Directory, 컨테이너용 Microsoft Defender, Azure Policy, Azure Key Vault, 네트워크 보안 그룹 및 오케스트레이션된 클러스터 업그레이드와 같은 구성 요소가 포함됩니다. AKS는 이러한 보안 구성 요소를 결합하여 다음을 수행합니다.
- 전체 인증 및 권한 부여 사례를 제공합니다.
- AKS 기본 제공 Azure Policy를 적용하여 애플리케이션을 보호합니다.
- 컨테이너용 Microsoft Defender를 사용하여 애플리케이션을 통해 빌드된 엔드 투 엔드 인사이트.
- AKS 클러스터에서 최신 OS 보안 업데이트 및 Kubernetes 릴리스를 실행하도록 합니다.
- 보안 Pod 트래픽 및 중요한 자격 증명에 대한 액세스 권한을 제공합니다.
이 문서에서는 AKS에서 애플리케이션을 보호하는 핵심 개념을 소개합니다.
빌드 보안
공급망의 진입점으로 파이프라인 아래로 승격되기 전에 이미지 빌드의 정적 분석을 수행하는 것이 중요합니다. 여기에는 취약성 및 규정 준수 평가가 포함됩니다. 개발이 중단되므로 취약성이 있기 때문에 빌드에 실패하는 것이 아닙니다. 개발 팀에서 실행 가능한 취약성을 기반으로 공급업체 상태를 분류하는 방법을 살펴봅니다. 또한 유예 기간을 사용하여 개발자가 식별된 문제를 수정할 시간을 허용합니다.
레지스트리 보안
레지스트리에서 이미지의 취약성 상태를 평가하면 드리프트가 검색되고 빌드 환경에서 제공되지 않은 이미지도 포착됩니다. Notary V2를 사용하여 이미지에 서명을 연결하여 신뢰할 수 있는 위치에서 배포가 이루어지도록 합니다.
클러스터 보안
AKS에서 Kubernetes 마스터 구성 요소는 Microsoft에서 제공하고 관리하며 유지하는 관리형 서비스의 일부입니다. 각 AKS 클러스터에는 API 서버, 스케줄러 등을 제공하는 자체 단일 테넌트 전용 Kubernetes 마스터가 있습니다. 자세한 내용은 Azure Kubernetes Service 취약성 관리를 참조하세요.
기본적으로 Kubernetes API 서버는 공용 IP 주소 및 FQDN(정규화된 도메인 이름)을 사용합니다. 권한 있는 IP 범위를 사용하여 API 서버 엔드포인트에 대한 액세스를 제한할 수 있습니다. 또한 완전한 프라이빗 클러스터를 만들어 가상 네트워크에 대한 API 서버 액세스를 제한할 수 있습니다.
Kubernetes RBAC(역할 기반 액세스 제어) 및 Azure RBAC를 사용하여 API 서버에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 AKS와 Microsoft Entra 통합을 참조하세요.
노드 보안
AKS 노드는 사용자가 관리하고 유지하는 Azure VM(가상 머신)입니다.
- Linux 노드는 Ubuntu 또는 Azure Linux의 최적화된 버전을 실행합니다.
- Windows Server 노드는 컨테이너 런타임을 사용하여 최적화된 Windows Server 2022 릴리스를
containerd실행합니다.
AKS 클러스터가 생성되거나 강화되면 노드는 최신 OS 보안 업데이트 및 구성을 사용하여 자동으로 배포됩니다.
참고 항목
실행 중인 AKS 클러스터:
- Kubernetes 버전 1.19 이상 - Linux 노드 풀은 컨테이너 런타임으로
containerd를 사용합니다. Windows Server 2019 및 Windows Server 2022 노드 풀은 컨테이너 런타임으로 사용합니다containerd. 자세한 내용은containerd로 Windows Server 노드 풀 추가를 참조하세요. - Kubernetes 버전 1.19 이하 - Linux 노드 풀은 Docker를 컨테이너 런타임으로 사용합니다.
Linux 및 Windows 작업자 노드의 보안 업그레이드 프로세스에 대한 자세한 내용은 보안 패치 노드를 참조하세요.
Azure 2세대 VM을 실행하는 AKS 클러스터에는 보안 부팅 및 가상화된 버전의 신뢰할 수 있는 플랫폼 모듈(vTPM)과 같이 독립적으로 사용하도록 설정할 수 있는 기술을 결합하여 고급 및 영구 공격 기술로부터 보호하는 신뢰할 수 있는 시작 지원이 포함되어 있습니다. 관리자는 확인되고 서명된 부팅 로더, OS 커널 및 드라이버가 있는 AKS 작업자 노드를 배포하여 기본 VM의 전체 부팅 체인의 무결성을 보장할 수 있습니다.
노드 권한 부여
노드 권한 부여는 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 기밀 컨테이너를 기반으로 컨테이너 메모리를 암호화하고 계산 중 메모리의 데이터가 명확한 텍스트, 읽기 가능한 형식 및 변조되지 않도록 방지합니다. VM 노드 OS 커널뿐만 아니라 다른 컨테이너 그룹/Pod에서 컨테이너를 격리하는 데 도움이 됩니다. 기밀 컨테이너(미리 보기)는 하드웨어 기반 메모리 암호화(SEV-SNP)를 사용합니다.
- Pod 샌드박싱(미리 보기)은 컨테이너 애플리케이션과 컨테이너 호스트의 공유 커널 및 컴퓨팅 리소스(CPU, 메모리 및 네트워크) 간에 격리 경계를 제공합니다.
네트워크 보안
온-프레미스 네트워크와의 연결 및 보안을 위해 AKS 클러스터를 기존 Azure 가상 네트워크 서브넷에 배포할 수 있습니다. 이러한 가상 네트워크는 Azure 사이트 간 VPN 또는 Express 경로를 사용하여 온-프레미스 네트워크에 다시 연결됩니다. 서비스 액세스를 내부 네트워크 연결로 제한하도록 개인, 내부 IP 주소를 사용하여 Kubernetes 수신 컨트롤러를 정의합니다.
Azure 네트워크 보안 그룹
가상 네트워크 트래픽 흐름을 필터링하기 위해 Azure는 네트워크 보안 그룹 규칙을 사용합니다. 이러한 규칙은 리소스에 대한 액세스가 허용되거나 거부된 원본 및 대상 IP 범위, 포트 및 프로토콜을 정의합니다. 기본 규칙은 Kubernetes API 서버에 대한 TLS 트래픽을 허용하도록 생성됩니다. 부하 분산 장치, 포트 매핑 또는 수신 경로를 사용하여 서비스를 만듭니다. AKS는 트래픽 흐름에 대한 네트워크 보안 그룹을 자동으로 수정합니다.
AKS 클러스터에 고유한 서브넷을 제공하는 경우(Azure CNI 또는 Kubenet 사용 여부와 관계없이) AKS에서 관리하는 NIC 수준 네트워크 보안 그룹을 수정하지 마세요. 대신 트래픽 흐름을 수정하는 서브넷 수준 네트워크 보안 그룹을 더 많이 만듭니다. 부하 분산 장치 액세스, 컨트롤 플레인과의 통신 또는 송신 등 클러스터를 관리하는 데 필요한 트래픽을 방해하지 않는지 확인합니다.
Kubernetes 네트워크 정책
클러스터의 Pod 간 네트워크 트래픽을 제한하기 위해 AKS는 Kubernetes 네트워크 정책을 지원합니다. 네트워크 정책을 사용하면 네임스페이스 및 레이블 선택기에 따라 클러스터 내의 특정 네트워크 경로를 허용하거나 거부할 수 있습니다.
애플리케이션 보안
AKS에서 실행되는 Pod를 보호하려면 컨테이너용 Microsoft Defender를 고려하여 Pod에서 실행되는 애플리케이션에 대한 사이버 공격을 탐지하고 제한합니다. 지속적인 검사를 실행하여 애플리케이션의 취약성 상태에서 드리프트를 감지하고 "파란색/녹색/카나리아" 프로세스를 구현하여 취약한 이미지를 패치하고 바꿉니다.
리소스에 대한 안전한 컨테이너 액세스
사용자나 그룹에 필요한 최소한의 권한을 부여해야 하듯이 컨테이너를 필요한 작업과 프로세스로만 제한해야 합니다. 공격 위험을 최소화하려면 상승된 권한이나 루트 액세스가 필요한 애플리케이션 및 컨테이너를 구성하지 마십시오. [리소스에 대한 컨테이너 액세스 보호][secure-container-access]에 모범 사례로 AppArmor 및 seccomp와 같은 기본 제공 Linux 보안 기능이 권장됩니다.
Kubernetes 비밀
Kubernetes ‘비밀’을 사용하여 액세스 자격 증명이나 키와 같은 중요한 데이터를 Pod에 삽입합니다.
- Kubernetes API를 사용하여 비밀을 만듭니다.
- Pod 또는 배포를 정의하고 특정 비밀을 요청합니다.
- 비밀은 비밀을 요구하는 예약된 Pod가 있는 노드에만 제공됩니다.
- 비밀은 디스크에 기록되지 않고 tmpfs에 저장됩니다.
- 비밀을 요구하는 노드에서 마지막 Pod를 삭제하면 해당 비밀이 노드의 tmpfs에서 삭제됩니다.
- 비밀은 지정된 네임스페이스 내에 저장되며 동일한 네임스페이스 내의 Pod에서만 액세스할 수 있습니다.
비밀을 사용하면 Pod 또는 서비스 YAML 매니페스트에 정의되는 중요한 정보가 줄어듭니다. 대신 Kubernetes API 서버에 저장된 비밀을 YAML 매니페스트의 일부로 요청합니다. 이 방법은 비밀에 대한 특정 Pod 액세스만 제공합니다.
참고 항목
원시 비밀 매니페스트 파일에는 base64 형식의 비밀 데이터가 포함되어 있습니다. 자세한 내용은 공식 설명서를 참조하세요. 이러한 파일은 중요한 정보로 처리해야 하며 소스 제어로 커밋해서는 안 됩니다.
Kubernetes 비밀은 분산 키-값 저장소인 etcd에 저장됩니다. AKS에서 etcd 저장소를 완전히 관리하며 데이터는 Azure 플랫폼 내에서 미사용 시 암호화됩니다.
다음 단계
AKS 클러스터의 보안을 유지하려면 AKS 클러스터 업그레이드를 참조하세요.
관련 모범 사례는 AKS의 클러스터 보안 및 업그레이드 모범 사례 및 AKS의 Pod 보안 모범 사례를 참조하세요.
핵심 Kubernetes 및 AKS 개념에 대한 자세한 내용은 다음을 참조하세요.
Azure Kubernetes Service