Azure Firewall을 사용하여 AKS(Azure Kubernetes Service) 클러스터 보호

Azure Firewall

AKS(Azure Kubernetes Service)

Azure Private Link

Azure Virtual Network

Azure DevOps

이 가이드에서는 Terraform 및 Azure DevOps를 사용하여 허브 스포크 네트워크 토폴로지에서 프라이빗 AKS 클러스터를 만드는 방법에 대해 설명합니다. Azure Firewall는 AKS(Azure Kubernetes Service) 클러스터를 드나드는 트래픽을 검사하는 데 사용됩니다. 클러스터는 허브 가상 네트워크에 피어링된 하나 이상의 스포크 가상 네트워크에서 호스트됩니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

Terraform 모듈은 다음을 호스트하는 4개의 서브넷이 있는 새 가상 네트워크를 배포하는 데 사용됩니다.

AKS 클러스터(AksSubnet).
점프 박스 가상 머신(VM) 및 프라이빗 엔드포인트(VmSubnet).
Application Gateway WAF2(AppGatewaySubnet).
Azure Bastion(AzureBastionSubnet).

AKS 클러스터는 사용자 정의 관리 ID를 사용하여 Azure의 부하 분산 장치 및 관리 디스크와 같은 추가 리소스를 만듭니다. Terraform 모듈을 사용하면 다음과 같은 기능이 있는 AKS 클러스터를 선택적으로 배포할 수 있습니다.

AKS 클러스터는 다음 풀로 구성됩니다.

중요한 시스템 Pod 및 서비스만 호스트하는 시스템 노드 풀
사용자 워크로드 및 아티팩트를 호스트하는 사용자 노드 풀

VM은 AKS 클러스터를 호스트하는 가상 네트워크에 배포됩니다. AKS를 프라이빗 클러스터로 배포하면 시스템 관리자가 이 VM을 사용하여 Kubernetes 명령줄 도구를 통해 클러스터를 관리할 수 있습니다. VM의 부팅 진단 로그는 Azure Storage 계정에 저장됩니다.

Azure Bastion 호스트는 SSL을 통해 jump-box VM에 대한 보안이 강화된 SSH 연결을 제공합니다. Azure Container Registry는 컨테이너 이미지 및 아티팩트(예: Helm 차트)를 빌드, 저장 및 관리하는 데 사용됩니다.

AKS는 클러스터와 외부 네트워크 간의 수신 및 송신 트래픽을 보호하기 위한 기본 제공 솔루션을 제공하지 않습니다.

이러한 이유로 이 문서에 제시된 아키텍처에는 DNAT 규칙, 네트워크 규칙 및 애플리케이션 규칙을 사용하여 인바운드 및 아웃바운드 트래픽을 제어하는 Azure Firewall이 포함되어 있습니다. 또한 방화벽은 위협 인텔리전스 기반 필터링을 통해 워크로드를 보호합니다. Azure Firewall 및 Bastion은 프라이빗 AKS 클러스터를 호스트하는 가상 네트워크와 피어링되는 허브 가상 네트워크에 배포됩니다. 경로 테이블 및 사용자 정의 경로는 AKS 클러스터에서 Azure Firewall로 아웃바운드 트래픽을 라우팅합니다.

참고 항목

고급 위협 차단을 제공하는 Azure Firewall의 프리미엄 SKU를 사용하는 것이 좋습니다.

Key Vault는 AKS에서 실행되는 워크로드에 의해 비밀 저장소로 사용되어 Microsoft Entra 워크로드 ID, 비밀 저장소 CSI 드라이버 또는 Dapr를 통해 키, 인증서 및 비밀을 검색합니다. Azure Private Link를 사용하면 AKS 워크로드가 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure Key Vault와 같은 Azure PaaS 서비스에 액세스할 수 있습니다.

토폴로지에는 이러한 서비스에 대한 프라이빗 엔드포인트 및 프라이빗 DNS 영역이 포함됩니다.

AKS 클러스터를 호스트하는 가상 네트워크와 앞에서 설명한 프라이빗 DNS 영역 간에 가상 네트워크 링크가 있습니다.

Log Analytics 작업 영역은 진단 로그 및 메트릭을 수집하는 데 사용됩니다.

구성 요소

