Kubernetes를 사용하여 효과적인 컨테이너 마이크로세그멘테이션 전략을 설계하고 구현하는 방법

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

전체 하이브리드 클라우드에 컨테이너를 배포하면 결국 보안과 관련된 몇 가지 질문이 생깁니다.

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

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

컨테이너는 그 자체로는 이해하기 어려운 주제일 수 있습니다. 컨테이너를 사용하여 마이크로세그멘테이션 “문제”를 해결하려고 하면 문제가 훨씬 더 복잡해질 수 있습니다.

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

다행히도, 이것은 입니다 해결할 수 있는 문제.설명해 드릴게요.

기존 마이크로세그멘테이션 전략에 컨테이너를 추가할 때의 고려 사항

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

일반적으로 이 질문에 대한 답은 모든 호스트 (베어메탈 및 VM) 를 합한 다음 향후 예상되는 성장에 맞춰 그 수를 두 배 또는 세 배로 늘리는 것입니다.일부 애플리케이션은 호스트 또는 VM의 클러스터에서 실행되기 때문에 이 수치는 다소 모호할 수 있습니다. 하나의 호스트가 항상 하나의 워크로드와 같지는 않습니다.하지만 워크로드를 호스트와 동일시하는 것은 규모 조정 기준을 추정하는 데 유용한 벤치마크입니다.그런 다음 최종 총 수를 특정 마이크로세그멘테이션 공급업체가 지원할 수 있는 관리형 워크로드의 상한선과 비교합니다.

베어메탈 호스트는 자주 마이그레이션되지 않으므로 세그먼트를 정의하는 데 상당히 정적인 엔티티입니다.반면 VM은 예측이 다소 어려울 수 있습니다.예를 들어 VM을 동적으로 스핀업/다운하고, 네트워크 세그먼트 간에 마이그레이션하고, 라이프사이클 전반에 걸쳐 여러 IP 주소를 할당할 수 있습니다.따라서 전체 호스트 수는 약간 유동적일 것입니다.그렇긴 하지만, 일반적으로 관리 및 분할해야 하는 총 워크로드 수에 도달하기 위해 클라우드에서 활성화될 것으로 예상되는 VM 수를 추정할 수 있습니다.최종 수치는 수백 개 또는 수천 개에 이르는 경우가 많습니다.

따라서 여러 마이크로세그멘테이션 공급업체가 지원할 수 있는 상한선을 고려할 때 이러한 최대 수는 종종 “충분히 괜찮은” 것처럼 보일 수 있습니다.예를 들어 클라우드에서 현재 1,000개의 워크로드가 실행되고 있는데 이 수가 향후 몇 년 동안 두 배 또는 세 배로 증가할 수 있다면, 조만간 특정 공급업체의 관리 워크로드 상한선인 20,000개에 도달할 염려는 거의 없을 것입니다.숫자가 많더라도 문제가 되는 것은 아닙니다.

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

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

따라서 Kubernetes를 실행하는 100개의 노드가 있고 각 노드에서 110개의 포드를 실행하는 경우, 어떤 식으로든 별개의 세그먼트로 정의해야 하는 11,000개의 컴퓨팅 인스턴스가 생길 수 있습니다.노드가 200개인 경우 22,000개의 가능한 컴퓨팅 인스턴스가 생길 수 있습니다.반복해서 말씀드리자면, 컨테이너 환경에서 단 200개의 노드만으로 22,000개의 워크로드 세그먼트가 생성될 수 있습니다.

그리고 이것은 컨테이너 환경에서만 가능합니다.관리형 워크로드 및 가능한 세그먼트의 예상 수를 추정하려면 전체 하이브리드 클라우드에 컨테이너화되지 않은 워크로드를 모두 추가해야 합니다.배운 교훈은 다양한 마이크로세그멘테이션 공급업체가 지원할 수 있는 관리형 워크로드의 최대 수를 더 이상 달성할 수 없다는 것입니다.

컨테이너 및 비컨테이너 모두를 위한 단일 솔루션

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

컨테이너에 하나의 세그멘테이션 솔루션을 배포하고 베어메탈과 VM에 대해 다른 세그멘테이션 솔루션을 배포하는 경우, 결과적으로 둘 사이의 이벤트를 자동화하거나 상관 관계를 파악하지 못하는 두 개의 별개의 툴셋이 생성됩니다.이 접근 방식은 소규모에서는 효과가 있을 수 있지만 배포 규모가 커지면 운영 및 관리가 어려워질 수 있습니다.워크로드 세분화에 대한 이러한 사일로화된 접근 방식은 피해야 합니다.모든 워크로드를 배포 및 관리할 수 있는 통합 솔루션을 만들려면 전체 컴퓨팅 패브릭에서 동일한 방식으로 컨테이너화된 워크로드를 관리해야 합니다. 워크로드 세분화.

예를 들어 Illumio는 베어메탈부터 VM, 컨테이너에 이르기까지 모든 워크로드에서 작동합니다.컨테이너화된 워크로드와 컨테이너화되지 않은 워크로드 간에 특징적인 차이가 없으므로 모든 워크로드에 대해 시각화, 자동화, 정책 관리를 포함한 마이크로세그멘테이션이 가능합니다.

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

쿠버네티스는 이그레스 및 인그레스 네트워크 트래픽을 제어할 수 있는 세 가지 주요 컨테이너 엔티티, 즉 포드, 서비스 또는 네임스페이스를 정의합니다.(참고: 노드는 이러한 엔티티 간의 대상으로 간주되지 않으며 클러스터는 노드 컬렉션 주변의 가장 넓은 경계로 정의됩니다.)또한 클러스터 주변에 로드 밸런서가 배포되는 경우가 많기 때문에 세그먼트화할 수 있는 항목이 4개일 수 있습니다.마이크로세그멘테이션 아키텍처를 정의할 때 다음 중 세그먼트로 분류해야 하는 항목은 무엇입니까?일부 또는 전부?

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

쿠버네티스는 서비스를 배포할 수 있는데, 이 서비스는 주어진 수의 포드 앞에 배포되며, 이는 마치 그 뒤에 있는 파드의 로드 밸런서 역할을 한다.서비스는 훨씬 더 안정적이며, 쿠버네티스는 포드를 동적으로 스핀업 및 스핀다운할 수 있지만 서비스에서는 거의 불가능합니다.따라서 서비스를 개별 포드가 아닌 세그먼트로 정의하는 것이 가장 좋습니다.

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

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

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

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

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

클라우드에 컨테이너를 배포한다고 해서 배포 방식에 관계없이 워크로드 주변의 세그먼트를 정의하는 기능이 저하되어서는 안 됩니다.장애물을 발생시키지 않으면서 세그멘테이션 솔루션을 컨테이너식 워크로드가 지원하는 것과 동일한 숫자로 계속 확장할 수 있어야 합니다.Illumio Core를 통해 기업은 다음과 같은 목표를 달성할 수 있습니다. 제로 트러스트 규모에 관계없이 전체 클라우드 패브릭의 모든 단일 워크로드에 적용됩니다.

더 알고 싶으세요?방법 읽어보기 일루미오 코어는 쿠버네티스와 오픈시프트를 보호할 수 있습니다..

오늘 저희에게 연락하세요 Illumio 제로 트러스트 세그멘테이션을 사용하여 컨테이너를 보호하는 방법을 알아보십시오.