[Kúbé~rñét~és를 사용하여 효과적인 컨테이너 마이크로세그멘테이션 전략을 설계하고 구현하는 방법]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[네임스페이스, 포드 또는 서비스¿]

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

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

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

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

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

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

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

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

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

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

[오늘 저희에게 연락하세요 Íllú~míó 제로 트러스트 세그멘테이션을 사용하여 컨테이너를 보호하는 방법을 알아보십시오.]