Azure Firewall는 Azure에서 실행되는 클라우드 워크로드에 대한 위협 방지를 제공하는 클라우드 네이티브 지능형 네트워크 방화벽 보안 서비스입니다. 고가용성 및 무제한 클라우드 확장성이 내장되어 있는 서비스 형태의 완전한 상태 저장 방화벽입니다. 동서 및 남북 트래픽 검사를 모두 제공합니다.
Container Registry는 Docker Registry 2.0 오픈 소스에 기반한 관리형의 프라이빗 Docker 레지스트리 서비스입니다. 기존 컨테이너 개발 및 배포 파이프라인과 함께 Azure Container Registry를 사용하거나 Container Registry 작업을 사용하여 Azure에서 컨테이너 이미지를 빌드할 수 있습니다.
Azure Kubernetes Service는 운영 오버헤드를 Azure로 오프로드하여 Azure에서 관리형 Kubernetes 클러스터 배포를 단순화합니다. 호스팅되는 Kubernetes 서비스인 Azure는 상태 모니터링 및 유지 관리 같은 중요 작업을 처리합니다. Kubernetes 마스터는 Azure에서 관리하므로 사용자는 에이전트 노드만 관리하고 유지 관리합니다.
Key Vault는 API 키, 암호, 인증서 및 암호화 키와 같은 비밀을 더욱 안전하게 저장하고 액세스를 제어합니다. 또한 Key Vault를 사용하면 Azure 및 연결된 내부 리소스에 사용할 공용 및 프라이빗 TLS/SSL(Transport Layer Security/Secure Sockets Layer) 인증서를 쉽게 프로비저닝, 관리 및 배포할 수 있습니다.
Azure Bastion은 가상 네트워크 내부에 프로비전하는 완전 관리형 PaaS(Platform as a Service)입니다. Azure Bastion은 TLS를 통해 Azure Portal에서 직접 가상 네트워크의 VM에 대한 보안이 강화된 RDP(원격 데스크톱 프로토콜) 및 SSH(보안 셸) 연결을 제공합니다.
Azure Virtual Machines는 가상화의 유연성을 제공하는 스케일링 가능한 주문형 컴퓨팅 리소스를 제공합니다.
Azure Virtual Network는 Azure 개인 네트워크의 기본 빌딩 블록입니다. Virtual Network를 사용하면 VM과 같은 Azure 리소스가 보안이 강화된 상태에서 서로, 인터넷 및 온-프레미스 네트워크와 통신할 수 있도록 합니다. Azure Virtual Network는 온-프레미스에 있는 기존 네트워크와 유사하지만 스케일링 성능, 가용성 및 격리와 같은 Azure 인프라 이점이 포함되어 있습니다.
가상 네트워크 인터페이스를 사용하면 Azure VM이 인터넷, Azure 및 온-프레미스 리소스와 통신할 수 있습니다. 하나의 Azure VM에 여러 네트워크 인터페이스 카드를 추가하여 자식 VM이 고유한 전용 네트워크 인터페이스 디바이스와 IP 주소를 가질 수 있도록 할 수 있습니다.
Azure Managed Disks는 Azure가 Azure VM에서 관리하는 블록 수준 스토리지 볼륨을 제공합니다. 울트라 디스크, 프리미엄 SSD(반도체 드라이브), 표준 SSD 및 표준 HDD(하드 디스크 드라이브)를 사용할 수 있습니다.
Blob Storage는 클라우드용 개체 스토리지 솔루션입니다. Blob Storage는 대량의 비정형 데이터를 저장하는 데 최적화되어 있습니다.
Private Link를 사용하여 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure PaaS 서비스(예: Blob Storage 및 Key Vault)에 액세스할 수 있습니다. 또한 사용자가 소유하거나 Microsoft 파트너가 제공하는 Azure 호스트 서비스에 액세스하는 데도 사용할 수 있습니다.

대안

Azure Marketplace에서 Azure Firewall 대신 타사 방화벽을 사용할 수 있습니다. 그럴 경우, AKS 클러스터에서 인바운드 및 아웃바운드 트래픽을 검사하고 허용하거나 거부하도록 방화벽을 올바르게 구성하는 것은 사용자의 책임입니다.

시나리오 정보

AKS 클러스터는 관리 또는 사용자 지정이 가능한 가상 네트워크에 배포됩니다. 그럼에도 불구하고 클러스터에는 가상 네트워크 외부의 서비스에 대한 아웃바운드 종속성이 있습니다. 관리와 운영을 목적으로 AKS 클러스터 노드는 특정 포트 및 이러한 아웃바운드 종속성과 연결된 FQDN(정규화된 도메인 이름)에 액세스해야 합니다. 여기에는 사용자 고유의 클러스터의 Kubernetes API 서버에 액세스하고, 클러스터 구성 요소를 다운로드 및 설치하며, Microsoft Container Registry에서 컨테이너 이미지를 끌어와야 합니다. 이러한 아웃바운드 종속성은 FQDN으로 정의되며 정적 주소가 없으므로 네트워크 보안 그룹을 사용하여 아웃바운드 트래픽을 잠그는 것이 불가능합니다. 따라서 AKS 클러스터에는 기본적으로 무제한 아웃바운드(송신) 인터넷 액세스가 있어 노드 및 서비스가 필요에 따라 외부 리소스에 액세스할 수 있습니다.

그러나 프로덕션 환경에서는 일반적으로 데이터 반출 및 기타 원치 않는 네트워크 트래픽으로부터 Kubernetes 클러스터를 보호하는 것이 좋습니다. 들어오는 트래픽과 나가는 모든 네트워크 트래픽은 보안 규칙에 따라 제어되어야 합니다. 이를 위해서는 송신 트래픽을 제한하면서 일상적인 클러스터 유지 관리 작업, 아웃바운드 종속성 및 워크로드 요구 사항에 필요한 포트 및 주소에 대한 액세스를 허용해야 합니다.

간단한 솔루션은 도메인 이름을 기반으로 아웃바운드 트래픽을 제어할 수 있는 방화벽 디바이스를 사용하는 것입니다. 방화벽은 신뢰할 수 있는 네트워크와 인터넷 사이에 장벽을 만듭니다. Azure Firewall을 사용하여 대상의 FQDN, 프로토콜 및 포트에 따라 아웃바운드 트래픽을 제한하여 세분화된 송신 트래픽 제어를 제공합니다. 또한 AKS 클러스터의 아웃바운드 종속성과 연결된 FQDN에 대한 허용 목록을 사용할 수 있으며 네트워크 보안 그룹에서는 사용할 수 없습니다. 또한 공유 경계 네트워크에 배포된 Azure Firewall에서 위협 인텔리전스 기반 필터링을 통해 수신 트래픽을 제어하고 보안을 향상시킬 수 있습니다. 이러한 필터링은 경고를 생성하고 알려진 악성 IP 주소 및 도메인과 주고받는 트래픽을 거부할 수 있습니다.

