쿠버네티스로 효과적인 컨테이너 마이크로세그멘테이션 전략을 설계하고 구현하는 방법

마이크로세분화는 대규모로 구현하기 어려운 것으로 여겨지는 경우가 많습니다. 전체 클라우드 패브릭의 모든 단일 워크로드에 세그먼트(신뢰 경계)를 만드는 것이 목표라면 아키텍처 단계에서 몇 가지 요소를 고려해야 합니다. 베어 메탈 또는 가상 머신으로 배포되는 호스트는 익숙한 엔티티이며, 네트워킹 및 보안 관점에서 그 동작이 잘 알려져 있습니다. 그러나 전체 아키텍처에 컨테이너 환경을 포함하면 기존 네트워크 및 보안 아키텍처에서는 일반적으로 중요하지 않은 몇 가지 주의 사항이 도입될 수 있습니다.

전체 하이브리드 클라우드에 컨테이너를 배포하면 결국 보안과 관련하여 몇 가지 질문이 떠오르게 됩니다:

• 모든 컨테이너 워크로드에서 마이크로세그멘테이션의 배포와 관리를 자동화하려면 어떻게 해야 하나요?
• 베어메탈 및 VM 호스트를 관리하는 데 사용되는 기존 보안 도구에 컨테이너 세분화 정책 및 자동화를 포함하려면 어떻게 해야 하나요?
• 컨테이너용과 기타 모든 것을 위한 두 개의 서로 다른 마이크로세분화 솔루션을 관리해야 하나요?

컨테이너는 네트워크 및 보안 관점에서 이상하게 작동할 수 있습니다. 예를 들어, 파드가 갑자기 죽었다가 나중에 다른 IP 주소로 자동으로 다시 스핀업될 수 있습니다. 반면에 서비스는 파드 앞에 배포되며 로드 밸런서처럼 작동합니다. 그렇다면 이 중 어떤 엔티티에 대해 세그먼트를 정의해야 할까요? 네임스페이스는 이러한 엔티티에 걸쳐 있을 수 있는데, 이를 어떻게 세분화할 수 있을까요? 그리고 모든 것이 완전히 배포되면 얼마나 많은 워크로드가 생성되나요?

컨테이너는 그 자체로 이해하기 어려운 주제일 수 있으며, 컨테이너로 마이크로세분화 '문제'를 해결하려고 하면 문제가 더욱 복잡해지기 쉽습니다.

아키텍처가 발전함에 따라 현재의 보안 전략을 깨뜨리거나 실수로 장애물을 발생시키지 않고 기존 환경에 컨테이너를 도입하려면 어떻게 마이크로세그멘테이션 문제를 해결할 수 있을까요?

다행히도 이 문제는 해결할 수 있는 문제입니다. 설명해 드리겠습니다.

기존 마이크로세분화 전략에 컨테이너를 추가할 때 고려할 사항

컨테이너와 마이크로세그멘테이션에 대한 대화를 시작하기 좋은 곳은 규모를 다루는 것입니다. 전체 하이브리드 클라우드에서 모든 워크로드에 대한 세분화 전략을 설계할 때 확장성은 항상 중요한 주의 사항입니다. 전체 환경이 얼마나 커질까요?

일반적으로 이 질문에 대한 답은 베어메탈과 VM 등 모든 호스트를 합산한 다음, 향후 예상되는 성장을 수용하기 위해 호스트 수를 두 배 또는 세 배로 늘리는 것입니다. 일부 애플리케이션은 호스트 또는 VM 클러스터에서 실행되기 때문에 이 숫자는 약간 모호할 수 있으며, 하나의 호스트가 항상 하나의 워크로드와 같지는 않습니다. 그러나 워크로드와 호스트를 동일시하는 것은 확장 수치를 추정하는 데 유용한 벤치마크입니다. 그런 다음 이 최종 총 수를 특정 마이크로세분화 공급업체가 지원할 수 있는 관리 워크로드의 상한과 비교합니다.

베어 메탈 호스트는 자주 마이그레이션하지 않기 때문에 세그먼트를 정의하기에 매우 정적인 엔티티입니다. 반면에 가상 머신은 예측하기 어려울 수 있습니다. 예를 들어, 네트워크 세그먼트 간에 동적으로 스핀업 및 스핀다운하고, 네트워크 세그먼트 간에 마이그레이션하고, 수명 주기 동안 여러 IP 주소를 할당할 수 있습니다. 따라서 총 호스트 수는 약간 유동적입니다. 즉, 일반적으로 관리 및 세분화해야 하는 총 워크로드 수에 도달하기 위해 클라우드에서 얼마나 많은 가상 머신이 활성화될 것으로 예상되는지 추정할 수 있습니다. 이 최종 숫자는 수백 명 또는 수천 명에 이르는 경우가 많습니다.  

