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에서 애플리케이션을 보호하는 핵심 개념을 소개합니다.

빌드 보안

공급망의 진입점으로서 파이프라인 아래로 승격되기 전에 이미지 빌드의 정적 분석을 수행하는 것이 중요합니다. 여기에는 취약성 및 규정 준수 평가가 포함됩니다. 개발이 중단되므로 취약성이 있기 때문에 빌드에 실패하는 것이 아닙니다. 개발 팀에서 조치를 취할 수 있는 취약성을 기반으로 공급업체 상태를 분류하는 방법을 살펴보겠습니다. 또한 유예 기간을 사용하여 개발자가 식별된 문제를 수정할 시간을 허용합니다.

레지스트리 보안

레지스트리에서 이미지의 취약성 상태를 평가하면 드리프트가 감지되고 빌드 환경에서 제공되지 않은 이미지도 catch됩니다. Notary V2를 사용하여 이미지에 서명을 연결하여 신뢰할 수 있는 위치에서 배포가 이루어지도록 합니다.

클러스터 보안

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

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

Kubernetes RBAC(Kubernetes 역할 기반 액세스 제어) 및 Azure RBAC를 사용하여 API 서버에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 AKS와 Microsoft Entra 통합을 참조 하세요.

노드 보안

AKS 노드는 관리하고 기본 Azure VM(가상 머신)입니다.

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

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

참고 항목

실행 중인 AKS 클러스터:

  • Kubernetes 버전 1.19 이상 - Linux 노드 풀은 컨테이너 런타임으로 사용합니다 containerd . Windows Server 2019 노드 풀은 현재 미리 보기 상태인 컨테이너 런타임으로 사용합니다 containerd . 자세한 내용은 containerd로 Windows Server 노드 풀 추가를 참조하세요.
  • Kubernetes 버전 1.19 이하 - Linux 노드 풀은 Docker를 컨테이너 런타임으로 사용합니다. Windows Server 2019 노드 풀은 기본 컨테이너 런타임에 Docker를 사용합니다.

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

노드 권한 부여

노드 권한 부여는 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 Route를 사용하여 온-프레미스 네트워크에 다시 연결합니다. 서비스 액세스를 내부 네트워크 연결로 제한하도록 개인, 내부 IP 주소를 사용하여 Kubernetes 수신 컨트롤러를 정의합니다.

Azure 네트워크 보안 그룹

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

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

Kubernetes 네트워크 정책

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

애플리케이션 보안

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

Kubernetes 비밀

Kubernetes Secret을 사용하면 액세스 자격 증명 또는 키와 같은 중요한 데이터를 Pod에 삽입합니다.

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

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

참고 항목

원시 비밀 매니페스트 파일에는 base64 형식의 비밀 데이터가 포함되어 있습니다. 자세한 내용은 공식 설명서를 참조하세요. 이러한 파일을 중요한 정보로 처리하고 소스 제어에 커밋하지 않습니다.

Kubernetes 비밀은 분산 키-값 저장소인 etcd에 저장됩니다. AKS에서 etcd 저장소를 완전히 관리하며 데이터는 Azure 플랫폼 내에서 미사용 시 암호화됩니다.

다음 단계

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

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

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