Terraform 및 Azure DevOps를 사용하여 허브 스포크 네트워크 토폴로지에서 프라이빗 AKS 클러스터를 만들 수 있습니다. Azure Firewall는 AKS(Azure Kubernetes Service) 클러스터를 드나드는 트래픽을 검사하는 데 사용됩니다. 클러스터는 허브 가상 네트워크에 피어링된 하나 이상의 스포크 가상 네트워크에서 호스트됩니다.

Azure Firewall은 세 가지 SKU를 지원하여 광범위한 고객 사례 및 기본 설정에 맞춥니다.

Azure Firewall 프리미엄은 결제 처리와 같은 매우 중요한 애플리케이션을 보안하는 데 권장됩니다. 이것은 맬웨어 및 TLS 검사와 같은 고급 위협 차단 기능을 지원합니다.
Azure Firewall 표준은 계층 3-계층 7 방화벽을 찾고 최대 30Gbps의 최고 트래픽 기간을 처리하기 위해 자동 스케일링이 필요한 고객에게 권장됩니다. 이것은 위협 인텔리전스, DNS 프록시, 사용자 지정 DNS 및 웹 범주와 같은 엔터프라이즈 기능을 지원합니다.
Azure Firewall 기본은 필요한 처리량이 250Mbps 미만인 고객에게 권장됩니다.

다음 표에서는 세 가지 Azure Firewall SKU의 기능을 보여줍니다. 자세한 내용은 Azure Firewall 가격을 참조하세요.

세 가지 Azure Firewall SKU의 기능을 보여 주는 스크린샷

기본적으로 AKS 클러스터에는 무제한 아웃바운드 인터넷 액세스가 있습니다. 이 수준의 네트워크 액세스를 통해 AKS 클러스터에서 실행되는 노드와 서비스는 필요에 따라 외부 리소스에 액세스할 수 있습니다. 송신 트래픽을 제한하려면 정상적인 클러스터 유지 관리 작업을 유지할 수 있도록 제한된 수의 포트 및 주소에 계속 액세스할 수 있어야 합니다. AKS와 같은 Kubernetes 클러스터에서 아웃바운드 트래픽에 대한 보안을 제공하는 가장 쉬운 방법은 도메인 이름에 따라 아웃바운드 트래픽을 제어할 수 있는 소프트웨어 방화벽을 사용하는 것입니다. Azure Firewall은 대상의 FQDN(정규화된 도메인 이름)을 기반으로 아웃바운드 HTTP 및 HTTPS 트래픽을 제한할 수 있습니다. 이러한 필수 포트와 주소를 허용하도록 방화벽 및 보안 규칙을 구성할 수도 있습니다. 자세한 내용은 AKS에서 클러스터 노드의 송신 트래픽 제어를 참조하세요.

마찬가지로, 공유 경계 네트워크에 배포된 Azure Firewall에서 위협 인텔리전스 기반 필터링을 사용하도록 설정하여 수신 트래픽을 제어하고 보안을 향상시킬 수 있습니다. 이러한 필터링은 경고를 제공하고 알려진 악성 IP 주소 및 도메인과 주고받는 트래픽을 거부할 수 있습니다.

잠재적인 사용 사례

이 시나리오는 Kubernetes 클러스터에서 들어오고 나가는 인바운드 및 아웃바운드 트래픽의 보안을 개선해야 하는 필요성을 해결합니다.

비대칭 라우팅 방지

이 솔루션에서 Azure Firewall은 허브 가상 네트워크에 배포되고 프라이빗 AKS 클러스터는 스포크 가상 네트워크에 배포됩니다. Azure Firewall은 네트워크 및 애플리케이션 규칙 컬렉션을 사용하여 송신 트래픽을 제어합니다. 이러한 상황에서는 Azure Firewall에서 사용하는 공용 IP 주소 중 하나를 통해 시스템에 진입하기 위해 AKS에서 실행되는 모든 서비스에서 노출되는 모든 퍼블릭 엔드포인트에 대한 수신 트래픽을 구성해야 합니다.

패킷은 방화벽의 공용 IP 주소에 도착하지만 개인 IP 주소(기본 경로 사용)를 통해 방화벽으로 돌아갑니다. 이것은 문제입니다. 이를 방지하려면 다음 다이어그램과 같이 방화벽의 공용 IP 주소에 대한 다른 사용자 정의 경로를 만듭니다. 방화벽의 공용 IP 주소로 이동하는 패킷은 인터넷을 통해 라우팅됩니다. 이 구성에서는 방화벽의 개인 IP 주소로 가는 기본 경로를 사용하지 않습니다.

AKS 워크로드의 트래픽을 허브 가상 네트워크의 Azure Firewall로 라우팅하려면 다음을 수행해야 합니다.

클러스터의 작업자 노드를 호스트하는 각 서브넷에 경로 테이블을 만들고 연결합니다.
사용자 정의 경로를 만들어 0.0.0.0/0 CIDR의 트래픽을 Azure Firewall 개인 IP 주소로 전달합니다. 다음 홉 유형에 대한 가상 어플라이언스를 지정합니다.