따라서 여러 마이크로세분화 공급업체가 지원할 수 있는 최대 규모 제한을 고려할 때 이러한 최대 수치는 종종 "충분하다"고 보일 수 있습니다. 예를 들어, 현재 클라우드에서 1,000개의 워크로드를 실행 중이고 향후 몇 년 동안 이 숫자가 두 배 또는 세 배로 늘어날 수 있다면 특정 공급업체의 관리 워크로드 상한선인 20,000개에 곧 도달할 것이라는 우려는 거의 없을 것입니다. 큰 숫자는 멀리 있는 문제로 여겨집니다.

하지만 그림에 컨테이너를 추가하면 어떻게 될까요? 컨테이너화된 워크로드는 VM 및 베어메탈 호스트와 다르게 동작하는 컴퓨팅 인스턴스입니다.

예를 들어, Kubernetes는 컨테이너를 실행하는 기본 호스트(VM 또는 베어메탈)를 "노드"라고 부릅니다. 각 노드에는 하나 이상의 "포드"가 생성되며, 각 포드 내에서 실제 컨테이너 런타임 인스턴스가 실행됩니다. 쿠버네티스는 특정 노드에 최대 110개의 파드를 배포할 것을 권장합니다.

따라서 클라우드에 100개의 노드가 있고 각 노드가 110개의 파드를 실행하는 경우, 어떻게든 별개의 세그먼트로 정의해야 하는 11,000개의 가능한 컴퓨팅 인스턴스가 발생할 수 있습니다. 200개의 노드가 있는 경우 22,000개의 컴퓨팅 인스턴스를 사용할 수 있습니다. 컨테이너 환경에서 200개의 노드만 있으면 22,000개의 가능한 워크로드 세그먼트를 생성할 수 있다는 점을 다시 한 번 강조합니다.

그리고 이것은 컨테이너 환경에만 해당됩니다. 예상되는 관리형 워크로드 수와 가능한 세그먼트를 추정하려면 전체 하이브리드 클라우드에 걸쳐 컨테이너화되지 않은 모든 워크로드를 추가해야 합니다. 여기서 얻은 교훈은 여러 마이크로세분화 공급업체가 지원할 수 있는 최대 관리 워크로드 수가 더 이상 달성 불가능해 보이지 않는다는 것입니다.

컨테이너와 비컨테이너 모두를 위한 하나의 솔루션

컨테이너 환경을 세분화하는 방법을 고려할 때, Kubernetes 또는 OpenShift의 클러스터 내 및 클러스터 간 마이크로세그멘테이션을 지원하는 여러 공급업체가 있습니다. 그러나 이러한 솔루션은 대부분 컨테이너 환경에만 초점을 맞추고 있으며 하이브리드 클라우드 전반의 비컨테이너 워크로드에는 적용되지 않습니다. 그리고 실제로 컨테이너 워크로드가 있는 대부분의 네트워크에는 컨테이너화되지 않은 워크로드, 베어메탈 및 가상 머신이 모두 동일한 클라우드 패브릭에 공존하고 있습니다.

컨테이너를 위한 하나의 세분화 솔루션과 베어메탈 및 가상 머신을 위한 다른 세분화 솔루션을 배포하는 경우, 그 결과 두 솔루션 간에 이벤트를 자동화하거나 상호 연관시키지 않는 두 개의 서로 다른 도구 세트가 생성됩니다. 이 접근 방식은 소규모에서는 효과적일 수 있지만 배포 규모가 커지면 운영 및 관리가 어려워집니다. 워크로드 세분화에 대한 이러한 사일로화된 접근 방식은 피해야 합니다. 모든 워크로드 세분화를 배포하고 관리하기 위한 통합 솔루션을 만들려면 전체 컴퓨팅 패브릭에서 컨테이너화된 워크로드를 동일한 방식으로 관리해야 합니다.

예를 들어 Illumio는 베어메탈에서 가상머신, 컨테이너에 이르기까지 모든 워크로드에서 작동합니다. 컨테이너화된 워크로드와 컨테이너화되지 않은 워크로드 간에 기능 차이가 없으므로 모든 워크로드에 대해 시각화, 자동화 및 정책 관리 기능을 갖춘 마이크로세그멘테이션을 사용할 수 있습니다.

네임스페이스, 포드 또는 서비스?

쿠버네티스는 송신 및 수신 네트워크 트래픽을 제어할 수 있는 세 가지 주요 컨테이너 엔티티인 파드, 서비스 또는 네임스페이스를 정의합니다. (참고: 노드는 이러한 엔티티 간의 목적지로 간주되지 않으며, 클러스터는 노드 모음을 둘러싼 가장 넓은 경계로 정의됩니다). 또한 클러스터 경계에 로드 밸런서가 배포되어 있는 경우가 많으므로 세그먼트화할 수 있는 엔티티가 네 개가 될 수 있습니다. 마이크로세그멘테이션 아키텍처를 정의할 때 다음 중 어떤 엔티티를 세그먼트로 분류해야 하나요? 일부 또는 전부?

