KR20230160938A

KR20230160938A - 컨테이너화된 애플리케이션 보호

Info

Publication number: KR20230160938A
Application number: KR1020237038019A
Authority: KR
Inventors: 존 에드워드 맥다월; 샤라드 사하; 닐레시 반살
Original assignee: 팔로 알토 네트웍스, 인크.
Priority date: 2021-05-28
Filing date: 2022-05-24
Publication date: 2023-11-24
Also published as: EP4352919A1; WO2022251220A1; JP7503219B2; US11924165B2; CN117378174A; US20230008901A1; US11477165B1; JP2024522101A

Abstract

컨테이너화된 애플리케이션들을 보호하기 위한 기술들이 개시된다. 일부 실시예들에서, 컨테이너화된 애플리케이션들을 보호하기 위한 시스템, 프로세스, 및/또는 컴퓨터 프로그램 제품은 새로운 애플리케이션 컨테이너(예를 들어, 애플리케이션 파드를 검출하는 것; 상기 애플리케이션 컨테이너에 보안 개체(예: 방화벽)를 배포하는 것; 및 정책을 시행하기 위해 보안 개체를 사용하여 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽(예: 애플리케이션 컨테이너와 연관된 모든 계층-7 유입, 유출 및 동-서 트래픽)을 모니터링하는 것을 포함한다.

Description

컨테이너화된 애플리케이션 보호

본 발명은 컨테이너화된 애플리케이션들을 보호하기 위한 시스템, 방법, 및 컴퓨터 프로그램에 관한 것이다.

방화벽은 일반적으로 승인된 통신이 방화벽을 통과하도록 허용하면서 승인되지 않은 액세스로부터 네트워크를 보호한다. 방화벽은 일반적으로 네트워크 액세스에 대해 방화벽 기능을 제공하는 디바이스, 디바이스 세트 또는 컴퓨터와 같은 디바이스에서 실행되는 소프트웨어이다. 예를 들어, 방화벽들은 디바이스들(예: 컴퓨터, 스마트폰, 또는 다른 유형들의 네트워크 통신 가능 디바이스들)의 운영 시스템들에 통합될 수 있다. 방화벽들은 또한, 컴퓨터 서버, 게이트웨이, 네트워크/라우팅 디바이스(예: 네트워크 라우터), 또는 데이터 어플라이언스(예: 보안 어플라이언스 또는 다른 유형들의 특수 목적 디바이스)에 통합되거나 소프트웨어로 실행될 수도 있다.

방화벽들은 일반적으로 일련의 규칙들에 기초하여 네트워크 전송을 거부하거나 허용한다. 이러한 일련의 규칙들을 흔히 정책(policies)이라고 한다. 예를 들어, 방화벽은 일련의 규칙들 또는 정책들을 적용함으로써 인바운드 트래픽을 필터링할 수 있다. 방화벽은 또한 일련의 규칙들 또는 정책들을 적용함으로써 아웃바운드 트래픽을 필터링할 수 있다. 방화벽들은 또한 기본적인 라우팅 기능들을 수행할 수 있다.

본 발명의 다양한 실시예들은 다음의 상세한 설명 및 첨부 도면들에 개시된다.
도 1a는 일부 실시예들에 따른 단일 방화벽 클러스터에 대한 보안 컨테이너 배포의 블록도이다.
도 1b는 일부 실시예들에 따른 2개의 방화벽 클러스터들에 대한 보안 컨테이너 배포의 블록도이다.
도 1c는 일부 실시예들에 따른 2개의 방화벽 클러스터들과 관리 플레인 고가용성(HA) 링크에 대한 보안 컨테이너 배포의 블록도이다.
도 2는 일부 실시예들에 따라 컨테이너화된 애플리케이션들을 보호하기 위한 시스템 아키텍처의 블록도이다.
도 3a는 일부 실시예들에 따라 애플리케이션 파드에서 데이터 플레인(DP) 컨테이너를 생성하기 위한 시퀀스 다이어그램이다.
도 3b는 일부 실시예들에 따라 쿠버네티스를 사용하여 노드에서 데이터 플레인(DP) 데몬셋을 셧다운하기 위한 시퀀스 다이어그램이다.
도 4a는 데이터 어플라이언스의 실시예를 도시한다.
도 4b는 데이터 어플라이언스의 실시예의 논리적 구성요소들의 기능도이다.
도 5는 일부 실시예들에 따라 컨테이너화된 애플리케이션들을 보호하기 위한 프로세스를 도시하는 흐름도이다.
도 6은 일부 실시예들에 따라 컨테이너화된 애플리케이션들을 보호하기 위한 프로세스를 도시하는 또 다른 흐름도이다.

본 발명은 프로세스로서; 장치; 시스템; 물건의 구성; 컴퓨터 판독 가능한 저장 매체에 포함된 컴퓨터 프로그램 제품; 및/또는 프로세서, 예컨대 프로세서에 결합된 메모리에 저장되거나 및/또는 그에 의해 제공되는 명령들을 실행하도록 구성된 프로세서를 포함하여 다양한 방식들로 구현될 수 있다. 본 명세서에서, 이러한 구현들 또는 본 발명이 취할 수 있는 다른 모든 형태는 기술들로 지칭될 수 있다. 일반적으로, 개시된 프로세스들의 단계들의 순서는 본 발명의 범위 내에서 변경될 수 있다. 달리 명시되지 않는 한, 작업을 수행하도록 구성되는 것으로 설명된 프로세서 또는 메모리와 같은 구성요소는 지정된 시간에 작업을 수행하도록 일시적으로 구성되는 일반 구성요소 또는 작업을 수행하도록 제작된 특정 구성요소로 구현될 수 있다. 본 명세서에서 사용되는 것으로서, 용어 '프로세서' 는 컴퓨터 프로그램 명령들과 같은 데이터를 처리하도록 구성된 하나 이상의 디바이스들, 회로들 및/또는 프로세싱 코어들을 의미한다.

본 발명의 하나 이상의 실시예들에 대한 상세한 설명은 본 발명의 원리를 예시하는 첨부 도면들과 함께 아래에 제공된다. 본 발명은 이러한 실시예들과 관련하여 설명되지만, 본 발명은 어떠한 실시예로도 제한되지 않는다. 본 발명의 범위는 청구 범위에 의해서만 한정되며, 본 발명은 수많은 대안들, 수정들 및 등가물들을 포함한다. 본 발명의 완전한 이해를 제공하기 위해 다음의 설명에서 다수의 특정 세부 사항들이 설명된다. 이러한 세부 사항들은 예의 목적으로 제공되며, 본 발명은 이러한 특정 세부 사항들의 일부 또는 전부없이 청구 범위에 따라 실시될 수 있다. 명확성을 위해, 본 발명과 관련된 기술 분야들에서 알려진 기술 자료는 상세하게 설명하지 않았으며, 이는 본 발명이 불필요하게 모호해지는 일이 없도록 하기 위함이다.

진보된 또는 차세대 방화벽

맬웨어는 악성 소프트웨어(예를 들어, 다양한 적대적, 침입적 및/또는 원치 않는 소프트웨어 포함)를 지칭하는 데 통상적으로 사용되는 일반적인 용어이다. 맬웨어는 코드, 스크립트, 활성 콘텐트, 및/또는 기타 소프트웨어의 형태일 수 있다. 맬웨어의 예시적인 사용은 컴퓨터 및/또는 네트워크 운영 방해, 독점 정보(예: ID(identity), 금융 및/또는 지적 재산 관련 정보와 같은 기밀 정보) 도용, 및/또는 개인/독점 컴퓨터 시스템 및/또는 컴퓨터 네트워크에 대한 액세스 권한 획득을 포함한다. 안타깝게도, 맬웨어를 검출하고 완화시키는 데 도움이 되는 기술들이 개발되고 있지만 악의적인 작성자들은 이러한 노력들을 회피하는 방법을 찾는다. 따라서, 맬웨어를 식별하고 완화시키기 위한 기술들에 대한 개선들이 지속적으로 필요하다.

방화벽은 일반적으로 승인된 통신이 방화벽을 통과하도록 허용하면서 승인되지 않은 액세스로부터 네트워크를 보호한다. 방화벽은 일반적으로 네트워크 액세스를 위한 방화벽 기능을 제공하는 디바이스, 디바이스 세트 또는 디바이스에서 실행되는 소프트웨어이다. 예를 들어, 방화벽은 디바이스들(예: 컴퓨터, 스마트폰, 또는 다른 유형들의 네트워크 통신 가능 디바이스들)의 운영 시스템에 통합될 수 있다. 방화벽은 또한 컴퓨터 서버, 게이트웨이, 네트워크/라우팅 디바이스(예: 네트워크 라우터), 또는 데이터 어플라이언스(예: 보안 어플라이언스 또는 다른 유형들의 특수 목적 디바이스들)와 같은 다양한 유형들의 디바이스들 또는 보안 디바이스들 상의 소프트웨어 애플리케이션들로서 실행되거나 이에 통합될 수 있으며, 일부 구현들에서 특정 동작들은 ASIC 또는 FPGA와 같은 특수 목적 하드웨어에서 구현될 수 있다.

방화벽들은 일반적으로 일련의 규칙들에 기초하여 네트워크 전송을 거부하거나 허용한다. 이러한 규칙들의 세트들은 종종 정책(예를 들어, 네트워크 정책 또는 네트워크 보안 정책)이라고 지칭된다. 예를 들어, 방화벽은 원치 않는 외부 트래픽이 보호된 디바이스들에 도달하는 것을 방지하기 위한 일련의 규칙들이나 정책들을 적용함으로써 인바운드 트래픽을 필터링할 수 있다. 방화벽은 또한 일련의 규칙들 또는 정책들(예를 들어, 허용, 차단, 모니터링, 알림 또는 로그(log) 및/또는 다른 조치들이 여기에 설명된 것과 같은 다양한 기준에 기초하여 트리거될 수 있는 방화벽 규칙들 또는 방화벽 정책들에 지정될 수 있다)을 적용함으로써 아웃바운드 트래픽을 필터링할 수 있다. 방화벽은 또한 일련의 규칙들 또는 정책들을 유사하게 적용함으로써 로컬 네트워크(예: 인트라넷) 트래픽을 필터링할 수 있다.

보안 디바이스(예: 보안 어플라이언스, 보안 게이트웨이, 보안 서비스, 및/또는 다른 보안 디바이스들)는 다양한 보안 동작들(예: 방화벽, 안티-맬웨어, 침입 방지/검출, 프록시, 및/또는 다른 보안 기능들), 네트워킹 기능들(예: 라우팅, 서비스 품질(QoS), 네트워크 관련 리소스들의 워크로드 밸런싱, 및/또는 다른 네트워킹 기능들), 및/또는 다른 보안 및/또는 네트워킹 관련 동작들을 수행할 수 있다. 예를 들어, 라우팅은 소스 정보(예: IP 주소 및 포트), 목적지 정보(예: IP 주소 및 포트), 및 프로토콜 정보(예: 계층-3 IP 기반 라우팅)에 기초하여 수행될 수 있다.

기본 패킷 필터링 방화벽은 네트워크를 통해 전송되는 개별 패킷들을 검사함으로써 네트워크 통신 트래픽을 필터링한다(예: 무상태(stateless) 패킷 필터링 방화벽인 패킷 필터링 방화벽 또는 1세대 방화벽). 무상태 패킷 필터링 방화벽들은 일반적으로 개별 패킷들 자체를 검사하고 검사된 패킷들에 기초하여 규칙들을 적용한다(예: 패킷의 소스 및 목적지 주소 정보의 조합, 프로토콜 정보, 및 포트 번호를 사용).

애플리케이션 방화벽들은 또한 애플리케이션 계층 필터링을 수행할 수 있다(예: TCP/IP 스택의 애플리케이션 레벨에서 작동하는 애플리케이션 계층 필터링 방화벽 또는 2세대 방화벽을 사용). 애플리케이션 계층 필터링 방화벽들 또는 애플리케이션 방화벽들은 일반적으로 특정 애플리케이션 및 프로토콜(예: HTTP(HyperText Transfer Protocol)을 사용한 웹 브라우징, DNS(Domain Name System) 요청, FTP(File Transfer Protocol)를 사용한 파일 전송, 및 Telnet, DHCP, TCP, UDP 및 TFTP(GSS)와 같은 다른 다양한 유형들의 애플리케이션들 및 다른 프로토콜들)을 식별할 수 있다. 예를 들어, 애플리케이션 방화벽들은 표준 포트를 통해 통신을 시도하려고 하는 승인되지 않은 프로토콜들을 차단할 수 있다(예: 해당 프로토콜에 대한 비표준 포트를 사용하여 침투를 시도하려는 승인되지 않은/정책 외 프로토콜은 일반적으로 애플리케이션 방화벽들을 사용하여 식별될 수 있음).

상태 유지(stateful) 방화벽들은 또한 패킷 플로우/네트워크 전송의 패킷들의 플로우와 연관된 일련의 패킷 컨텍스트 내에서 각 패킷이 검사되는 상태 유지 기반 패킷 검사를 수행할 수 있다(예: 상태 유지 방화벽 또는 3세대 방화벽). 이 방화벽 기술은 일반적으로, 방화벽을 통과하는 모든 연결들의 기록들을 유지하고 패킷이 새로운 연결의 시작인지, 기존 연결의 일부인지, 또는 잘못된 패킷인지의 여부를 결정할 수 있기 때문에 상태 유지 패킷 검사라고 지칭된다. 예를 들어, 연결의 상태는 그 자체가 정책 내의 규칙을 트리거하는 기준들 중 하나가 될 수 있다.

진보된 또는 차세대 방화벽들은 위에서 설명한 바와 같이 무상태 및 상태 유지 패킷 필터링 및 애플리케이션 계층 필터링을 수행할 수 있다. 차세대 방화벽들은 또한 추가 방화벽 기술들을 수행할 수 있다. 예를 들어, 때때로 진보된 또는 차세대 방화벽이라고 지칭되는 특정의 최신 방화벽들은 또한 사용자들 및 콘텐트를 식별할 수 있다. 특히, 특정의 차세대 방화벽들은 이러한 방화벽들이 자동으로 식별할 수 있는 애플리케이션 목록을 수천 개의 애플리케이션들로 확장하고 있다. 이러한 차세대 방화벽들의 예들은 팔로 알토 네트웍스, 인코포레이티드(Palo Alto Networks, Inc.)로부터 상업적으로 유용할 수 있다(예: 팔로 알토 네트웍스의 PA 시리즈 방화벽들).

예를 들어, 팔로 알토 네트웍스의 차세대 방화벽들은 기업들이 다음과 같은 다양한 식별 기술들을 사용하여 포트들, IP 주소들 및 패킷들뿐만 아니라 애플리케이션들, 사용자들 및 콘텐트를 식별하고 제어할 수 있게 한다: 정확한 애플리케이션 식별을 위한 APP-ID, 사용자 식별(예: 사용자 또는 사용자 그룹별)을 위한 User-ID, 및 실시간 콘텐트 스캐닝(예: 웹 서핑 제어, 데이터 및 파일 전송 제한)을 위한 Content-ID가 있다. 이러한 식별 기술들은 기업들이 기존 포트 차단 방화벽들에 의해 제공되는 기존 접근 방식을 따르는 대신에 비즈니스 관련 개념들을 사용하여 애플리케이션을 안전하게 사용할 수 있게 한다. 또한, 예를 들어, 전용 어플라이언스들로 구현되는 차세대 방화벽들을 위한 특수 목적 하드웨어는 일반적으로 범용 하드웨어(예를 들면, 지연 시간(latency)을 최소화하면서 네트워크 처리량을 극대화하기 위해 단일 패스 소프트웨어 엔진과 긴밀하게 통합되는 전용 기능 특정 프로세싱을 이용하는 팔로 알토 네트웍스, 인코포레이티드에서 제공하는 보안 어플라이언스들)에서 실행되는 소프트웨어보다 애플리케이션 검사에 대해 더 높은 레벨의 성능을 제공한다.

고급 또는 차세대 방화벽들은 또한 가상화된 방화벽들을 사용하여 구현될 수 있다. 이러한 차세대 방화벽들의 예들은 팔로 알토 네트웍스, 인코포레이티드로부터 상업적으로 이용 가능하다(예: 예를 들어, VMware®ESXi™ 및 NSX™, Citrix®Netscaler SDX™, KVM/OpenStack(Centos/RHEL, Ubuntu®), 및 Amazon Web Services(AWS)를 포함하는 다양한 상업용 가상화 환경들을 지원하는 팔로 알토 네트웍스의 방화벽들). 예를 들어, 가상화된 방화벽들은 물리적 폼 팩터 어플라이언스에서 사용할 수 있는 유사하거나 또는 정확히 동일한 차세대 방화벽 및 진보된 위협 방지 피처들(advanced threat prevention features)을 지원할 수 있으며, 이는 기업들이 프라이빗, 퍼블릭, 및 하이브리드 클라우드 컴퓨팅 환경으로 유입되는 애플리케이션들을 안전하게 활성화할 수 있게 한다. VM 모니터링, 동적 주소 그룹, 및 REST 기반 API와 같은 자동화 피처들을 통해 기업들은 해당 컨텍스트를 보안 정책에 동적으로 공급하는 VM 변경 사항을 사전에 모니터링할 수 있으므로 VM이 변경될 때 발생할 수 있는 정책 지연(policy lag)을 제거할 수 있다.

가상화된 컴퓨팅 환경을 위한 보안 솔루션의 기술적 과제

보안 서비스 제공업자들은 다양한 방화벽, VPN, 및 다른 보안 관련 서비스들을 포함하여 다양한 상업적으로 사용 가능한 보안 솔루션들을 제공한다. 예를 들어, 일부 보안 서비스 제공업자들은 그들의 고객에게 다양한 방화벽, VPN, 및 다른 보안 관련 서비스들을 포함한 보안 솔루션들을 제공한다. 그러나, 컨테이너 환경(예: 컨테이너화된 애플리케이션이라고도 하는 컨테이너 기반 환경에서 애플리케이션들을 실행하는 기업 네트워크 환경 및 서비스)의 확산이 증가함에 따라 이러한 보안 솔루션들에 대한 새로운 기술적 과제들이 제기되고 있다.

특히, 컨테이너 환경(예: 쿠버네티스 클러스터 또는 다른 상업적으로 사용 가능한 컨테이너 환경)에서 컨테이너화된 애플리케이션 계층-7(L7) 트래픽을 보호하는 것은 보안 플랫폼/솔루션(예: 캘리포니아주 산타클라라에 본사를 둔 팔로 알토 네트웍스, 인코포레이티드의 NGFW(네트워크 게이트웨이 방화벽) 또는 다른 상업적으로 사용 가능한 보안 플랫폼/솔루션과 같은 상업적으로 사용 가능한 방화벽)을 컨테이너화된 애플리케이션들의 네트워크 트래픽의 경로에 효과적이고 효율적으로 삽입하는 복잡성으로 인해 기술적으로 어려운 것이다.

따라서, 컨테이너 환경에서 컨테이너화된 애플리케이션 계층-7(L7) 트래픽을 보호하기 위해 효과적이고 효율적인 보안 플랫폼들/솔루션들을 가능하게 하는 새롭고 향상된 솔루션들이 필요하다.

컨테이너화된 애플리케이션들을 보호하는 기술들의 개요

많은 기업 네트워크 환경들은 관리형 컨테이너 서비스 오퍼링으로 전환하고 있는데, 이는 일반적으로 해당 책임의 상당 부분을 퍼블릭 클라우드 제공업자에게 오프로드함으로써 예를 들어 쿠버네티스 클러스터 관리의 복잡성과 운영 오버헤드를 줄여주기 때문이다. 다양한 관리형 컨테이너 플랫폼들은 다양한 클라우드 서비스 제공업자들에 의해 제공되는데, 예를 들어 Google Kubernetes Engine(GKE), Microsoft Azure Container Service(AKS), Microsoft Azure Container Instances(ACI), Amazon Elastic Container Service for Kubernetes(Amazon EKS), Amazon Fargate 등이 있다.

그러나, 기업들은 일반적으로 이러한 관리형 컨테이너 서비스들 내의 파드 간(inter pod) 및 서비스 간 트래픽(inter service traffic)에 대한 완전한 가시성과 보호를 원한다. 각 클라우드 서비스 제공업자는 일반적으로 보안을 적용해야 하는 그 자신들의 네트워킹 인프라 및 메커니즘들(예: 인터페이스 또는 컨테이너 네트워크 인터페이스(CNI) 플러그인과 같은 다른 솔루션들)을 보유하고 있기 때문에 네트워크 보안 옵션으로 더욱 제한된다. 따라서, 바람직하게 그러한 환경에 대해 보안 솔루션이 제공될 수 있으며 여기서 보안(예: 방화벽) 라이프사이클과 보안 정책 프로비저닝이 다양한 관리형 컨테이너 서비스 환경들(예: 컨테이너 통합/컨테이너 배포(CI/CD) 파이프라인)에 통합되어 이러한 컨테이너 환경에서 애플리케이션 라이프사이클과 함께 자동화된 보안 솔루션을 용이하게 할 수 있다.

따라서, 컨테이너화된 애플리케이션들을 보호하기 위한 다양한 기술들이 개시된다.

일부 실시예들에서, 컨테이너화된 애플리케이션들을 보호하기 위한 시스템, 프로세스, 및/또는 컴퓨터 프로그램 제품은 새로운 애플리케이션 컨테이너(예를 들어, 애플리케이션 파드(application pod))를 검출하는 것; 새로운 애플리케이션 컨테이너에 보안 개체(security entity)(예: 방화벽)를 배포(deploy)하는 것; 및 정책(예: 보안/방화벽 정책)을 시행하기 위해 보안 개체를 사용하여 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽(예: 애플리케이션 컨테이너와 연관된 모든 계층-7 유입, 유출 및 동-서 트래픽(all layer-7 ingress, egress, and east-west traffic))을 모니터링하는 것을 포함한다.

일부 실시예들에서, 컨테이너화된 애플리케이션들을 보호하기 위한 시스템, 프로세스, 및/또는 컴퓨터 프로그램 제품은 보안 개체로부터 보안 관리 개체로 트래픽 로그 데이터를 전송하는 것을 더 포함한다.

예를 들어, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 (예를 들어, 쿠버네티스 클러스터 또는 다른 상업적으로 사용 가능한 컨테이너 환경 내에서와 같은 컨테이너 환경에서 컨테이너화된 애플리케이션 계층-7(L7) 트래픽을 포함하는) 컨테이너 환경에서 애플리케이션 계층 네트워크 트래픽의 경로에 보안 플랫폼/솔루션을 투명하게 삽입하는 것을 용이하게 할 수 있다. 구체적으로, 방화벽과 같은 보안 플랫폼/솔루션은, 아래에서 자세히 설명하는 바와 같이, 예를 들어 애플리케이션 식별(APP ID) 및/또는 전체 위협 검사(full threat inspection)(예: 네트워크 트래픽의 심층 패킷 검사(DPI)를 사용)를 적용하기 위해 플로우들에 대해 정책(예: 네트워크/보안 정책)을 구현하고 시행하기 위한 지원을 포함하여 플로우들의 수정 없이 유입, 유출, 및 동-서 플로우들(ingress, egress, and east-west flows)에 대한 모든 트래픽의 경로에 투명하게 삽입될 수 있다.

예시적인 구현에서, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 클러스터 내의 유입 플로우, 유출 플로우, 및 동-서 트래픽을 포함하여 쿠버네티스 클러스터와 같은 컨테이너 환경 내의 파드들의 네트워크 트래픽에 대한 인라인 보안 솔루션을 제공할 수 있다. 따라서, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 그러한 플로우들과 다양한 유형들의 네트워크 트래픽에 대한 보안 적용 범위를 원활하게(seamlessly) 제공한다. 쿠버네티스와 같은 컨테이너 환경들은 일반적으로 수명이 긴 애플리케이션들보다는 가볍게 쓰고 버리는 파드들로 효과적으로 처리될 수 있는 애플리케이션들의 간단한 배포를 가능하게 하도록 의도되었기 때문에, 개시된 기술들은 이러한 모든 플로우들에 원활하게 삽입(seamless insertion)할 수 있을 뿐만 아니라, 파드들이 생성되고 파기됨에 따라(예를 들어, 애플리케이션 파드들이 포함된 방화벽의 동적 배포 및 제거) 이들에 사용자가 개입하지 않고 동적으로 또한 수행될 수 있으며, 이에 대해서는 아래에서 자세히 설명된다.

따라서, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 원활한 삽입(seamless insertion)을 용이하게 할 수 있다. 예를 들어, 애플리케이션 파드들은 실행 중(예를 들어, 런타임 시) 수행되는 보안의 가시성이 반드시 필요한 것은 아니며, 이는 사이드카 컨테이너, IP 테이블, 또는 애플리케이션 파드 내부로부터 볼 수 있는 수정 사항이 없기 때문이며, 이에 대해서는 아래에서 자세히 설명된다.

또한, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 엄격한 인라인 보안을 촉진할 수 있다. 예를 들어, 쿠버네티스 노드의 네트워크/브리지 연결(인터페이스)에 대한 애플리케이션이 방화벽/보안 솔루션(예: PAN-OS) 인터페이스를 통과하는 경우 애플리케이션 파드는 일반적으로 아래에서 자세히 설명하는 것과 같이 보안을 우회할 수 없다.

또한, 컨테이너화된 애플리케이션을 보호하기 위해 개시된 기술들은 일반적으로 모든 네트워크 트래픽 플로우들을 커버할 수 있다. 예를 들어, 개시된 보안 솔루션은 컨테이너 환경 내의 유입, 유출, 및 동-서 트래픽 플로우들을 커버하며(예를 들어, 쿠버네티스 인프라를 변경할 필요 없이 쿠버네티스 클러스터와 같은 컨테이너 환경에서 플로우들을 수정하지 않고 유입, 유출, 및 동-서 플로우들의 APP ID 및 위협 검사), 아래에 자세히 설명된다. 개시된 보안 솔루션들은 또한 클라우드 네이티브이며 역시 아래에서 자세히 설명하는 것과 같이 모든 컨테이너 환경 배포들(예: 쿠버네티스 배포들)에서 작동할 수 있다.

더욱이, 컨테이너화된 애플리케이션을 보호하기 위해 개시된 기술들은 일반적으로 모든 네트워크 트래픽 유형들을 커버할 수 있다. 예를 들어, 일반적으로 호스트의 넷필터 및 특정 프로토콜 피처들에 의존하여 해당 유형들만의 트래픽 프로토콜들(예: 일반적으로 TCP 옵션, UDP 적용 범위 없음)만을 보호하는 다양한 다른 보안 접근 방식들과 달리, 인터페이스 레벨 플러밍(interface-level plumbing)은 아래에서 자세히 설명하는 것처럼 모든 유형들의 네트워크 트래픽에 대해 보안을 적용할 수 있게 한다.

또한, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 일반적으로 세션에 대한 모든 패킷들을 검사할 수 있다. 예를 들어, 방화벽(예: PAN-OS 방화벽)이 애플리케이션 파드들을 떠나거나 들어오는 모든 트래픽에 대해 엄격한 인라인을 적용하는 경우, 개시된 보안 솔루션들은 세션/플로우에 대한 모든 패킷들을 검사할 수 있으며 TCP SYN 패킷 등에만 의존하지 않는다. 이에 대해 아래에서 자세히 설명한다.

또한, 컨테이너화된 애플리케이션을 보호하기 위해 개시된 기술들은 컨테이너 환경들에 대한 향상된 보안 성능을 촉진할 수 있다. 다른 접근 방식들은 일반적으로 엔보이(envoy)와 같은 네트워크 프록시로 구현된다. 이러한 접근 방식들은 일반적으로 모든 트래픽 플로우들을 종료하고 재설정해야 하므로 트래픽에 상당한 오버헤드를 추가한다. 이에 반해, 개시된 보안 솔루션은 RAW 소켓들을 사용하므로 지연 시간이 줄어들고 처리량이 향상된다.

또한, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 각 노드에서 단일 방화벽 에이전트를 활용할 수 있다. 따라서, 일부 다른 사이드카 기반 접근 방식들과 달리, 아래에서 자세히 설명하는 것처럼 노드당 하나의 방화벽만 실행된다.

컨테이너 환경들에 대한 현재 보안 접근 방식들의 대부분은 또한 네트워크 정책들을 구현하기 위해 노드에서 IP 테이블/넷필터 또는 버클리 패킷 필터(BPF) 필터들에 의존한다. 이 솔루션은 이들 중 어떤 것과도 간섭하지 않으며 그러한 기존 솔루션들과 함께 작업할 수 있다. 또한, 개시된 보안 솔루션은 트래픽 리디렉션을 위해 IP 테이블/넷필터 또는 BPF 필터에 의존하지 않으며, 따라서 새로운 파드들/서비스들이 배포될 때 IP 테이블들에 대한 추가/삭제 변경 사항들에 대한 폭발 반경(blast radius)이 증가하지 않는다.

따라서, 아래에 추가로 설명되는 바와 같이 컨테이너화된 애플리케이션들을 보호하기 위한 다양한 기술들이 개시된다.

컨테이너화된 애플리케이션들을 보호하기 위한 예시적인 시스템 실시예들

도 1a는 일부 실시예들에 따른 단일 방화벽 클러스터에 대한 보안 컨테이너 배포의 블록도이다. 이 예에서, 보안 솔루션은 쿠버네티스 마스터(110) 및 쿠블릿들(Kubelets)(112A-D)을 포함하는 쿠버네티스 클러스터에 배포된다. 도 1a를 참조하면, 관리 파드(Management Pod)(104)로 도시된 단일 관리 플레인을 갖춘 쿠버네티스 클러스터(102)는 선택된 보호되는 파드들(106A-G)을 보호하기 위해 제공되며 나머지 파드들(108A-C)은 도시된 바와 같이 보호되지 않는다.

예시적인 구현에서, 현재 가상 머신(VM) 이미지의 보안 관리 플레인 및 보안 데이터 플레인은 분리되며 별개의 컨테이너들에 배포된다. 관리 플레인(MP) 컨테이너(예를 들어, 상태 유지 서비스(stateful service)로서 배포됨)는 복수의 데이터 플레인(DP) 컨테이너들(예를 들어, 32개(또는 그 이상)의 별개의 데이터 플레인 컨테이너들을 지원할 수 있음)을 관리할 수 있다. 관리 플레인 및 데이터 플레인 컨테이너들은 보안 터널(예: IPSec 터널 또는 다른 보안 터널/통신 메커니즘)을 통해 통신할 수 있다. 관리 컨테이너에 연결된 각 데이터 플레인 컨테이너는 다른 데이터 플레인 컨테이너와 완전히 독립적으로 동작할 수 있으며 별개의 라이프사이클을 갖는다. 이 예에서, 관리 플레인 컨테이너에 연결된 모든 데이터 플레인 컨테이너들은 동일한 정책(예를 들어, 이들에 푸시되는 방화벽/보안 정책)을 갖는다. 관리 컨테이너들은 방화벽/보안 관리 플랫폼에 의해 관리될 수 있으며(예를 들어, 캘리포니아 산타클라라에 본사를 둔 팔로 알토 네트웍스, 인코포레이티드로부터 상업적으로 사용 가능하고 가상 머신(VM) 또는 물리적 어플라이언스로서 배포된 Panorama를 사용하거나 또는 다른 상업적으로 사용 가능한 방화벽/보안 관리 플랫폼을 사용), 해당 방화벽/보안 관리 플랫폼의 각 인스턴스는 이 예에서 최대 1,000개(또는 그 이상)의 관리 서비스들(예: 예를 들어 하나 또는 둘(또는 그 이상)의 관리 플레인 파드들을 가질 수 있음)을 관리할 수 있다.

이 예시적인 구현에서, 쿠버네티스 클러스터는 보안 관리 플레인 컨테이너를 지원하는 서비스를 배포한다. 사용자는 단일 관리 파드를 상태 유지 서비스로서 배포하거나(예를 들어, 도 1a 및 1b의 104로 도시) 또는 관리 파드들에 내결함성 쌍(fault tolerant pair)을 배포할 수 있다. 관리 파드는 일반적으로 데이터 플레인 파드들보다 먼저 배포된다. 클러스터에 대한 관리자(예: 보안 관리자)는 도 1a에 도시된 것처럼 선택된 파드들에 보안을 선택적으로 삽입할 수 있으며 또는 1b에 도시된 바와 같이 보안을 여러 보안 관리 도메인들로 분할할 수 있다.

예를 들어, 모든 트래픽, URL들, 및 위협 로그들(threat logs)은 DP 컨테이너들을 통해 IPSec 터널을 통해 등록한 MP 컨테이너로 전달될 수 있다. DP는 MP로 전달하기 전에 데이터 플레인 로그들의 유입 및 유출 인터페이스에 해당 슬롯을 삽입할 수 있다. 모든 트래픽 로그들은 MP 컨테이너에서 유지되어 보안 관리 플랫폼(예: Panorama 또는 방화벽을 위한 다른 상업적으로 사용 가능한 보안 관리 플랫폼 등)으로 전달될 수 있다. 이 예에서, DP 컨테이너에 저장된 로그들은 없다. 대안적으로, 위에서 설명한 것과 유사하게, 로그들이 DP 컨테이너에 캐시될(cached) 수 있어, 주기적으로 MP 컨테이너에 전달될 수 있다.

도 1b는 일부 실시예들에 따른 2개의 방화벽 클러스터들에 대한 보안 컨테이너 배포의 블록도이다. 이 예에서, 보안 솔루션은 쿠버네티스 마스터(110) 및 쿠블릿들(112A-D)을 포함하는 쿠버네티스 클러스터에 배포된다. 도 1b를 참조하면, 관리 파드들(104A 및 104B)을 포함하는 단일 관리 플레인을 갖춘 쿠버네티스 클러스터(120)는 보호되는 파드들(122A-E) 및 보호되는 파드들(124A-E)로 도시된 바와 같이 파드들이 상이한 보안 관리 도메인들로 분할되는 파드들을 보호하기 위해 제공된다. 이 실시예에서, MP/DP 컨테이너들의 각각의 별개의 세트가 상이한 정책 도메인들(PCI 또는 비-PCI(non-PCI)) 또는 CI/CD 파이프라인의 상이한 스테이지들에 적용될 수 있다(예를 들어, 개발 대 프로덕션). 배포 구성은 사용자들(예: 네트워크/보안 관리자들)이 다양한 시나리오들을 설계할 수 있도록 유연하다.

도 1c는 일부 실시예들에 따른 2개의 방화벽 클러스터들과 관리 플레인 고가용성(HA) 링크에 대한 보안 컨테이너 배치의 블록도이다. 이 예에서, 보안 솔루션은 쿠버네티스 마스터(110) 및 쿠블릿들(112A-D)을 포함하는 쿠버네티스 클러스터에 배포된다. 도 1c를 참조하면, 관리 파드(104A) 및 HA 링크(134)에 의해 연결된 또 다른 관리 파드(104B)를 포함하는 관리 플레인 서비스(132)를 갖춘 쿠버네티스 클러스터(130)는 보호되는 파드들(122A-F) 및 보호되는 파드들(124A-E)로 도시된 바와 같이 파드들이 상이한 보안 관리 도메인들로 분할되는 파드들을 보호하기 위해 제공된다.

관리 플레인 페일오버(management plane failover)에 대한 예시적인 시나리오는 MP 서비스로서 2개의 관리 파드들이 배포된 경우이다. 이 예에서, 관리 파드들 각각은 활성화되어 있으며 각각은 도 1c에 도시된 바와 같이 데이터 플레인 컨테이너들의 세트를 관리한다. 예를 들어, MP 파드(104A)에 장애가 발생하면 서비스가 다시 시작되고, MP 파드(104A)를 사용할 수 없는 동안 이전에 MP 파드(104A)에 의해 관리됐던 DP 컨테이너들(이 예에서는 보호되는 파드들(122A-F)을 포함)이 MP 파드(104B)에 연결된다. MP 파드(104A)가 다시 서비스되면, 시스템은 결국 다시 안정적인 상태로 로드 밸런싱된다. 추가적인 장애 시나리오들은 컨테이너화된 환경들에 대해 개시된 HA 보안 솔루션을 사용하여 유사하게 처리될 수 있다. 첫 번째, 데이터 플레인 인스턴스는 미리 구성된 타임아웃 윈도우 이상 동안 그 관리 플레인에 대한 하트비트를 손실할 수 있다. 예를 들어, 타임아웃은 10초로 설정될 수 있거나 또는 관리자에 의해 다른 타임아웃 설정으로 구성될 수 있다. 두 번째, 두 MP들 간의 HA 링크는 MP들 중 하나에서의 장애를 검출할 수 있다. 세 번째, 쿠버네티스는 MP 파드들 중 하나에서의 상태 확인 장애(health-check failure)를 검출할 수 있다. 이들 및 기타 장애 시나리오들은 이제 아래에 추가로 설명되는 바와 같이 컨테이너화된 환경들을 위해 개시된 HA 보안 솔루션을 사용하여 유사하게 처리될 수 있다.

첫 번째 예에서, 데이터 플레인이 장애를 검출하면 MP 서비스에 대한 재연결을 수행하는 것을 시도한다. MP 파드들 중 하나가 사용 가능하면 재연결이 성공될 것이고 시스템은 계속 작동할 것이다. MP 파드들 중 어떠한 것도 사용 가능하지 않으면 DP 컨테이너는 셧다운할 것이고, 애플리케이션 파드는 쿠버네티스 상태 확인에 실패할 것이다. 이로 인해 중대한 서비스 중단이 발생할 수 있다; 그러나, 전체 MP 서비스를 사용할 수 없게 되므로 이러한 것은 매우 드물게 발생해야 한다.

두 번째 예의 경우에서, MP 파드들 중 하나에 장애가 발생하면 첫 번째 예의 경우와 관련하여 위에서 설명한 것과 동일하게 될 것이며, 시스템은 위에서 설명한 것과 유사하게 복구될 것이다.

세 번째 예의 경우에서, 쿠버네티스가 두 번째 예의 경우에서와 마찬가지로 장애를 검출하면 서비스에 대한 새로운 파드의 배포를 시도한다. 새로운 MP 파드를 사용할 수 있게 되면 MP 서비스에 대한 새로운 요청(예를 들어, 잠재적으로 재연결 요청) 처리를 시작한다.

기술적인 문제는 이러한 모든 이벤트들이 상이한 타임라인들에서 발생하고 이들이 충돌 가능성이 있다는 것이다. 예시적인 구현에서, DP-MP 연결의 평균 복구 시간(MTTR)을 최소화하여 DP가 셧다운되는 것을 방지하고 트래픽 로깅 정보의 손실을 최소화하도록 솔루션을 구현할 수 있다.

두 번째 및 세 번째 예의 사용 사례의 상태 확인 결과가 동일하면, 문제는 더 간단해질 수 있다. 두 번째 예의 경우에서 장애가 검출되면, 쿠버네티스는 재시작 프로세스를 시작하여 서비스에 대한 새로운 MP 파드를 생성한다. 이 프로세스가 수행되는 동안 장애가 있는 MP 파드에 연결된 기존 DP 파드들은 일반적으로 새로운 MP 파드가 사용 가능할 때까지 활성 MP 파드에 재연결할 수 있다.

도 2는 일부 실시예들에 따라 컨테이너화된 애플리케이션들을 보호하기 위한 시스템 아키텍처의 블록도이다. 이 예에서, 보안 솔루션은 쿠버네티스 클러스터의 애플리케이션 파드에 배포된다.

도 2를 참조하면, NGFW OS(예: 본 예시적 구현에서는 PAN-OS) 데이터 플레인(DP) 데몬셋(DaemonSet)(204) 및 컨테이너 네트워킹 인터페이스(CNI) 데몬셋(206)에 의해 노드(202)에 도시된 바와 같이, 보안(예를 들어, 가상 네트워크 게이트웨이 방화벽(NGFW) 보안 솔루션을 사용)이 배포될 각 노드에 2개의 데몬셋들이 배포된다. PAN-OS DP 데몬셋(204)은 208에 도시된 바와 같은 리눅스 네트워크 네임스페이스(예를 들어, 이 예에서는 PAN NS를 사용)와 통신하는 것으로 도시된다. 또한 도시된 바와 같이, 한 쌍의 veth 인터페이스들(214a 및 214b)을 포함하는 PAN NS(208)는 애플리케이션 컨테이너(210)와 통신한다. 구체적으로, PAN NS(208)는 PAN NS(208)의 veth 인터페이스(214a) 및 애플리케이션 컨테이너(210)의 eth0 인터페이스(212)(예를 들어, 이더넷 인터페이스)를 통해 애플리케이션 컨테이너(210)와 통신한다. PAN NS(208)는 또한 cbr0(216)(예: 모든 컨테이너 파드들을 연결하는 노드 내의 소프트웨어 브리지인 컨테이너 브리지)을 통해 노드(202)의 eth0 인터페이스(218)와 통신한다.

이 예시적 구현에서, 컨테이너화된 애플리케이션을 보호하기 위해 개시된 기술들은 방화벽(예를 들면, 팔로 알토 네트웍스로부터 상업적으로 사용 가능한 PAN-OS 기반 방화벽 또는 다른 상업적으로 사용 가능한 방화벽) 또는 임의의 다른 컨테이너 네트워킹 기능(CNF)에 의해 애플리케이션 파드로 들어오고 나가는 모든 트래픽의 검사를 구현하기 위해 기존 컨테이너 네트워킹 인터페이스(CNI)(예: CNI는 https://github.com/containernetworking/cni/blob/master/SPEC.md#container-network-interface-cni-specification 에서 제공되는 개방형 사양으로, 컨테이너들, 특히 쿠버네티스 컨테이너들에 플러그형 네트워킹 구현을 가능하게 하며, CNI는 GKE, AWS, Azure, OpenShift 등과 같이 상업적으로 사용 가능한 다양한 클라우드 기반 컨테이너 환경들에 지원된다)를 확장함으로써 보안 플랫폼들/솔루션들(예: 팔로 알토 네트웍스 CN-시리즈 플랫폼들 또는 다른 상업적으로 사용 가능한 보안 플랫폼들/솔루션들)의 용량을 실질적으로 증가시킬 수 있다. 특히, CNI 체인(CNI chaining)이 활용되어 다른 CNI들 이후에 PAN-CNI 플러그인(plugin)을 추가할 수 있다. PAN-CNI 플러그인은 쿠버네티스 노드에 별개의 리눅스 네트워크 네임스페이스(PAN-NS)를 생성하고, 새로운 애플리케이션 파드가 시작되면 애플리케이션 파드의 veth 인터페이스를 PAN-NS 네임스페이스(NS)로 이동하고 PAN-NS와 애플리케이션 파드의 네트워크 네임스페이스 사이에 새로운 veth 쌍의 인터페이스들을 생성한다. PAN-NS의 이 2개의 veth 인터페이스들은 아래에서 자세히 설명하는 것처럼 엄격한 인라인 보안을 삽입하는 데 사용될 수 있다. 이 예시적인 구현에서, 이들은 상업적으로 사용 가능한 PAN-OS 방화벽 가상 와이어 기술을 사용하여 연결되며, 그와 같이 PAN-OS 방화벽은 애플리케이션 파드와 쿠버네티스 노드 네트워크 사이의 모든 트래픽에 대한 엄격한 인라인 보안 검사가 된다. 결과적으로, 애플리케이션 파드와 쿠버네티스 노드 네트워크 간의 모든 트래픽은 PAN-OS 방화벽을 통과한다.

또한, 이러한 변경 사항들은 일반적으로 애플리케이션 파드에 표시되지 않으므로 개시된 보안 솔루션 기술의 보안과 투명성이 더욱 향상된다. 애플리케이션 파드가 제거되면, veth 쌍의 인터페이스들이 제거되고 그에 따라 컨테이너 환경에서 보안 솔루션의 자동화된 정리를 용이하게 한다.

또 다른 예시적인 구현에서, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술은 노드/브리지 측 veth를 팔로 알토 네트웍스(PAN) NS 네임스페이스(NS)(PAN NS)로 이동하고 PAN NS와 노드의 브리지 사이에 새로운 veth 쌍의 인터페이스들을 생성함으로써 구현된다. 이러한 메커니즘은 파드의 모든 인터페이스들에 효과적으로 적용되어 다중 인터페이스 파드들의 모든 인터페이스 트래픽에 대해 엄격한 보안을 유사하게 삽입할 수 있다.

일 실시예에서, 노드(202)에 보안을 추가하는 프로세스는 다음과 같이 수행될 수 있다. 첫 번째, 쿠버네티스 노드의 표준 CNI 체인에 CNI 플러그인을 추가한다. 두 번째, 쿠버네티스 노드에 새로운 리눅스 네트워크 네임스페이스를 생성한다(예를 들어, 이 예에서 DP 컨테이너는 파드의 주소 공간에서 실행하고 있더라도 별개의 네트워크 네임스페이스에서 실행되며, 아래에 자세히 설명되는 바와 같이 파드에 여전히 효과적으로 투명하면서도 파드로의 모든 유입 및 유출 트래픽을 모니터링할 수 있도록 구성된다). 세 번째, 새로운 애플리케이션 파드가 시작되면, PAN-CNI 플러그인은 애플리케이션 파드의 veth 인터페이스를 PAN-NS 네임스페이스(ethN)로 이동하고 PAN-NS(eth(n)/eth(n+1))와 애플리케이션 파드의 네트워크 네임스페이스 사이에 새로운 veth 쌍의 인터페이스들을 생성한다. 네 번째, 위에서 설명한 것과 유사하게 PAN-NS의 이러한 2개의 veth 인터페이스들은 엄격한 인라인 보안을 삽입하는 데 사용될 수 있다. 다섯 번째, PAN-OS 방화벽 가상 와이어 쌍을 사용하여 이들 2개의 인터페이스들을 연결한다(예: VWire는 기본적으로 방화벽이 어떻게든 패킷을 변경하지 않는 와이어의 범프(bump)이며; 패킷은 한 인터페이스에 들어가 방화벽에 의해 검사되고, 허용되면 변경 없이 다른 인터페이스로 보내지고; 하지만 정책을 위반하면 삭제된다(dropped)(예를 들어, https://en.wikipedia.org/wiki/Bump-in-the-wire 참조)). 여섯 번째, 애플리케이션 파드와 쿠버네티스 노드 네트워크 간의 모든 트래픽은 PAN-OS 방화벽을 통과한다. 구체적으로, 도 2에 도시된 바와 같이, 모든 트래픽(예: 관리 플레인 및 데이터 플레인 유입 및 유출 트래픽)은 eth0 인터페이스(212)를 통과하며, 그와 같이 이제 모든 트래픽은 또한 도 2에서 도시되는 바와 같이 204에서 제공되는 PAN-OS 방화벽을 통과한다.

예를 들어, 개시된 기술들을 사용하면, 컨테이너 환경들(예: 쿠버네티스 또는 다른 상업적으로 사용 가능한 컨테이너 환경들)을 위해 특별히 구축된 머신 러닝(ML) 기반의 차세대 방화벽(예: 캘리포니아주 산타 클라라에 본사를 둔 팔로 알토 네트웍스, 인코포레이티드로부터 구할 수 있는 CN 시리즈 방화벽 등)이 제공될 수 있다. 구체적으로, 개시된 보안 솔루션은 네임스페이스 경계들 간에 이동하는 위협들을 검출하고 방지하기 위해 아웃바운드 트래픽의 컨테이너 소스 IP를 포함한 계층-7 트래픽 가시성을 제공한다. 또한, 개시된 보안 솔루션은 다른 보안 개체들(예: 기업/컨테이너 환경의 다른 방화벽들)과 컨테이너(예: 쿠버네티스) 컨텍스트 정보를 공유함으로써 사용자가 전반적인 보안 상태를 강화하는 것을 돕도록 컨테이너 트래픽에서 기업 레벨의 네트워크 보안 및 위협 보호를 시행한다.

예시적인 사용 경우의 시나리오로서, 위에 설명된 보안 솔루션을 사용하여, 고객은 특정 레이블들 및 태그들로 보안 관리자에 의해 승인된 서비스들과 컨테이너 파드들 간의 트래픽만 허용하는 화이트리스트 모델을 활용할 수 있다.

또 다른 예시적인 사용 경우의 시나리오로서, L7 사용의 경우들은 모든 트래픽의 검사를 커버할 수 있고, 그에 따라 실제 L7 애플리케이션 유형을 식별할 수 있고, 이를 통해 방화벽에 의해 구현되는 구성된 보안 정책을 기반으로 특정 포드를 출입할 수 있는 애플리케이션 유형에 대한 규칙들을 구축할 수 있다. 또한, L7 플로우의 콘텐트가 위협 및 맬웨어에 대해 검사되어 악의적인 행동에 대해 애플리케이션들을 보호할 수 있다. 이제 당업자에게 명백한 바와 같이, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들은 다양한 다른 사용 경우의 시나리오들에 유사하게 적용될 수 있다.

예시적인 구현에서, 구성된 CNI 플러그인 체인의 각 CNI 플러그인은 컨테이너 오케스트레이션 환경에 따라 순서대로 실행된다. 쿠버네티스의 경우, 체인의 각 CNI 플러그인은 파드가 쿠블릿의 프로세스 공간에서 스케줄된 노드의 쿠블릿 프로세스에 의해 실행된다. 예시적인 구현에서, Istio CNI 플러그인은 파드 추가 작업들을 처리할 수 있고 파드의 네트워크 네임스페이스에 트래픽 리디렉션 설정을 생성할 수 있다. 각 노드의 쿠블릿은 Istio CNI 플러그인을 실행하기 때문에, Istio CNI 플러그인의 설치는 일반적으로 노드별 구성 및 플러그인 실행 파일 배포를 수반한다. Istio 노드 데몬셋은 Istio CNI 플러그인의 노드별 설치를 수행한다. CNI 아키텍처는 또한 JSON 메시지의 이전 구성 단계들을 리턴한다. 이는 veth 및 브리지 조작을 수행하는 데 사용되는 정보가 "CMD_ADD" 방법에 사용 가능하므로, 네트워크를 다시 연결하는 데 매우 유용하다. 파드가 생성되고 네트워크 네임스페이스가 생성되면 새로운 네트워크 네임스페이스에서 네트워크 프록시가 실행될 수 있다.

이러한 예시적 구현에서, 컨테이너화된 애플리케이션들을 보호하기 위해 개시된 기술들을 사용하여 파드에 이러한 보안이 제공되어야 하는 경우, YAML AIN'T MARKUP LANGUAGE(YAML) 파일에 레이블이 추가될 수 있으며, 아래에 추가로 설명되는 바와 같이, CNI는 파드를 PAN-OS DP 데몬셋에 연결한다(예를 들어, 이러한 프로세스는 애플리케이션 파드에 투명하게 수행될 수 있으며 이 예에서 애플리케이션 파드들에 코드 변경들은 추가되지 않는다(YAML 라벨만 추가)).

이 예시적인 구현에서, 사용자들은 설정에서 이러한 필드들만을 채운 후 이러한 YAML들을 사용하여 지정된 클라우드 플랫폼에 보안 솔루션/방화벽(예: 위에 설명된 CN 시리즈 방화벽)을 빠르게 배포할 수 있다.

In pan-cni.yaml, pan-cn-mgmt.yaml and pan-cn-ngfw.yaml:

image: <your-private-registry-image-path>

In pan-cn-mgmt-secret.yaml:

PAN_PANORAMA_AUTH_KEY: <panorama-auth-key>

# Thermite Certificate retrieval

CN-SERIES-AUTO-REGISTRATION-PIN-ID: "<PIN Id>"

CN-SERIES-AUTO-REGISTRATION-PIN-VALUE: "<PIN-Value>"

In pan-cn-mgmt-configmap.yaml:

# Panorama settings

PAN_PANORAMA_IP: <panorama-IP>

PAN_DEVICE_GROUP: <panorama-device-group>

PAN_TEMPLATE_STACK: <panorama-template-stack>

PAN_CGNAME: <panorama-collector-group>

# Intended License Bundle type - "CN-X-BASIC", "CN-X-BND1", "CN- X-BND2"

# based on the authcode applied on the Panorama K8S plugin

PAN_BUNDLE_TYPE: <license-bundle-type>

예시적인 프로덕션 배포의 경우, 사용자는 다음과 같이 YAML을 사용자 지정할 수 있다. pan-cn-mgmt.yaml 및 pan-cn-ngfw.yaml의 리소스(예: CPU, 메모리) 필드들은 디폴트 파라미터들로 미리 채워져 있지만 여기에 설명된 것과 유사하게 배포 시나리오에 더 적합하도록 사용자 정의할 수 있다. 또한, 컨피그맵(configmaps)에는 사용자가 추가할 수 있는 몇 가지 선택적 필드들이 있는데, 예를 들어 HA의 Panorama에 대한 PAN_PANORAMA_IP2 또는 동일한 Panorama에서 여러 쿠버네티스 클러스터들을 관리할 때 더 쉽게 식별하기 위한 CLUSTER_NAME 등이 있다(예를 들어, 캘리포니아 산타클라라에 본사를 둔 팔로 알토 네트웍스, 인코포레이티드로부터 구할 수 있는 상업적으로 사용 가능한 보안 관리 플랫폼).

YAML들이 원하는 대로 수정되면, 아래 예와 같이 이러한 YAML들이 배포될 수 있다.

kubectl apply -f plugin-serviceaccount.yaml

kubectl apply -f pan-cni-serviceaccount.yaml

kubectl apply -f pan-mgmt-serviceaccount.yaml

kubectl apply -f pan-cni-configmap.yaml

kubectl apply -f pan-cni.yaml

kubectl apply -f pan-cn-mgmt-secret.yaml

kubectl apply -f pan-cn-mgmt-configmap.yaml

kubectl apply -f pan-cn-mgmt.yaml

kubectl apply -f pan-cn-ngfw-configmap.yaml

kubectl apply -f pan-cn-ngfw.yaml

애플리케이션 파드들에 대한 보안을 활성화하기 위해 다음 어노테이션이 해당 YAML들에 적용될 수 있으며, 또는 지정된 네임스페이스의 모든 파드들에 대한 보안을 활성화하기 위해 이러한 어노테이션이 네임스페이스에 적용될 수 있다: 예를 들면, "디폴트(default)" 네임스페이스에 대해, paloaltonetworks.com/firewall: pan-fw.

kubectl annotate namespace default paloaltonetworks.com/firewall=pan-fw

OpenShift는 다른 CNI 플러그인들을 호출하는 "메타 플러그인" 역할을 하는 multus CNI를 갖고 있다. 위에 설명된 예시적인 PAN-CNI 플러그인을 OpenShift 컨테이너 환경의 이러한 multus와 통합하기 위해 애플리케이션 파드들에 대해 이러한 2개의 추가 단계들이 수행될 수 있다. 첫 번째, kubectl apply -f pan-cni-net-attach-def.yaml -n <target-namespace>를 사용하여 모든 앱 파드의 네임스페이스에 NetworkAttachmentDefinition “pan-cni”가 배포될 수 있다. 두 번째, 애플리케이션 파드에 대한 YAML에 k8s.v1.cni.cncf.io/networks: pan-cni 어노테이션이 추가될 수 있다.

도 3a는 일부 실시예들에 따라 애플리케이션 파드에서 데이터 플레인(DP) 컨테이너를 생성하기 위한 시퀀스 다이어그램이다. 쿠버네티스 컨테이너 환경에서 DP 컨테이너를 시작하기 위해 이제 설명될 바와 같이 쿠버네티스 CNI 네트워크 플러그인들이 사용될 수 있다. 특히, 리소스들을 노출하기 위해 CNI 플러그인들을 생성한다. 여기의 리소스는 위에서 설명한 것과 유사하게 DP 애플리케이션을 연결할 수 있는 새로운 네트워크 네임스페이스이다.

도 3a를 참조하면, 시퀀스 다이어그램은 일반적으로 쿠버네티스 컨테이너 환경에서 새로운 DP 데몬셋(DP Daemonset)을 시작하는 플로우를 보여준다. 일반적으로, 새로운 DP 데몬셋을 생성하기 전에 이미 사용 가능한 MP 파드/서비스가 배포되어 있어야 하며 서비스 이름과 자격 증명은 DP 데몬셋에 대한 컨피그맵의 일부여야 한다. 도 3a의 스테이지 1에 도시된 바와 같이 Kubectl(302)이 호출되어 새로운 DP 데몬셋을 생성한다. 스테이지 2에서, Containerd(304)를 사용하여 CNI 데몬셋(306)이 생성된다. 스테이지 3에서, CNI 데몬셋(306)은 도시된 바와 같이 DP 데몬셋(308)에 대해 새로운 네트워크 네임스페이스를 할당한다. 스테이지 4에서, Kubectl(302) Containerd를 사용하여 새로운 DP 데몬셋을 할당한다. 스테이지 5에서, DP 데몬셋은 MP 컨테이너(310)에 연결되고 MP 컨테이너에 등록한다(예: 패스, 할당된 코어, 컨테이너 ID, 파드 이름, 및 MP 컨테이너에 대한 가능한 다른 레이블/메타데이터). 스테이지 6에서, MP 컨테이너는 MP 통신에서 식별자로 사용되는 고유한 슬롯 번호를 DP 컨테이너에 리턴한다. 마지막으로 스테이지 7에서, DP 데몬셋은 쿠버네티스 애플리케이션 파드들로부터의 새로운 인터페이스 생성 요청들을 모니터링한다.

도 3b는 일부 실시예들에 따라 쿠버네티스를 사용하여 노드에서 데이터 플레인(DP) 데몬셋을 셧다운하기 위한 시퀀스 다이어그램이다. 이제 쿠버네티스를 사용하는 애플리케이션 파드에서 DP 데몬셋의 셧다운 프로세스가 도 3b와 관련하여 설명된다. 스테이지 1에서, kubectl(302)은 파기 요청(destroy request)을 발행한다. 스테이지 2에서, Containerd(304)로부터의 요청이 DP 데몬셋으로 전송되어 셧다운된다. 스테이지 3에서, 이 슬롯이 제거된다는 통지가 MP 컨테이너(310)로 전송된다. 그렇지 않으면, MP 컨테이너는 쿠버네티스로부터 파드가 제거된 것으로 결정할 수 있다. 이러한 것은 MP 컨테이너가 파드를 제거하고 라이선스 서비스에서 리소스들을 무료 상태로 표시하는 것을 포함한다. 스테이지 4에서, CNI 데몬셋(306)은 Containerd(304)로부터 셧다운 요청을 수신한다. 스테이지 5에서, CNI 데몬셋(308)은 방화벽용으로 생성된 네트워크 네임스페이스를 삭제하고 CNI 데몬셋을 셧다운하며, CNI 플러그인은 DP 컨테이너에 할당된 리소스들을 할당 해제한다.

데이터 어플라이언스(400)의 실시예가 도 4a에 도시되어 있다. 도시된 예는 다양한 실시예들에서 네트워크 게이트웨이가 데이터 어플라이언스로서 구현되는 경우 네트워크 게이트웨이(400)에 포함될 수 있는 물리적 구성요소들의 표현이다. 구체적으로, 데이터 어플라이언스는 고성능 멀티 코어 중앙 처리 유닛(CPU)(402) 및 랜덤 액세스 메모리(RAM)(404)를 포함한다. 데이터 어플라이언스는 또한 스토리지(410)(하나 이상의 하드 디스크들 또는 솔리드 스테이트 스토리지 유닛들과 같은)를 포함한다. 다양한 실시예들에서, 데이터 어플라이언스는 기업 네트워크를 모니터링하고 개시된 기술들을 구현하는데 사용되는 정보를 (RAM(404), 스토리지(410), 및/또는 다른 적절한 위치들 어디든 간에) 저장한다. 이러한 정보의 예들은 애플리케이션 식별자, 콘텐트 식별자, 사용자 식별자, 요청된 URL, IP 주소 매핑, 정책 및 기타 구성 정보, 시그니처, 호스트 이름/URL 범주화 정보, 맬웨어 프로파일, 및 기계 학습 모델을 포함한다. 데이터 어플라이언스는 또한 하나 이상의 선택적 하드웨어 가속기들을 포함할 수 있다. 예를 들어, 데이터 어플라이언스는 암호화(encryption) 및 복호화(decryption) 동작들을 수행하도록 구성된 암호화 엔진(406), 및 매칭을 수행하고 네트워크 프로세서들로서 작용하고, 및/또는 다른 작업들을 수행하도록 구성된 하나 이상의 FPGA(Field Programmable Gate Array)(408)들을 포함할 수 있다.

데이터 어플라이언스에 의해 수행되는 것으로 여기에서 설명된 기능은 다양한 방식들로 제공/구현될 수 있다. 예를 들어, 데이터 어플라이언스는 전용 디바이스 또는 디바이스들의 세트일 수 있다. 데이터 어플라이언스에 의해 제공되는 기능은 또한 범용 컴퓨터, 컴퓨터 서버, 게이트웨이, 및/또는 네트워크/라우팅 디바이스에서 소프트웨어로서 실행되거나 통합될 수 있다. 일부 실시예들에서, 데이터 어플라이언스에 의해 제공되는 것으로 설명된 적어도 일부 서비스들은 클라이언트 디바이스에서 소프트웨어 실행에 의해 클라이언트 디바이스(예: 랩톱, 스마트폰 등과 같은 엔드포인트 디바이스)에 대신(또는 추가로) 제공된다.

데이터 어플라이언스가 작업을 수행하는 것으로 기술될 때마다, 데이터 어플라이언스의 단일 구성요소, 구성요소들의 서브세트, 또는 모든 구성요소들이 작업을 수행하기 위해 협력할 수 있다. 유사하게, 데이터 어플라이언스의 구성요소가 작업을 수행하는 것으로 기술될 때마다, 하위 구성요소가 작업을 수행할 수 있고 및/또는 그 구성요소가 다른 구성요소들과 결합하여 작업을 수행할 수 있다. 다양한 실시예들에서, 데이터 어플라이언스의 부분들은 하나 이상의 제3자들에 의해 제공된다. 데이터 어플라이언스에 사용 가능한 컴퓨팅 리소스들의 양(amount of computing resources)과 같은 팩터들에 따라, 데이터 어플라이언스의 다양한 논리적 구성요소들 및/또는 피처(feature)들이 생략될 수 있고 여기에 설명된 기술들은 그에 따라 적응될 수 있다. 유사하게, 추가적인 논리적 구성요소들/피처들이 적용 가능한 경우 데이터 어플라이언스의 실시예들에 포함될 수 있다. 다양한 실시예들에서 데이터 어플라이언스에 포함된 구성요소의 일례는 애플리케이션을 식별하도록 구성된 애플리케이션 식별 엔진이다(예를 들어, 패킷 플로우 분석에 기초하여 애플리케이션들을 식별하기 위한 다양한 애플리케이션 시그니처들을 사용). 예를 들어, 애플리케이션 식별 엔진은 웹 브라우징 - 소셜 네트워킹; 웹 브라우징 - 뉴스; SSH; 등과 같이 세션이 수반하는 트래픽의 유형을 결정할 수 있다.

개시된 시스템 프로세싱 아키텍처는 다음과 같은 다양한 배포 시나리오들에서 상이한 유형들의 클라우드들과 함께 사용될 수 있다: (1) 퍼블릭 클라우드; (2) 온프레미스 프라이빗 클라우드(private cloud on-premises); 및 (3) 하이-엔드 물리적 방화벽 내부(inside high-end physical firewalls). 일부 프로세싱 능력이 프라이빗 클라우드를 실행하기 위해 할당될 수 있다(예: 팔로 알토 네트웍스 PA-5200 시리즈 방화벽 어플라이언스의 관리 플레인(MP) 사용).

도 4b는 데이터 어플라이언스의 실시예의 논리적 구성요소들의 기능도이다. 도시된 예는 다양한 실시예들에서 네트워크 게이트웨이(400)에 포함될 수 있는 논리적 구성요소들의 표현이다. 달리 명시되지 않는 한, 네트워크 게이트웨이(400)의 다양한 논리적 구성요소들은 일반적으로 하나 이상의 스크립트들의 세트(예를 들어, 적용 가능한 경우 Java, Python 등으로 작성됨)를 포함하는 다양한 방식들로 구현될 수 있다.

도시된 바와 같이, 네트워크 게이트웨이(400)는 방화벽을 포함하고, 관리 플레인(432) 및 데이터 플레인(434)을 포함한다. 관리 플레인은 정책들을 구성하고 로그 데이터를 보기 위해 사용자 인터페이스를 제공하는 것과 같은 사용자 상호작용을 관리하는 역할을 한다. 데이터 플레인은 패킷 프로세싱 및 세션 핸들링을 수행하는 것과 같이 데이터를 관리하는 역할을 한다.

네트워크 프로세서(436)는 패킷들을 수신하고 이들을 프로세싱을 위해 데이터 플레인(434)에 제공하도록 구성된다. 플로우 모듈(438)이 새로운 세션의 부분으로서 패킷들을 식별할 때마다 새로운 세션 플로우를 생성한다. 후속 패킷들은 플로우 조회(flow lookup)에 기초하여 세션에 속하는 것으로 식별된다. 적용 가능한 경우, SSL 복호화는 SSL 복호화 엔진(440)에 의해 적용된다. 그렇지 않으면, SSL 복호화 엔진(440)에 의한 프로세싱은 생략된다. 복호화 엔진(440)은 네트워크 게이트웨이(400)가 SSL/TLS 및 SSH 암호화 트래픽을 검사하고 제어하는 데 도움을 줄 수 있으며, 따라서 암호화된 트래픽에 은닉되 있을 수 있는 위협들을 차단하는 데 도움이 될 수 있다. 복호화 엔진(440)은 또한 민감한 콘텐트가 기업/보안된 고객의 네트워크를 벗어나는(leaving) 것을 방지하는 것을 도울 수 있다. 복호화는 다음과 같은 파라미터들에 기초하여 선택적으로 제어(예를 들어, 활성화 또는 비활성화)될 수 있다: URL 카테고리, 트래픽 소스, 트래픽 목적지(traffic destination), 사용자, 사용자 그룹, 및 포트. 복호화 정책들(예: 복호화할 세션 지정) 외에도, 복호화 프로파일들이 정책에 의해 제어되는 세션들에 대한 다양한 옵션들을 제어하도록 할당될 수 있다. 예를 들어, 특정 암호화 스위트(cipher suites) 및 암호화 프로토콜 버전의 사용이 요구될 수 있다.

애플리케이션 식별(APP-ID) 엔진(442)은 세션이 수반하는 트래픽의 유형을 결정하도록 구성된다. 일례로서, 애플리케이션 식별 엔진(442)은 수신된 데이터에서 GET 요청을 인식할 수 있고 세션이 HTTP 디코더를 필요로 한다고 결론을 내릴 수 있다. 일부 경우들, 예를 들어 웹 브라우징 세션에서, 식별된 애플리케이션은 변경될 수 있으며 이러한 변경은 네트워크 게이트웨이(400)에 의해 노트(note)된다. 예를 들어, 사용자는 처음에 기업 Wiki(방문한 URL에 기초하여 "웹 브라우징 - 생산성(Productivity)”으로 분류됨)를 검색한 다음, 소셜 네트워킹 사이트(방문한 URL에 따라 "웹 브라우징 - 소셜 네트워킹"으로 분류됨)를 검색할 수 있다. 상이한 유형들의 프로토콜들은 상응하는 디코더들을 갖는다.

애플리케이션 식별(APP-ID) 엔진(442)에 의해 이루어진 결정에 기초하여, 패킷들은 위협 엔진(threat engine)(444)에 의해 (순서 없이 수신될 수 있는) 패킷들을 올바른 순서로 조합하고, 토큰화(tokenization)를 수행하고, 정보를 추출하도록 구성된 적절한 디코더로 전송된다. 위협 엔진(444)은 또한 패킷에 어떤 일이 일어나야 하는지를 결정하기 위해 시그니처 매칭을 수행한다. 필요에 따라, SSL 암호화 엔진(446)은 복호화된 데이터를 재암호화할 수 있다. 패킷들은 (예를 들어, 목적지로) 전송하기 위해 포워드 모듈(448)을 사용하여 포워딩된다.

도 4b에 또한 도시된 바와 같이, 정책들(452)이 수신되어 관리 플레인(432)에 저장된다. 정책들은 도메인 및/또는 호스트/서버 이름들을 사용하여 지정될 수 있는 하나 이상의 규칙들을 포함할 수 있으며, 규칙들은 모니터링된 세션 트래픽 플로우들로부터 추출된 다양한 파라미터/정보에 기초하여 가입자/IP 플로우들에 대한 보안 정책 시행에 대한 것과 같이 하나 이상의 시그니처들 또는 다른 매칭 기준들 또는 경험적 방법들을 적용할 수 있다. 인터페이스(I/F) 통신기(450)가 (예를 들어, (REST) API, 메시지, 또는 네트워크 프로토콜 통신 또는 다른 통신 메커니즘을 통해) 관리 통신을 위해 제공된다.

이제 명백해지는 바와 같이, 보안/방화벽 정책 시행을 수행하기 위한 이러한 예시적인 데이터 어플라이언스의 실시예의 위에 설명된 논리적 구성요소들은 컨테이너화된 애플리케이션들을 보호하기 위해 본 명세서에 유사하게 설명된 가상 또는 컨테이너 기반 방화벽 구현과 같이 소프트웨어로 유사하게 구현될 수 있다.

컨테이너화된 애플리케이션들을 보호하기 위한 예시적인 프로세스 실시예들이 이제 아래에서 추가로 설명된다.

컨테이너화된 애플리케이션들을 보호하기 위한 예시적인 프로세스 실시예들

도 5는 일부 실시예들에 따라 컨테이너화된 애플리케이션들을 보호하기 위한 프로세스를 도시하는 흐름도이다. 일 실시예에서, 프로세스(500)는 위에 설명된(예를 들어, 도 1a-4b와 관련하여 위에서 설명된 것과 같은) 시스템 아키텍처들을 사용하여 수행된다.

프로세스는 새로운 애플리케이션 컨테이너가 검출될 때 502에서 시작된다. 예를 들어, 애플리케이션 컨테이너는 위에서 설명한 것과 유사하게 클라우드 기반 컨테이너 서비스에서 실행되는 컨테이너화된 애플리케이션일 수 있다.

504에서, 보안 개체가 새로운 애플리케이션 컨테이너에 배포된다. 예를 들어, 보안 개체는 위에서 설명한 것과 유사하게 애플리케이션 컨테이너의 모든 트래픽(예: 유입, 유출, 및 동-서 트래픽)을 모니터링하기 위해 애플리케이션 컨테이너에 원활하게 배포되는(seamlessly deployed) 방화벽을 포함할 수 있다.

506에서, 보안 개체는 정책을 시행하기 위해 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링한다. 예를 들어, 애플리케이션 컨테이너에 배포된 방화벽은 위에서 설명한 것과 유사하게 (예를 들어, APP-ID 및/또는 네트워크 트래픽과 연관된 다른 메타 정보에 기초하여) 보안/방화벽 정책을 시행하기 위해 (예를 들어, 심층 패킷 검사(DPI)를 사용하여) 트래픽을 검사함으로써 애플리케이션 컨테이너의 모든 트래픽(예를 들어, 유입, 유출, 및/또는 동-서 트래픽)을 검사할 수 있다.

도 6은 일부 실시예들에 따라 컨테이너화된 애플리케이션들을 보호하기 위한 프로세스를 도시하는 또 다른 흐름도이다. 일 실시예에서, 프로세스(600)는 위에 설명된(예를 들어, 도 1a-4b와 관련하여 위에서 설명된 것과 같은) 시스템 아키텍처들을 사용하여 수행된다.

프로세스는 새로운 애플리케이션 컨테이너가 검출될 때 602에서 시작된다. 예를 들어, 애플리케이션 컨테이너는 위에서 설명한 것과 유사하게 클라우드 기반 컨테이너 서비스에서 실행되는 컨테이너화된 애플리케이션일 수 있다.

604에서, 보안 개체가 새로운 애플리케이션 컨테이너에 배포된다. 예를 들어, 보안 개체는 위에서 설명한 것과 유사하게 애플리케이션 컨테이너의 모든 트래픽(예: 유입, 유출, 및 동-서 트래픽)을 모니터링하기 위해 애플리케이션 컨테이너에 원활하게 배포되는 방화벽을 포함할 수 있다.

606에서, 보안 개체는 애플리케이션 컨테이너에 대한 모든 계층-7(L7) 유입 및 유출 트래픽을 원활하게(seamlessly) 검사한다. 예를 들어, 보안 개체는 위에서 설명한 것과 유사하게 애플리케이션 컨테이너(예: 애플리케이션 파드)에 대한 L7 애플리케이션 트래픽을 포함한 모든 트래픽을 원활하게 검사하기 위해 애플리케이션 컨테이너에 투명하게 배포될 수 있다.

608에서, 보안 개체는 검사된 트래픽에 기초하여 보안 정책을 시행한다. 예를 들어, 애플리케이션 컨테이너에 배포된 방화벽은 위에서 설명한 것과 유사하게 (예를 들어, 위협 검사/시행(threat inspection/enforcement)을 위한 것과 같이, APP-ID 및/또는 네트워크 트래픽과 연관된 다른 메타 정보에 기초하여) 보안/방화벽 정책을 시행하기 위해 (예를 들어, 심층 패킷 검사(DPI)를 사용하여) 트래픽을 검사함으로써 애플리케이션 컨테이너의 모든 트래픽(예를 들어, 유입, 유출, 및/또는 동-서 트래픽)을 검사할 수 있다.

610에서, 보안 개체는 보안 개체로부터 보안 관리 개체로 트래픽 로그 데이터를 전송한다. 예를 들어, 보안 개체는 주기적으로 트래픽 로그 데이터를 보안 관리 개체에 보내거나 또는 위에서 설명한 것과 유사하게 애플리케이션 컨테이너/파드가 파기되기 전에 이러한 트래픽 로그 데이터를 보안 관리 개체에 보낼 수 있다.

전술한 실시 예들이 이해의 명확성을 위해 일부 상세하게 설명되었지만, 본 발명은 제공된 세부 사항에 제한되지 않는다. 본 발명을 구현하는 많은 대안적인 방법들이 있다. 개시된 실시 예들은 예시적인 것이며 제한적인 것이 아니다.

Claims

시스템에 있어서,
프로세서로서:
새로운 애플리케이션 컨테이너를 검출하고;
애플리케이션 컨테이너에 보안 개체를 배포하고;
정책을 시행하기 위해 보안 개체를 사용하여 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하도록 구성된, 상기 프로세서; 및
상기 프로세서에 결합되고, 상기 프로세서에 명령들을 제공하도록 구성된 메모리를 포함하는, 시스템.
제1항에 있어서, 상기 보안 개체는 방화벽인, 시스템.
제1항에 있어서, 상기 정책은 보안 정책인, 시스템.
제1항에 있어서, 상기 보안 개체는 방화벽이고, 상기 정책은 방화벽 정책인, 시스템.
제1항에 있어서, 상기 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하는 것은 애플리케이션 컨테이너와 연관된 모든 계층-7 유입, 유출, 및 동-서 트래픽(all layer-7 ingress, egress, and east-west traffic)을 모니터링하는 것을 포함하는, 시스템.
제1항에 있어서, 상기 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하는 것은 심층 패킷 검사를 사용하여 결정된 플로우(flow)와 연관된 애플리케이션 식별을 포함하는, 시스템.
제1항에 있어서, 상기 애플리케이션 컨테이너는 클라우드 기반 컨테이너 서비스에서 실행되는, 시스템.
제1항에 있어서, 상기 애플리케이션 컨테이너는 퍼블릭 클라우드 서비스 제공자를 사용하여 제공되는 클라우드 기반 컨테이너 서비스에서 실행되는, 시스템.
제1항에 있어서, 상기 애플리케이션 컨테이너는 복수의 퍼블릭 클라우드 서비스 제공자들을 사용하여 제공되는 클라우드 기반 컨테이너 서비스에서 실행되는, 시스템.
제1항에 있어서, 상기 프로세서는 또한:
보안 개체로부터 보안 관리 개체로 트래픽 로그 데이터를 전송하도록 구성되는, 시스템.
방법에 있어서:
새로운 애플리케이션 컨테이너를 검출하는 단계;
애플리케이션 컨테이너에 보안 개체를 배포하는 단계; 및
정책을 시행하기 위해 보안 개체를 사용하여 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하는 단계를 포함하는, 방법.
제11항에 있어서, 상기 보안 개체는 방화벽이고, 상기 정책은 방화벽 정책인, 방법.
제11항에 있어서, 상기 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하는 것은 애플리케이션 컨테이너와 연관된 모든 계층-7 유입, 유출, 및 동-서 트래픽을 모니터링하는 것을 포함하는, 방법.
제11항에 있어서, 상기 애플리케이션 컨테이너는 클라우드 기반 컨테이너 서비스에서 실행되는, 방법.
제11항에 있어서, 상기 애플리케이션 컨테이너는 퍼블릭 클라우드 서비스 제공자를 사용하여 제공되는 클라우드 기반 컨테이너 서비스에서 실행되는, 방법.
제11항에 있어서, 상기 애플리케이션 컨테이너는 복수의 퍼블릭 클라우드 서비스 제공자들을 사용하여 제공되는 클라우드 기반 컨테이너 서비스에서 실행되는, 방법.
제11항에 있어서, 보안 개체로부터 보안 관리 개체로 트래픽 로그 데이터를 전송하는 단계를 더 포함하는, 방법.
컴퓨터 프로그램 제품으로서, 상기 컴퓨터 프로그램 제품은 유형의 컴퓨터 판독 가능한 저장 매체에 구현되고, 컴퓨터 명령들을 포함하며, 상기 컴퓨터 명령들은:
새로운 애플리케이션 컨테이너를 검출하고;
애플리케이션 컨테이너에 보안 개체를 배포하고;
정책을 시행하기 위해 보안 개체를 사용하여 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하기 위한 것인, 컴퓨터 프로그램 제품.
제18항에 있어서, 상기 보안 개체는 방화벽이고, 상기 정책은 방화벽 정책인, 컴퓨터 프로그램 제품.
제18항에 있어서, 상기 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하는 것은 애플리케이션 컨테이너와 연관된 모든 계층-7 유입, 유출, 및 동-서 트래픽을 모니터링하는 것을 포함하는, 컴퓨터 프로그램 제품.
시스템에 있어서:
프로세서; 및
상기 프로세서에 결합되고, 상기 프로세서에 명령들을 제공하도록 구성된 메모리를 포함하고,
상기 프로세서는:
새로운 애플리케이션 컨테이너를 검출하고;
모든 네트워크 트래픽 유형들을 보호하기 위해 컨테이너 환경에서 애플리케이션 계층 네트워크 트래픽의 경로 안으로 애플리케이션 컨테이너에 보안 개체를 배포하고;
정책을 시행하기 위해 보안 개체를 사용하여 애플리케이션 컨테이너로 들어오고 나가는 모든 트래픽을 모니터링하고;
보안 개체로부터 보안 관리 개체로 트래픽 로그 데이터를 전송하도록 구성되고 - 상기 트래픽 로그 데이터는 애플리케이션 컨테이너가 파기되기 전에 주기적으로 보안 관리 개체로 전송됨 -,
상기 보안 개체는 다음의 동작들을 수행함으로써 유입, 유출, 및 동-서 플로우들의 모든 애플리케이션 계층 네트워크 트래픽의 경로에 플로우 수정 없이 사이드카 컨테이너 또는 IP 테이블들을 사용하지 않고 투명하게 삽입되고,
상기 다음의 동작들은,
컨테이너 환경의 노드에서 보안 개체와 연관된 새로운 네트워크 네임스페이스를 생성하는 것을 수행하고,
노드의 사이드 인터페이스를 보안 개체와 연관된 새로운 네트워크 네임스페이스로 이동하고 새로운 네트워크 네임스페이스와 애플리케이션 컨테이너와 연관된 네트워크 네임스페이스 사이에 새로운 쌍의 인터페이스들을 생성하는 것을 수행하는 것이며,
상기 보안 개체와 연관된 새로운 네트워크 네임스페이스와 상기 애플리케이션 컨테이너와 연관된 네트워크 네임스페이스 사이의 상기 새로운 쌍의 인터페이스들은 네임스페이스 경계들 간에 이동하는 위협들을 검출 및 방지하기 위해 컨테이너 환경에서 인라인 보안을 수행하는 것을 용이하게 하는, 시스템.
제21항에 있어서, 상기 보안 개체는 애플리케이션 컨테이너가 생성되고 파기될 때 애플리케이션 컨테이너에 대한 사용자 개입 없이 동적으로 애플리케이션 컨테이너에 배포되는, 시스템.
제21항에 있어서, 상기 정책은 방화벽 정책이고, 상기 프로세서는 또한:
보안 개체를 사용하여 패킷을 검사하고,
보안 정책을 위반하지 않는 것으로 결정되면 패킷을 수정 없이 전송하고, 방화벽 정책을 위반하는 것으로 결정되면 패킷을 삭제하도록 구성되는, 시스템.