자세한 내용은 자습서: Azure Portal을 사용하여 Azure Firewall 배포 및 구성을 참조하세요.

자세한 내용은 다음을 참조하세요.

Azure DevOps를 사용할 때 프라이빗 AKS 클러스터에 워크로드 배포

Azure DevOps를 사용하는 경우, Azure DevOps Microsoft에서 호스트된 에이전트를 사용하여 프라이빗 AKS 클러스터에 워크로드를 배포할 수 없음을 주의하세요. 이러한 에이전트는 API 서버에 액세스할 수 없습니다. 프라이빗 AKS 클러스터에 워크로드를 배포하려면 프라이빗 AKS 클러스터와 동일한 가상 네트워크나 피어링된 가상 네트워크에서 Azure DevOps 자체 호스팅 에이전트를 프로비저닝하고 사용해야 합니다. 후자의 경우 노드 리소스 그룹에 있는 AKS 클러스터의 프라이빗 DNS 영역과 Azure DevOps 자체 호스팅 에이전트를 호스트하는 가상 네트워크 간에 가상 네트워크 링크를 만들어야 합니다.

가상 머신에 단일 Windows 또는 Linux Azure DevOps 에이전트를 배포하거나, VMSS(가상 머신 확장 집합)를 사용할 수 있습니다. 자세한 내용은 Azure 가상 머신 확장 집합 에이전트를 참조하세요. 또는 Azure Pipelines에서 자체 호스팅 에이전트를 설정하여 Docker를 사용하여 Windows Server Core 컨테이너(Windows 호스트용) 또는 Ubuntu 컨테이너(Linux 호스트용) 내에서 실행할 수 있습니다. 프라이빗 AKS 클러스터에 하나 이상의 복제본이 있는 Pod로 배포합니다. 자세한 내용은 다음을 참조하세요.

프라이빗 AKS 클러스터의 노드 풀을 호스트하는 서브넷이 경로 테이블 및 사용자 정의 경로를 통해 송신 트래픽을 Azure Firewall로 라우팅하도록 구성된 경우 적절한 애플리케이션 및 네트워크 규칙을 만들어야 합니다. 이러한 규칙에서는 에이전트가 에이전트 가상 머신에 Docker, Kubectl, Azure CLI 및 Helm과 같은 도구를 다운로드하고 설치하기 위해 외부 사이트에 액세스할 수 있도록 허용해야 합니다. 자세한 내용은 Docker에서 자체 호스팅 에이전트 실행을 참조하세요.

또는 AKS 클러스터를 호스팅하는 가상 네트워크 또는 피어된 가상 네트워크에서 MDP(관리형 DevOps 풀)를 구성할 수 있습니다. 관리형 DevOps 풀을 통해 개발 팀은 특정 요구 사항에 맞게 조정된 Azure DevOps 에이전트 풀을 만들 수 있습니다. 보안 모범 사례를 구현하고, 비용과 성능의 균형을 맞추는 옵션을 제공하고, 일반적인 시나리오에 대한 경로를 제공하며, 사용자 지정 풀을 만들고 유지 관리하는 데 소요되는 시간을 크게 줄입니다. 자세한 내용은 Microsoft 관리형 DevOps 풀 아키텍처 개요를 참조하세요.

가상 네트워크의 관리형 DevOps 풀에서 에이전트를 추가하여 CI/CD 파이프라인이 프라이빗 AKS 클러스터의 Kubernetes API 서버와 상호 작용하고 공용 네트워크 액세스가 비활성화되고 동일한 가상 네트워크 또는 피어링된 네트워크에 정의된 프라이빗 엔드포인트를 통해서만 연결할 수 있는 Azure Container Registry와 같은 Azure 리소스에 액세스할 수 있습니다. 자세한 내용은 관리형 DevOps 풀 네트워킹 구성을 참조하세요.

퍼블릭 표준 Load Balancer 앞에서 Azure Firewall 사용

Terraform 모듈의 리소스 정의는 수명 주기 메타 인수를 사용하여 Azure 리소스가 Terraform 컨트롤 범위 밖에서 변경될 때 작업을 사용자 지정합니다. ignore_changes 인수는 Terraform에 태그와 같은 지정된 리소스 속성에 대한 업데이트를 무시하도록 지시하는 데 사용됩니다. Azure Firewall 정책 리소스 정의에는 규칙 컬렉션 또는 단일 규칙을 만들거나 업데이트하거나 삭제할 때 Terraform이 리소스를 업데이트하지 못하도록 하는 수명 주기 블록이 포함되어 있습니다. 마찬가지로 Azure 경로 테이블에는 사용자 정의 경로를 만들거나 삭제하거나 업데이트할 때 Terraform이 리소스를 업데이트하지 못하도록 하는 수명 주기 블록이 포함되어 있습니다. 이를 통해 Azure Firewall 정책의 DNAT, 애플리케이션 및 네트워크 규칙과 Terraform 컨트롤 외부의 Azure 경로 테이블의 사용자 정의 경로를 관리할 수 있습니다.

이 문서와 연결된 샘플에는 자체 호스팅 에이전트에서 실행되는 Azure DevOps 파이프라인을 사용하여 프라이빗 AKS 클러스터에 워크로드를 배포하는 방법을 보여 주는 Azure DevOps CD 파이프라인이 포함되어 있습니다. 샘플은 퍼블릭 Helm 차트를 사용하여 Bitnami redmine 프로젝트 관리 웹 애플리케이션을 배포합니다. 이 다이어그램은 샘플의 네트워크 토폴로지를 보여 줍니다.