파드는 쿠버네티스에서 IP 주소를 할당할 수 있는 가장 작은 엔티티입니다. 컨테이너 런타임 인스턴스는 하나 이상의 파드에서 실행되며, 종종 이러한 파드는 서로 통신해야 합니다. 각 파드는 세그먼트로 정의할 수 있지만, 문제는 Kubernetes가 스핀다운했다가 나중에 스핀업할 수 있기 때문에 네트워킹 관점에서 볼 때 대상 또는 소스 IP 주소가 갑자기 사라질 수 있다는 점입니다. 네트워크 및 보안 팀은 전체 패브릭에서 엔티티가 갑자기 사라져 경로 통합 및 보안 도구를 다루기가 어려워지는 것을 좋아하지 않습니다.

쿠버네티스는 주어진 수의 파드 앞에 배포되는 서비스를 배포하여 그 뒤에 있는 파드의 로드 밸런서처럼 작동할 수 있습니다. 서비스는 훨씬 더 안정적이며, Kubernetes는 동적으로 파드를 스핀업 및 스핀다운할 수 있지만, 서비스에서는 거의 그렇게 하지 않습니다. 따라서 서비스를 개별 파드가 아닌 세그먼트로 정의하는 것이 가장 좋습니다.

마이크로세그멘테이션 공급업체에 파드 또는 서비스를 세그먼트로 정의할 수 있는지 문의하여 보안 관리자에게 선택을 맡기는 것이 중요합니다.

컨테이너에 배포된 애플리케이션은 일반적으로 네임스페이스로 배포되며, 코드는 기본적으로 하나 이상의 포드 내에서 분산된 방식으로 실행됩니다. 컨테이너 네임스페이스는 여러 파드와 서비스에 걸쳐 추상화된 것이다.

예를 들어 Illumio를 사용하면 네임스페이스에 대해 '프로필'을 정의한 다음 이 프로필을 세그먼트로 정의할 수 있습니다. 그 결과, Illumio는 세그먼트의 정의를 포드, 서비스 또는 네임스페이스에 대해 정의할 수 있게 해줍니다. 또한 컨테이너화된 환경을 위해 특별히 설계된 마이크로세그멘테이션 도구와 달리 Illumio는 기본 호스트, 클러스터 경계의 진입/진출 지점, 컨테이너 내의 리소스에 액세스해야 하는 주변 레거시 워크로드에 대해 세그먼트를 정의할 수도 있습니다. 세그먼트는 컨테이너 내에만 존재하는 것이 아니라 전체 클라우드 패브릭에 걸쳐 존재합니다.

따라서 마이크로세분화 공급업체가 100,000개 이상의 워크로드를 관리할 수 있는지 확인해야 합니다. 클라우드 패브릭에 더 많은 컨테이너 환경이 배포될수록 이러한 높은 수치는 더 빨리 주목받게 됩니다. 그리고 이러한 수치는 컨테이너에서 워크로드가 동적으로 생겼다가 사라지는 일시적인 워크로드로 구성되는 경우가 많습니다. 즉, 마이크로세분화 솔루션은 실시간으로 변화에 대응해야 합니다.

컨테이너 클러스터에 배포된 Illumio의 Kubelink 인스턴스를 사용하면 배포 및 해제되는 워크로드를 동적으로 검색하고, 애플리케이션 종속성 맵을 활성화하며, 관리 중인 워크로드의 모든 변경 사항에 실시간으로 대응할 수 있는 도구를 적용할 수 있습니다. 자동화와 오케스트레이션은 컨테이너에서 중요한 두 가지 개념이며, Illumio는 컨테이너 환경 내외부에서 마이크로세그멘테이션 관리를 운영하기 위해 이 두 가지를 모두 구현합니다.

클라우드에 컨테이너를 배포한다고 해서 배포 방식에 관계없이 워크로드를 중심으로 세그먼트를 정의할 수 있는 기능을 희생해서는 안 됩니다. 세분화 솔루션이 컨테이너화된 워크로드에 따라 장애 없이 계속해서 높은 수치로 확장할 수 있는지 확인하세요. 일루미오 코어를 사용하면 규모에 관계없이 전체 클라우드 패브릭의 모든 워크로드에 대해 제로 트러스트를 달성할 수 있습니다.

더 알고 싶으신가요? 일루미오 코어가 Kubernetes와 OpenShift를 어떻게 보호하는지 알아보세요.

지금 바로 문의하여 Illumio 제로 트러스트 세분화로 컨테이너를 보호하는 방법을 알아보세요.