메시지 흐름은 다음과 같습니다.

AKS 호스팅 웹 애플리케이션에 대한 요청은 공용 IP 구성을 통해 Azure Firewall에 의해 노출되는 공용 IP로 전송됩니다. 공용 IP와 공용 IP 구성은 모두 이 워크로드 전용입니다.
Azure Firewall DNAT 규칙은 Azure Firewall 공용 IP 주소와 공용 IP에 대한 포트를 노드 리소스 그룹에 있는 AKS 클러스터의 Kubernetes 퍼블릭 표준 Load Balancer에서 워크로드에 사용되는 공용 IP와 포트로 변환합니다.
부하 분산 장치는 AKS 클러스터의 에이전트 노드 중 하나에서 실행되는 Kubernetes 서비스 Pod 중 하나로 요청을 보냅니다.
응답 메시지는 사용자 정의 경로를 통해 원래 호출자에게 다시 전송됩니다. Azure Firewall 공용 IP는 주소 접두사이고, 인터넷은 다음 홉 유형입니다.
워크로드 시작 아웃바운드 호출은 기본 사용자 정의 경로에 의해 Azure Firewall의 개인 IP 주소로 라우팅됩니다. 0.0.0.0/0은 주소 접두사이고, 가상 어플라이언스는 다음 홉 유형입니다.

자세한 내용은 AKS 클러스터의 퍼블릭 표준 Load Balancer 앞에서 Azure Firewall 사용을 참조하세요.

내부 표준 Load Balancer 앞에서 Azure Firewall 사용

이 문서와 연결된 샘플에서 ASP.NET Core 애플리케이션은 AKS 클러스터에서 서비스로 호스트되고 NGINX 수신 컨트롤러에서 앞에 섰습니다. NGINX 수신 컨트롤러는 AKS 클러스터를 호스트하는 스포크 가상 네트워크에서 개인 IP 주소를 가지는 내부 Load Balancer를 통해 노출됩니다. 자세한 내용은 AKS에서 내부 가상 네트워크에 대한 수신 컨트롤러 만들기를 참조하세요. 메타데이터 섹션의 service.beta.kubernetes.io/azure-load-balancer-internal: "true" 주석을 사용하여 NGINX 수신 컨트롤러 또는 보다 일반적으로는 LoadBalancer 또는 ClusterIP 서비스를 배포하는 경우 노드 리소스 그룹 아래에 kubernetes-internal이라는 내부 표준 Load Balancer가 만들어집니다. 자세한 내용은 AKS에서 내부 Load Balancer 사용을 참조하세요. 다음 다이어그램과 같이 테스트 웹 애플리케이션은 전용 Azure 공용 IP를 통해 Azure Firewall에 의해 노출됩니다.

메시지 흐름은 다음과 같습니다.

AKS 호스팅 테스트 웹 애플리케이션에 대한 요청은 공용 IP 구성을 통해 Azure Firewall에 의해 노출되는 공용 IP로 전송됩니다. 공용 IP와 공용 IP 구성은 모두 이 워크로드 전용입니다.
Azure Firewall DNAT 규칙은 Azure Firewall 공용 IP와 포트를 노드 리소스 그룹에 있는 AKS 클러스터의 내부 표준 Load Balancer에서 사용되는 개인 IP와 포트로 변환합니다.
내부 부하 분산 장치는 AKS 클러스터의 에이전트 노드 중 하나에서 실행되는 Kubernetes 서비스 Pod 중 하나로 요청을 보냅니다.
응답 메시지는 사용자 정의 경로를 통해 원래 호출자에게 다시 전송됩니다. 0.0.0.0/0은 주소 접두사이고, 가상 어플라이언스는 다음 홉 유형입니다.
워크로드 시작 아웃바운드 호출은 사용자 정의 경로의 개인 IP 주소로 라우팅됩니다.

자세한 내용은 내부 표준 Load Balancer 앞에서 Azure Firewall 사용을 참조하세요.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

다음 고려 사항 중 일부는 AKS 클러스터의 보호를 개선하기 위해 Azure Firewall을 사용하는 것과 관련이 없는 일반적인 권장 사항입니다. 이러한 고려 사항은 이 솔루션의 필수적인 요구 사항이라고 생각합니다. 이 사항은 보안, 성능, 가용성 및 안정성, 스토리지, 서비스 메시, 모니터링 고려 사항에 적용됩니다.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

Azure 플랫폼은 네트워크 침입 및 DDoS(분산 서비스 거부) 공격 등 다양한 위협에 대해 향상된 보호 기능을 제공합니다. 퍼블릭 HTTPS 엔드포인트를 노출하는 AKS 호스팅 웹 애플리케이션 및 서비스를 보호하려면 WAF(Web Application Firewall)를 사용해야 합니다. SQL 삽입, 사이트 간 스크립팅 및 기타 웹 익스플로잇과 같은 일반적인 위협으로부터 보호해야 합니다. 이렇게 하려면 OWASP(Open Web Application Security Project) 규칙 및 사용자 지정 규칙을 사용하세요. Azure Web Application Firewall은 일반적인 악용과 취약성으로부터 웹 애플리케이션을 중앙 집중식으로 보호합니다. Azure Application Gateway, Azure Front Door 및 Azure Content Delivery Network를 사용하여 Azure WAF를 배포할 수 있습니다.

DDoS 공격은 조직이 애플리케이션을 클라우드로 전환하게 만드는 가장 큰 가용성 및 보안 문제입니다. DDoS 공격은 애플리케이션의 리소스를 소진시켜서 정상적인 사용자가 애플리케이션을 사용할 수 없게 생성합니다. DDoS 공격은 인터넷을 통해 공개적으로 도달할 수 있는 모든 엔드포인트를 대상으로 할 수 있습니다. Azure의 모든 속성에는 추가 비용 없이 Azure DDoS 인프라 보호를 통한 보호가 포함됩니다. 전역 배포 Azure 네트워크의 스케일과 용량은 항상 작동하는 트래픽 모니터링 및 실시간 위험 완화를 통해 일반적인 네트워크 계층 공격에 대해 향상된 방어 기능을 제공합니다. DDoS 인프라 보호는 사용자 구성 또는 애플리케이션 변경이 필요 없습니다. 이를 통해 Azure DNS 같은 PaaS 서비스를 포함한 모든 Azure 서비스를 보호할 수 있습니다.

애플리케이션 설계 모범 사례와 결합된 Azure DDoS 네트워크 보호는 향상된 DDoS 완화 기능을 제공하여 DDoS 공격에 대한 방어력을 높입니다. 경계 가상 네트워크에서 Azure DDOS 네트워크 보호를 사용하도록 설정해야 합니다.

다음은 몇 가지 추가 보안 고려 사항입니다.

Key Vault, Azure Service Bus 또는 Azure SQL Database와 같은 AKS 워크로드에서 사용되는 모든 PaaS 서비스에 대한 프라이빗 엔드포인트를 만드세요. 애플리케이션과 이러한 서비스 간의 트래픽이 공용 인터넷에 노출되지 않습니다. 프라이빗 엔드포인트를 통한 AKS 클러스터 가상 네트워크와 PaaS 서비스 인스턴스 간의 트래픽은 Microsoft 백본 네트워크를 이동하지만 그 통신은 Azure Firewall에 의해 전달되지 않습니다. 이 메커니즘은 데이터 유출에 대한 향상된 보안 및 보호 기능을 제공합니다. 자세한 내용은 Azure Private Link란?을 참조하세요.
AKS 클러스터 앞에서 Application Gateway를 사용할 때 Web Application Firewall 정책을 사용하여 AKS에서 실행되는 공용 워크로드를 공격으로부터 보호할 수 있습니다.
네트워크 정책을 사용하여 서로 통신할 수 있는 구성 요소를 제어하여 서비스 내 통신을 분리하고 보안을 지원합니다. 기본적으로 Kubernetes 클러스터의 모든 Pod는 제한 없이 트래픽을 보내고 받을 수 있습니다. 보안을 개선시키기 위해 Azure 네트워크 정책 또는 Calico 네트워크 정책을 사용하여 서로 다른 마이크로 서비스 간의 트래픽 흐름을 제어하는 규칙을 정의할 수 있습니다. 자세한 내용은 네트워크 정책을 참조하세요.
AKS 노드에 대한 원격 연결을 노출하지 마십시오. 관리 가상 네트워크에서 요새 호스트 또는 점프 상자를 만듭니다. 베스천 호스트를 사용하여 트래픽을 AKS 클러스터로 라우팅하세요.
프로덕션 환경에서 프라이빗 AKS 클러스터를 사용하거나 적어도 AKS에서 승인된 IP 주소 범위를 사용하여 API 서버에 대한 보안 액세스를 고려합니다. 퍼블릭 클러스터에서 승인된 IP 주소 범위를 사용하는 경우 Azure Firewall 네트워크 규칙 컬렉션의 모든 송신 IP 주소를 허용합니다. 클러스터 내 작업은 Kubernetes API 서버를 사용합니다.
Azure Firewall에서 DNS 프록시를 사용하도록 설정하면 Azure Firewall은 하나 이상의 가상 네트워크에서 선택한 DNS 서버로 DNS 쿼리를 처리하고 전달할 수 있습니다. 이 기능은 중요하며 네트워크 규칙에서 신뢰할 수 있는 FQDN 필터링에 필요합니다. Azure Firewall 및 방화벽 정책 설정에서 DNS 프록시를 사용하도록 설정할 수 있습니다. DNS 프록시 로그에 대해 자세히 알아보려면 Azure Firewall 로그 및 메트릭을 참조하세요.
Application Gateway 앞에서 Azure Firewall을 사용할 때 HTTPS를 통해 워크로드를 노출하도록 Kubernetes 수신 리소스를 구성하고, 각 테넌트마다 별도의 개별 하위 도메인 및 디지털 인증서를 사용할 수 있습니다. AGIC(Application Gateway 수신 컨트롤러)는 SSL(Secure Sockets Layer) 종료를 위해 Application Gateway 수신기를 자동으로 구성합니다.
NGINX 수신 컨트롤러와 같은 서비스 프록시 앞에서 Azure Firewall을 사용할 수 있습니다. 이 컨트롤러는 역방향 프록시, 구성 가능한 트래픽 라우팅, Kubernetes 서비스에 대한 TLS 종료를 제공합니다. Kubernetes 수신 리소스는 개별 Kubernetes 서비스에 대한 수신 규칙 및 라우팅을 구성하는 데 사용됩니다. 수신 컨트롤러 및 수신 규칙을 사용하면 단일 IP 주소를 사용하여 Kubernetes 클러스터의 여러 서비스에 트래픽을 라우팅할 수 있습니다. 인식된 인증 기관을 사용하여 TLS 인증서를 생성할 수 있습니다. 또는 Let's Encrypt를 사용하여 동적 공용 IP 주소 또는 정적 공용 IP 주소로 TLS 인증서를 자동으로 생성할 수 있습니다. 자세한 내용은 AKS에 HTTPS 수신 컨트롤러를 만들고 고유한 TLS 인증서 사용을 참조하세요.
워크로드 및 클러스터 요구가 진화함에 따라 초기 클러스터 배포의 경우와 이후 지속적인 방식으로 Azure Firewall 운영자와 클러스터 및 워크로드 팀 간의 엄격한 조정이 필요합니다. 특히 워크로드에서 클라이언트를 인증하는 데 사용되는 OAuth 2.0 및 OpenID Connect와 같은 인증 메커니즘을 구성할 때 그렇습니다.
다음 지침을 사용하여 이 문서에 설명된 환경을 보호할 수 있습니다.

가용성 및 안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.

여기서 가용성 및 안정성 고려 사항은 AKS의 다중 테넌시에만 국한되지 않습니다. 이러한 고려 사항은 이 솔루션의 필수 요구 사항이라고 생각합니다. AKS 클러스터 및 워크로드의 가용성을 최적화하기 위한 다음 방법을 고려합니다.

지역 내 복원력

배포 중 가용성을 높이기 위해 여러 가용성 영역에 걸쳐 Azure Firewall을 구성할 수 있습니다. 작동 시간 비율은 Azure Firewall SLA를 참조하세요. SLA에 영향을 주기는 하지만 근접성을 위해 Azure Firewall을 특정 영역과 연결할 수도 있습니다. 가용성 영역 간 데이터 전송을 포함하여 가용성 영역에 배포된 방화벽에 대한 추가 비용은 없습니다.
지역의 모든 가용성 영역에 AKS 클러스터의 노드 풀을 배포하는 것이 좋습니다. 노드 풀 앞에서 Azure 표준 Load Balancer 또는 Application Gateway를 사용합니다. 이 토폴로지는 단일 데이터 센터 중단이 있는 경우 향상된 복원력을 제공합니다. 클러스터 노드는 지역 내 3개의 개별 가용성 영역에 있는 여러 데이터 센터에 분산됩니다.
지역 내 복원력 및 고가용성을 위해 Container Registry에서 영역 중복성을 사용하도록 설정합니다.
Pod 토폴로지 확산 제약 조건을 사용하여 지역, 가용성 영역, 노드와 같은 장애 도메인 간에 AKS 클러스터에서 Pod가 분산되는 방식을 제어합니다.
중요 업무용 워크로드를 호스팅하는 AKS 클러스터에 대해 작동 시간 SLA를 사용하는 것이 좋습니다. 작동 시간 SLA는 재정적 지원을 받는 상위 SLA를 클러스터에 설정하는 선택적 기능입니다. 작동 시간 SLA는 가용성 영역을 사용하는 클러스터에 대해 Kubernetes API 서버 엔드포인트의 높은 가용성을 보장합니다. 가용성 영역을 사용하지 않는 클러스터에도 사용할 수 있지만 SLA는 더 낮습니다. SLA 세부 정보는 작동 시간 SLA를 참조하세요. AKS는 업데이트 및 장애 도메인에서 마스터 노드 복제본을 사용하여 SLA 요구 사항을 충족하는지 확인합니다.

재해 복구 및 비즈니스 연속성

한 지역 내에서 최소 두 쌍의 Azure 지역에 솔루션을 배포하는 것이 좋습니다. 비즈니스 연속성 및 재해 복구를 보장하기 위해 활성/활성 또는 활성/수동 라우팅 방법으로 Azure Traffic Manager 또는 Azure Front Door와 같은 글로벌 부하 분산 장치를 사용합니다.
Azure Firewall는 지역별 서비스입니다. 둘 이상의 지역에 솔루션을 배포하는 경우 각 지역에 Azure Firewall을 만들어야 합니다. 모든 지역 허브에 적용되는 조직이 요구하는 규칙을 포함하도록 전역 Azure Firewall 정책을 만들 수 있습니다. 이 정책을 지역 Azure 정책의 부모 정책으로 사용할 수 있습니다. 비어 있지 않은 부모 정책을 사용하여 만든 정책은 부모 정책의 모든 규칙 컬렉션을 상속합니다. 부모 정책에서 상속된 네트워크 규칙 컬렉션에는 항상 새 정책의 일부로 정의된 네트워크 규칙 컬렉션보다 높은 우선 순위가 지정됩니다. 애플리케이션 규칙 컬렉션에도 동일한 논리가 적용됩니다. 그러나 네트워크 규칙 컬렉션은 상속과 관계없이 항상 애플리케이션 규칙 컬렉션보다 먼저 처리됩니다. 표준 및 프리미엄 정책에 대한 자세한 내용은 Azure Firewall Manager 정책 개요를 참조하세요.
QA 환경에서 지역 장애 조치(failover) 프로세스를 스크립팅, 문서화 및 주기적으로 테스트해야 합니다. 이렇게 하면 핵심 서비스가 주 지역의 중단으로 영향을 받는 경우 예측할 수 없는 문제를 방지하는 데 도움이 됩니다. 또한 이러한 테스트는 장애 조치(failover)에 필요한 최종 수동 프로세스 및 개입과 함께 DR 접근 방식이 RPO/RTO 대상을 충족하는지 여부를 검사합니다.
장애 복구 프로시저를 테스트하여 예상대로 작동하는지 확인해야 합니다.
Container Registry에서 컨테이너 이미지를 저장합니다. 레지스트리를 각 AKS 지역에 지역 복제합니다. 자세한 내용은 Azure Container Registry의 지역에서 복제를 참조하세요.
가능하면 컨테이너에 서비스 상태를 저장하지 마세요. 대신, 다중 지역 복제를 지원하는 Azure PaaS를 사용합니다.
Azure Storage를 사용하는 경우 주 지역에서 백업 지역으로 스토리지를 마이그레이션하는 프로세스를 준비하고 테스트합니다.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.

DevOps

CI/CD(연속 통합 및 지속적인 업데이트) 파이프라인에서 Helm 차트를 사용하여 워크로드를 AKS에 배포합니다. GitHub Actions 또는 Azure DevOps와 같은 DevOps 시스템을 사용합니다. 자세한 내용은 Azure Kubernetes Service 빌드 및 배포를 참조하세요.
애플리케이션을 사용자에게 사용할 수 있게 하기 전에 적절하게 테스트하려면 애플리케이션 수명 주기 관리에서 A/B 테스트 및 카나리아 배포를 사용하세요. 동일한 서비스의 서로 다른 버전 간에 트래픽을 분할하는 데 사용할 수 있는 몇 가지 기술이 있습니다. 대안으로 서비스 메시 구현에서 제공하는 트래픽 분할 기능을 사용할 수 있습니다. 자세한 내용은 Linkerd Traffic Split 및 Istio Traffic Management를 참조하세요.
Azure Container Registry 또는 다른 컨테이너 레지스트리(예: Docker Hub)를 사용하여 클러스터에 배포된 프라이빗 Docker 이미지를 저장합니다. AKS는 Microsoft Entra ID를 사용하여 Azure Container Registry로 인증할 수 있습니다.
프로덕션 환경의 네트워크 토폴로지 및 방화벽 규칙을 미러링하는 별도의 사전 프로덕션 환경에서 워크로드의 수신 및 송신을 테스트합니다. 단계적 롤아웃 전략은 새 기능 또는 네트워크 규칙을 프로덕션으로 릴리스하기 전에 네트워킹 또는 보안 문제를 검색하는 데 도움이 됩니다.

모니터링

Azure Firewall이 방화벽에 의해 처리되는 수신 및 발신 트래픽을 로깅할 수 있도록 Azure Monitor와 완전히 통합됩니다. 자세한 내용은 Azure Firewall 위협 인텔리전스 기반 필터링을 참조하세요.

다음 모니터링 고려 사항은 AKS의 다중 테넌시에만 국한되지 않고, 이 솔루션의 필수 요구 사항이라고 생각합니다.

컨테이너 인사이트를 사용하여 AKS 클러스터 및 워크로드의 상태를 모니터링합니다.
진단 로그 및 메트릭을 수집하도록 모든 PaaS 서비스(예: Container Registry 및 Key Vault)를 구성합니다.

비용 최적화

결과 아키텍처의 비용은 다음 구성 세부 정보에 따라 다릅니다.

서비스 계층
스케일링 성능(주어진 수요를 지원하기 위해 서비스에 의해 동적으로 할당되는 인스턴스 수)
자동화 스크립트
재해 복구 수준

이러한 구성 세부 정보를 평가한 후, Azure 가격 계산기를 사용하여 비용을 예측합니다. 가격 최적화 옵션에 대한 자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 최적화 원칙을 참조하세요.

시나리오 배포

이 시나리오의 소스 코드는 GitHub에서 사용할 수 있습니다. 이 솔루션은 오픈 소스이며 MIT 라이선스와 함께 제공됩니다.

필수 구성 요소

온라인 배포의 경우 Azure 계정이 필요합니다. 구독이 없으면 시작하기 전에 체험 Azure 계정을 만듭니다. Azure DevOps를 사용하여 Terraform 모듈을 배포하려면 다음 요구 사항을 충족해야 합니다.

Terraform 상태 파일을 Azure Storage 계정에 저장합니다. 스토리지 계정을 사용하여 원격 Terraform 상태, 상태 잠금 및 미사용 암호화를 저장하는 방법에 대한 자세한 내용은 Azure Storage에 Terraform 상태 저장을 참조하세요.
Azure DevOps 프로젝트를 만듭니다. 자세한 내용은 Azure DevOps에서 프로젝트 만들기를 참조하세요.
Azure 구독에 대한 Azure DevOps 서비스 연결을 만듭니다. 서비스 연결을 만들 때 SPA(서비스 주체 인증) 또는 Azure Managed Service ID를 사용할 수 있습니다. 두 경우 모두 Azure DevOps에서 Azure 구독에 연결하는 데 사용하는 서비스 주체 또는 관리형 ID에 전체 구독의 소유자 역할이 할당되어 있어야 합니다.

Azure에 배포

Azure 구독 정보를 준비합니다.

워크벤치 GitHub 리포지토리를 복제합니다.

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

README.md 파일에 제공된 지침을 따릅니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

Paolo Salvatori | 수석 서비스 엔지니어

비공용 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

Microsoft Azure Well-Architected Framework에서 AKS에 대한 권장 사항 및 모범 사례를 검토합니다.

다음을 통해 공유

Azure Firewall을 사용하여 AKS(Azure Kubernetes Service) 클러스터 보호

아키텍처