[팔로 알토 네트웍스] 네트워크 보안 기초 #3

[3주차] 클라우드 네이티브 기술

학습목표

1. 가상 머신, 컨테이너, 오케스트레이션, 서버리스 컴퓨팅과 같은 클라우드 네이티브 기술에 대해 설명한다.
2. 쿠버네티스를 비롯한 클라우드 네이티브 기술을 탐색한다.
3. 도커 브릿지 네트워크 컨테이너를 단독 모드 및 대화 모드로 만들고 실행한다.

[3-1] 클라우드 네이티브 기술

클라우드 네이티브 기술

클라우드 네이티브 생태계는 새로운 유니버스와 마찬가지로 컨테이너의 초기 핵심에서 빠르게 회전하고 확장되는 많은 기술과 프로젝트를 보유하고 있다. 관리 기술과 함께 워크로드 구축은 특히 치열한 혁신 분야다. 쿠버네티스는 업계 표준 범용 컨테이너 오케스트레이터가 되었지만, 서버리스와 같은 다른 기술은 하드웨어 및 운영 체제 관리와 관련된 추상적인 복잡성을 더한다. 이러한 기술 간의 차이는 작고 미묘한 차이가 있기 때문에 이점과 절충점을 이해하기가 어렵다.

CNCF(Cloud Native Computing Foundation) 헌장에서 정의한 바와 같이, 클라우드 네이티브 시스템에는 다음과 같은 속성이 있다.

 

① 컨테이너 패키지

소프트웨어 컨테이너의 애플리케이션 및 프로세스를 애플리케이션 배포의 격리된 단위로 실행하고, 높은 수준의 리소스 격리를 달성하는 메커니즘으로 실행한다. 전반적인 개발자 환경을 개선하고, 코드 및 구성 요소 재사용을 촉진하며, 클라우드 네이티브 애플리케이션의 운영을 단순화한다.

② 동적으로 관리

중앙 조정 프로세스에 의해 능동적으로 예약되고 능동적으로 관리된다. 유지 보수 및 운영과 관련된 비용을 줄이면서, 기계 효율성과 자원 활용률을 획기적으로 향상시킨다.

③ 마이크로서비스 지향

명시적으로 설명된 종속성(ex. 서비스 엔드포인트를 통해)과 느슨하게 결합된다. 그리고 애플리케이션의 전반적인 민첩성과 유지보수성을 크게 향상시킨다. 기반은 애플리케이션 관리를 위한 최신 기술을 발전시키고, 신뢰할 수 있는 인터페이스를 통해 기술을 어디서나 쉽게 사용할 수 있도록 기술의 진화를 형성할 것이다.

클라우드 네이티브 기술의 연속체

 

이러한 모든 기술은 서로 다른 장점과 절충점을 가진 서로 다른 툴이며, 일반적으로 조직은 적어도 몇 개의 툴을 동시에 사용한다. 조직이 클라우드 네이티브 스택, 특히 레거시 기반이 깊은 스택에 점점 더 중요한 워크로드를 도입함에 따라 이러한 이질성은 변하지 않을 것이다.

 

가상화

가상화 기술은 서버(컴퓨팅), 스토리지, 네트워킹 및 애플리케이션과 같은 실제 또는 물리적 컴퓨팅 리소스를 에뮬레이트한다. 가상화를 통해 여러 애플리케이션 또는 서버 워크로드를 하나 이상의 물리적 리소스에서 독립적으로 실행할 수 있다.

하이퍼바이저는 여러 개의 가상 운영 체제를 단일 물리적 호스트 컴퓨터에서 동시에 실행할 수 있도록 한다. 하이퍼바이저는 컴퓨터 운영 체제와 하드웨어 커널 사이에서 작동한다. 하이퍼바이저에는 두 가지 유형이 있다.

 

① 유형 1(네이티브 또는 베어메탈): 호스트 컴퓨터의 하드웨어에서 직접 실행된다.
② 유형 2(호스팅): 운영 체제 환경 내에서 실행된다.

 

가상화는 자원을 최적화하기 위해 데이터 센터와 클라우드 컴퓨팅에서 사용되는 핵심 기술이다. 가상화와 관련된 중요한 보안 고려 사항은 다음을 포함한다.

① 휴면 상태의 가상 머신(VM)

많은 데이터 센터 및 클라우드 환경에서 비활성 VM은 사용하지 않을 때 일상적으로(종종 자동으로) 종료된다. 장기간(몇 주 또는 몇 달) 동안 종료되는 VM은 멀웨어 방지 업데이트 및 보안 패치가 적용될 때 부주의로 누락될 수 있다.

 

② 하이퍼바이저 취약성

가상 환경의 호스트된 애플리케이션, VM 및 기타 리소스 내의 취약성뿐만 아니라, 하이퍼바이저 자체가 취약하여 호스트된 리소스가 공격에 노출될 수 있다.

③ VM 내 통신

특히 단일 물리적 서버에 있는 가상 호스트 간의 네트워크 트래픽은 물리적 스위치를 통과하지 못할 수 있다. 이러한 가시성 부족은 문제 해결의 복잡성을 증가시키고 부적절한 모니터링 및 로깅 기능으로 인해 보안 위험을 증가시킬 수 있다.

⑤ VM 확산

가상 환경은 빠르게 증가하여 변경 관리 프로세스가 중단되고, 휴면 상태인 VM, 하이퍼바이저 취약성 및 VM 내 통신과 같은 보안 문제가 악화될 수 있다.

 

가상 머신

클라우드 네이티브의 맥락에서 논의되는 VM을 보면 놀랄 수 있지만, 오늘날 전 세계 워크로드의 대부분이 VM에서 "직접"(컨테이너화되지 않은) 실행되고 있는 것이 현실이다. 대부분의 조직은 VM을 제거해야 할 레거시 플랫폼으로 보지 않고, 단순히 컨테이너를 실행해야 할 바보같은 호스트로 보지 않는다. 오히려 많은 애플리케이션이 아직 컨테이너화되지 않았으며, 기존 VM이 여전히 중요한 배포 모델임을 인식하고 있다. 컨테이너를 호스팅하지 않는 VM은 클라우드 네이티브 시스템의 세 가지 속성을 모두 충족하지는 않지만, 동적으로 운영되고 마이크로서비스를 실행할 수 있다.

VM은 연속체에서 최고 수준의 격리, 호환성 및 제어 기능을 제공하며, 거의 모든 유형의 워크로드를 실행하는 데 적합하다. VM 기술의 예시로는 VMware vSphere, Microsoft Hyper-V 및 Amazon EC2와 같은 거의 모든 IaaS 클라우드 제공업체에서 제공하는 인스턴스가 있다. VM은 OS, 앱 및 데이터 간의 분리가 거의 없는 상태로 운영되는 경우가 많기 때문에 연속체에서 오른쪽으로 "thin VM"과 구분된다.

클라우드 네이티브 기술의 연속체에 있는 VM 및 thin VM

 

Thin VM

다른 운영 방법론보다 덜 독특한 기술인 Thin VM은 일반적으로 VM과 동일한 기본 기술이지만, 훨씬 더 상태 비저장 방식으로 배포 및 실행된다. Thin VM은 일반적으로 사람의 개입 없이 자동화를 통해 배포되고 개별 개체가 아닌 함대로 운영되며 OS, 앱 및 데이터 분리에 우선 순위를 둔다. VM이 OS 볼륨에 앱 데이터를 저장할 수 있는 반면, Thin VM은 다른 인스턴스에 쉽게 다시 연결할 수 있는 별도의 볼륨에 모든 데이터를 저장한다. Thin VM에는 클라우드 네이티브 시스템의 컨테이너 속성도 없지만, 일반적으로 기존 VM보다 동적 관리에 더 중점을 둔다. VM을 설정하고 구성할 수 있는 반면, Thin VM은 일반적으로 사람의 개입 없이 Puppet, Chef 또는 Ansible과 같은 자동화 도구를 사용하여 표준 이미지에서 배포된다.

Thin VM은 특정 인스턴스의 데이터 분리, 자동화 및 일회용성에 의도적으로 초점을 맞춘다는 점에서 연속체의 왼쪽에 있는 VM과 차별화된다. 컨테이너 런타임이 부족하다는 점에서는 연속체에서 VM 통합 컨테이너와 차별화된다. Thin VM에는 OS 파일 시스템에 직접 설치되고, 중간 런타임 없이 호스트 OS 커널에 의해 직접 실행되는 앱이 있다.

 

컨테이너 및 오케스트레이션

개발자들은 클라우드 네이티브 애플리케이션을 구축하고 배포하는 작업을 그 어느 때보다 단순하게 만들기 때문에 컨테이너를 널리 수용해 왔다. 컨테이너는 테스트에서 프로덕션으로 애플리케이션 코드를 이동하는 데 일반적으로 관련된 마찰을 상당 부분 제거할 뿐만 아니라, 컨테이너로 패키지화된 애플리케이션 코드는 어디에서나 실행될 수 있다. 모든 애플리케이션과 관련된 모든 종속성은 컨테이너화된 애플리케이션 내에 포함된다. 따라서 컨테이너화된 애플리케이션은 로컬 데이터 센터 또는 퍼블릭 클라우드에서 실행되는 가상 머신 또는 베어메탈 서버 전반에 걸쳐 휴대성이 뛰어나다.

이러한 수준의 유연성 덕분에 개발자들은 무시할 수 없을 정도로 생산성 면에서 큰 이익을 얻을 수 있다. 하지만 새로운 IT 아키텍처의 등장과 마찬가지로, 클라우드 네이티브 애플리케이션도 여전히 보안을 유지해야 한다. 컨테이너 환경은 이미지, 컨테이너, 호스트, 런타임, 레지스트리 및 오케스트레이션 플랫폼과 관련된 다양한 사이버 보안 문제를 야기하며, 이 모든 문제는 보안이 필요하다.

쿠버네티스는 오픈 소스 오케스트레이션 플랫폼으로 개발자들이 선언적 방식으로 컨테이너 인프라를 정의할 수 있는 API, 즉, IaC(Infrastructure as code)를 제공한다. 조직은 쿠버네티스 오케스트레이션과 마이크로서비스 아키텍처를 활용하여, 컨테이너화된 클라우드 네이티브 애플리케이션을 신속하고 규모에 맞게 게시, 유지 및 업데이트할 수 있다.

 

VM 통합 컨테이너

일부 조직, 특히 대기업의 경우 컨테이너는 매력적인 애플리케이션 배포 및 운영 접근 방식을 제공하지만, 다양한 민감도 수준의 워크로드를 혼합할 수 있는 충분한 격리 기능이 부족하다. 최근에 발견된 Meltdown 및 Spectre와 같은 하드웨어 결함은 제쳐두고, VM은 훨씬 더 강력한 격리 기능을 제공하지만, 복잡성과 관리 부담을 가중시킨다. Kata 컨테이너와 VMware vSphere Integrated 컨테이너와 같은 VM 통합 컨테이너는 개발자 친화적인 API와 OS에서 앱을 추상화하는 동시에, 하이퍼바이저 내의 호환성과 보안 격리라는 근본적인 복잡성을 숨김으로써 이를 달성하려고 한다.

기본적으로 이러한 기술은 사용자가 VM임을 알거나 관리할 필요 없이 VM을 제공하려고 한다. 대신 사용자는 "docker run"과 같은 일반적인 컨테이너 명령을 실행하고, 기반 플랫폼은 자동으로 보이지 않게 새 VM을 만들고, 그 안에서 컨테이너 런타임을 시작하고, 명령을 실행한다. 결국 사용자가 하이퍼바이저에 의해 다른 모든 것과 격리된 별도의 운영 체제 인스턴스에서 컨테이너를 시작했다는 것이다. 이러한 VM 통합 컨테이너는 일반적으로 단일 VM 내에서 단일 컨테이너(또는 쿠버네티스의 포드와 유사한 밀접하게 관련된 컨테이너 세트)를 실행한다. VM 통합 컨테이너는 세 가지 클라우드 네이티브 시스템 속성을 모두 가지고 있으며, 일반적으로 선택적인 배포 접근 방식으로 수동 구성조차 제공하지 않는다.

VM 통합 컨테이너는 컨테이너만 실행하고, VM 프로비저닝을 컨테이너 런타임 작업과 완벽하게 통합하도록 명시적으로 설계되어 있기 때문에, 연속체에서 왼쪽으로 가는 Thin VM과 차별화된다. 이들은 OS 인스턴스당 단일 컨테이너를 매핑하고 단일 컨테이너 중심 흐름을 통해 호스트하는 컨테이너와 함께, 새로운 VM을 인스턴스화하는 데 사용되는 통합 워크플로우를 통해 연속체에서 오른쪽으로 가는 순수 컨테이너와 차별화된다.

클라우드 네이티브 기술의 연속체에서의 VM 통합 컨테이너

 

컨테이너

컨테이너는 세 가지 클라우드 네이티브 시스템 특성을 모두 제공할 뿐만 아니라, 연속체 전반에 걸쳐 균형 잡힌 기능과 절충안을 제공한다. 도커 프로젝트에 의해 대중화되고 가장 잘 알려진 컨테이너는 수년 동안 다양한 형태로 존재해 왔으며, Solaris Zones 및 BSD Jails와 같은 기술에 뿌리를 두고 있다. 도커는 잘 알려진 브랜드이지만, 다른 공급업체들은 유사하지만 별도의 솔루션을 만들기 위해 runc와 containerd라는 기본 기술을 채택하고 있다.

컨테이너는 (VM뿐만 아니라) 분리, 기존 앱과의 탁월한 호환성 및 높은 수준의 운영 제어와 우수한 밀도 잠재력 및 소프트웨어 개발 흐름에 쉽게 통합할 수 있는 균형을 유지한다. 컨테이너는 주로 광범위한 구성 가능성과 운영 팀에 제공되는 선택의 폭이 넓기 때문에 운영이 복잡할 수 있다. 이러한 선택 사항에 따라 컨테이너는 상태 비저장, 동적 및 분리, 호스트 운영 체제 및 상태 비저장, 또는 그 사이의 임의의 위치에 있을 수 있다. 이러한 선택 정도는 컨테이너의 가장 큰 강점이자 가장 큰 약점이기도 하다. 이에 대응하여 시장은 서버리스와 같은 연속체 상의 시스템을 직접 만들어 일부 구성 가능성을 줄임으로써 규모 관리를 보다 용이하게 하고, 복잡성을 일부 추상화했다.

컨테이너는 VM에 대한 엄격한 1:1 매핑을 사용하지 않거나, 기본 호스트 운영 체제의 프로비저닝을 컨테이너 배포 흐름으로 포장함으로써 연속체 상에서 VM 통합 컨테이너와 차별화된다. 이러한 컨테이너는 사용자가 하드웨어 및 VM뿐만 아니라, 각 VM 내의 호스트 운영 체제 유지 관리를 포함한 모든 기본 인프라의 배포 및 운영을 책임지도록 함으로써 연속체 상에서 서비스형 컨테이너 플랫폼과 차별화된다.

클라우드 네이티브 기술의 연속체에서의 컨테이너

 

서비스형 컨테이너(CaaS)

컨테이너가 인기를 얻고 사용이 다양해짐에 따라, 쿠버네티스(및 OpenShift와 같은 파생 제품), Mesos 및 Docker Swarm과 같은 오케스트레이터는 대규모로 컨테이너를 배포하고 운영하는 데 점점 더 중요해지고 있다. 많은 컨테이너로 구성된 많은 수의 마이크로서비스를 배포하고 운영하는 데 필요한 복잡성을 상당 부분 추상화하지만, 이러한 오케스트레이터 자체는 설정 및 유지 관리가 복잡할 수 있다. 또한 이러한 오케스트레이터는 컨테이너 런타임에 집중되어 있으며, 기본 호스트의 배포 및 관리를 거의 지원하지 않는다. 정교한 조직은 이 문제를 해결하기 위해 자동화 툴링으로 포장된 Thin VM과 같은 기술을 사용하는 경우가 많지만, 이러한 접근 방식조차도 조직이 기본 컴퓨팅, 스토리지 및 네트워크 하드웨어를 관리하는 데 부담을 완전히 주지는 않는다. 서비스형 컨테이너(CaaS) 플랫폼은 기본적으로 세 가지 클라우드 네이티브 특성을 모두 제공하며 더 일반적인 구성 요소에서 조립되지만, 컨테이너 워크로드에 매우 최적화되어 있다.

주요 퍼블릭 클라우드 IaaS 제공업체는 이미 하위 수준의 자동화 및 배포에 광범위한 투자를 하고 있기 때문에, 많은 업체가 이 이점을 활용하여 사용자로부터 기본 하드웨어 및 VM 관리를 제거하기 위해 노력하는 컨테이너 실행을 위한 완벽한 플랫폼을 구축하기로 선택했다. 이러한 CaaS 플랫폼에는 구글 쿠버네티스 엔진, 애저 쿠버네티스 서비스 및 아마존 EC2 컨테이너 서비스가 포함된다. 이러한 솔루션은 오케스트레이터의 컨테이너 배포 및 관리 기능을 자체 플랫폼별 API와 결합하여 VM을 생성하고 관리한다. 이러한 통합을 통해 사용자는 기본 하드웨어나 가상화 계층을 관리할 필요 없이 용량을 보다 쉽게 프로비저닝할 수 있다. 구글 쿠버네티스 엔진과 같은 이러한 플랫폼 중 일부는 컨테이너에 중점을 둔 운영 체제(ex. 컨테이너 최적화 OS 또는 CoreOS)를 실행하는 Thin VM을 사용하여 호스트 운영 체제를 관리할 필요성을 더욱 줄인다.

CaaS 플랫폼은 하드웨어 및 VM 프로비저닝과 관련된 복잡성을 추상화하는 보다 포괄적인 기능 세트를 제공하여, 아래 그림의 연속체 왼쪽의 컨테이너와 차별화된다. 일반적으로 사용자가 기본 VM 및 호스트 OS를 직접 관리할 수 있도록 함으로써 연속체 오른쪽의 온디맨드 컨테이너와 차별화된다. 예를 들어, 대부분의 CaaS 구현에서 사용자는 노드에 직접 SSH를 적용하고, 루트 사용자로서 임의의 도구를 실행하여 진단을 지원하거나 호스트 OS를 사용자 지정할 수 있다.

클라우드 네이티브 기술의 연속체에서의 CaaS 플랫폼

 

온디맨드 컨테이너

CaaS 플랫폼은 규모에 맞게 컨테이너를 배포하고 운영하는 것을 단순화하지만, 여전히 사용자에게 기본 호스트 OS 및 VM을 관리할 수 있는 기능을 제공한다. 일부 조직에서는 이러한 유연성이 매우 바람직하지만, 다른 사용 사례에서는 불필요한 방해가 될 수 있다. 그런데 개발자의 경우, 기본 호스트 또는 VM에 대한 지식이나 구성 없이 단순히 컨테이너를 실행하는 기능은 개발 효율성과 민첩성을 향상시킬 수 있다.

온디맨드 컨테이너는 복잡성을 줄이고 구축을 용이하게 하기 위해 CaaS 플랫폼의 호환성과 제어 기능 중 일부를 대체하도록 설계된 일련의 기술이다. 온디맨드 컨테이너 플랫폼에는 AWS 파게이트 및 애저 컨테이너 인스턴스가 포함된다. 이러한 플랫폼에서 사용자는 호스트 OS에 직접 액세스할 수 없는 경우가 있으며, 컨테이너 워크로드를 배포하고 관리하기 위해 플랫폼 인터페이스를 독점적으로 사용해야 한다. 이러한 플랫폼은 세 가지 클라우드 네이티브 속성을 모두 제공하며 거의 틀림없이 필요로 한다고 봐야한다. 마이크로서비스로 앱을 구축하지 않는 것은 일반적으로 비현실적이며, 환경은 동적으로 관리되고 컨테이너로 배포될 수 있을 뿐이다.

 

온디맨드 컨테이너는 플랫폼별 인터페이스를 통해 전형적인 관리가 발생한다는 요구 사항과 함께, 호스트 OS 및 VM을 직접 제어할 수 있는 지원이 부족하다는 점에서 연속체 상의 CaaS 플랫폼과 왼쪽에 있는 CaaS 플랫폼을 구분한다. 온디맨드 컨테이너는 여전히 다른 컨테이너 플랫폼에서 실행할 수 있는 정상적인 컨테이너 이미지를 실행하기 때문에 연속체 상의 오른쪽에 있는 서버리스와 구별된다. 예를 들어, 사용자가 데스크톱의 컨테이너에서 직접 실행할 수 있는 동일한 이미지는 CaaS 플랫폼 또는 온디맨드 컨테이너에서 변경 없이 실행할 수 있다. 기본 OS 수준 종속성을 포함하여 앱을 위한 글로벌 휴대용 패키지로서의 이미지 형식의 일관성은 서버리스 환경과의 주요 차이점이다.

클라우드 네이티브 기술의 연속체에서의 온디맨드 컨테이너

 

서버리스 컴퓨팅

서버리스 아키텍처(*서비스로서의 기능 또는 FaaS라고도 한다.)를 사용하면, 조직이 물리적 또는 가상 서버를 유지 관리하거나 프로비저닝하지 않고도 소프트웨어 및 서비스를 구축하고 배포할 수 있다. 서버리스 아키텍처를 사용하여 만든 애플리케이션은 광범위한 서비스에 적합하며, 클라우드 워크로드가 증가함에 따라 탄력적으로 확장할 수 있다.

소프트웨어 개발 관점에서 서버리스 아키텍처를 채택하는 조직은 핵심 제품 기능에 초점을 맞추고, 기본 운영 체제, 애플리케이션 서버 또는 소프트웨어 런타임 환경을 완전히 무시할 수 있다.

서버리스 아키텍처를 사용하여 애플리케이션을 개발함으로써, 사용자는 기본 운영 체제 및 애플리케이션 서버에 보안 패치를 지속적으로 적용해야 하는 어려운 작업을 덜어준다. 대신, 이러한 작업은 이제 서버리스 아키텍처 제공업체가 담당한다.

서버리스 아키텍처에서 서버리스 공급자는 데이터 센터, 네트워크, 서버, 운영 체제 및 구성을 보호할 책임이 있다. 그러나 애플리케이션 로직, 코드, 데이터 및 애플리케이션 계층 구성은 여전히 공격에 대해 견고하고 탄력적이어야 한다. 그리고 이는 애플리케이션 소유자의 책임이다.

서버리스 아키텍처 및 공유 책임 모델

서버리스 모델을 채택하면 여러 가지 방법으로 애플리케이션 개발에 영향을 미칠 수 있다.

 

① 운영 오버헤드 감소

관리할 서버가 없기 때문에 개발자와 DevOps는 인프라 확장, 에이전트 설치 및 유지보수 또는 기타 인프라 관련 작업에 대해 걱정할 필요가 없다.

② 능률 향상

서버리스 애플리케이션은 데이터베이스 및 인증과 같은 것에 대해 관리형 서비스에 크게 의존하기 때문에 개발자는 애플리케이션의 비즈니스 로직에 자유롭게 집중할 수 있으며, 이는 일반적으로 AWS Lambda 또는 Google Cloud Functions와 같은 FaaS에서 실행된다.

③ 비용 절감

서버리스 애플리케이션에서 사용되는 대부분의 서비스에서 고객은 사용 비용만 지불한다. 예를 들어 AWS Lambda를 사용하면 고객은 기능 실행 비용을 지불한다. 이 가격 모델은 일반적으로 가상 머신과 마찬가지로 사용되지 않는 용량에 대해 비용을 지불하지 않아도 되기 때문에 비용에 큰 영향을 미친다.

 

온디맨드 컨테이너는 최종 사용자에게 노출되는 표면적을 크게 줄여주고, 따라서 관리와 관련된 복잡성을 줄이는 반면, 일부 사용자는 앱을 배포하는 훨씬 더 간단한 방법을 선호한다. 서버리스는 개발자가 서비스에 앱 코드만 제공하고, 그 다음 그 아래 스택의 나머지 부분을 자동으로 인스턴스화하도록 설계된 기술의 한 종류다.

서버리스 앱에서 개발자는 전체 컨테이너 이미지나 OS 구성 요소 없이 앱 패키지 자체만 업로드한다. 플랫폼은 동적으로 이미지로 패키지를 구성하고, 컨테이너에 있는 이미지를 실행하며, (필요한 경우) 기본 호스트 OS와 VM 및 이를 실행하는 데 필요한 하드웨어를 인스턴스화한다. 서버리스 모델에서 사용자는 가장 간단하고 가장 효율적인 배포 및 관리 경험을 위해 호환성과 제어를 가장 극적으로 절충한다.

 

서버리스 환경의 예로는 아마존의 Lambda와 애저의 Functions이 있다. Pivotal Cloud Foundry와 같은 많은 PaaS 제품들도 과거에 그렇게 판매되지 않았더라도 사실상 서버리스다. 겉으로 보기에는 컨테이너 고유의 클라우드 네이티브 속성이 부족해 보일 수 있지만, 컨테이너는 최종 사용자에게 직접 노출되지 않더라도 기본 구현에서 광범위하게 사용된다.

서버리스는 호스트가 실행하는 소프트웨어에 대한 가시성조차 없을 정도로 기본 호스트 및 컨테이너 런타임과 상호 작용할 수 없다는 점에서, 아래 그림의 온디맨드 컨테이너와 연속체의 왼쪽에 있는 차별화된다.

클라우드 네이티브 기술의 연속체에서의 서버리스

 

서버리스 아키텍처는 다음과 같은 애플리케이션을 보안할 때 고려해야 할 새로운 문제를 제시한다.

 

① 증가된 공격 표면

서버리스 기능은 HTTP 애플리케이션 인터페이스(API), 메시지 대기열, 클라우드 스토리지, IoT 장치 통신 등과 같은 광범위한 이벤트 소스의 데이터를 소비한다. 이러한 다양성은 특히 메시지가 프로토콜과 복잡한 메시지 구조를 사용할 때 잠재적인 공격 표면을 극적으로 증가시킨다. 이러한 메시지 중 많은 부분은 웹 애플리케이션 방화벽(WAF)과 같은 표준 애플리케이션 계층 보호로 검사할 수 없다.

② 공격 표면 복잡성

서버리스 아키텍처의 공격 표면은 아직 어느 정도 새로운 아키텍처임을 감안할 때 일부 사람들이 이해하기 어려울 수 있다. 많은 소프트웨어 개발자와 설계자는 아직 이러한 애플리케이션을 보안하는 데 필요한 보안 위험과 적절한 보안 보호에 대한 충분한 경험을 얻지 못했다.

③ 전반적인 시스템 복잡성

서버리스 아키텍처를 시각화하고 모니터링하는 것은 표준 소프트웨어 환경보다 여전히 더 복잡하다.

 

④ 부적절한 보안 테스트

서버리스 아키텍처에 대한 보안 테스트를 수행하는 것은 표준 애플리케이션을 테스트하는 것보다 더 복잡하며, 특히 이러한 애플리케이션이 원격 서드파티 서비스 또는 NoSQL 데이터베이스, 클라우드 스토리지 또는 스트림 처리 서비스와 같은 백엔드 클라우드 서비스와 상호 작용할 때 더욱 그렇다. 또한, 자동화된 검색 도구는 현재 서버리스 애플리케이션을 검사하는 데 적합하지 않다. 일반적인 검색 도구로는 다음의 목록이 있다.

⑴ DAST(Dynamic Application Security Testing): 이 도구는 HTTP 인터페이스에 대한 테스트 범위만 제공한다. 이러한 제한된 기능은 HTTP가 아닌 소스의 입력을 소비하거나 백엔드 클라우드 서비스와 상호 작용하는 서버리스 애플리케이션을 테스트할 때 문제를 만든다. 또한, 많은 DAST 도구는 고전적인 HTML/HTTP 요청/응답 모델 및 요청 형식을 따르지 않는 RESTful(표현 상태 전송)과 같은 웹 서비스를 부적절하게 테스트한다.
⑵ 정적 애플리케이션 보안 테스트(SAST): 이 도구는 소프트웨어의 취약점을 탐지하기 위해 데이터 흐름 분석, 제어 흐름 및 의미 분석에 의존한다. 서버리스 애플리케이션에는 이벤트 트리거 및 클라우드 서비스(ex. 메시지 대기열, 클라우드 스토리지 또는 NoSQL 데이터베이스)를 사용하여 서로 연결된 여러 개의 고유한 기능이 포함되어 있기 때문에 이러한 시나리오에서 데이터 흐름을 정적으로 분석하면 오탐이 발생할 가능성이 매우 높다. 반대로, 많은 도구에서 소스, 싱크 규칙은 FaaS 구성을 고려하지 않기 때문에 SAST 도구도 오탐으로 인해 어려움을 겪을 것이다. 이러한 규칙 세트는 서버리스 애플리케이션에 대한 적절한 지원을 제공하도록 진화해야 한다.

⑶대화형 애플리케이션 보안 테스트(IAST): 이 도구는 DAST 및 SAST와 비교할 때 서버리스 애플리케이션의 취약점을 정확하게 탐지할 가능성이 더 높다. 그러나 DAST 도구와 유사하게 서버리스 애플리케이션이 비 HTTP 인터페이스를 사용하여 입력을 소비할 때 보안 범위가 손상된다. 또한, IAST 솔루션은 테스터가 로컬 머신에 계측 에이전트를 배포해야 하며, 이는 서버리스 환경에서는 옵션이 아니다.
⑷ 기존 보안 보호(방화벽, WAF(웹 애플리케이션 방화벽), 침입 방지 시스템(IPS)/침입 탐지 시스템(IDS)): 서버리스 아키텍처를 사용하는 조직은 물리적(또는 가상) 서버 또는 운영 체제에 대한 액세스 권한이 없기 때문에 엔드포인트 보호, 호스트 기반 침입 방지, WAF 등과 같은 기존 보안 계층을 배포할 수 없다. 또한, 기존 탐지 로직과 규칙은 서버리스 환경을 지원하기 위해 아직 제대로 "번역"되지 않았다.

[3-2] 가상 머신

가상 머신
가상 머신은 일반적으로 하이퍼바이저라고 알려진 통제된 소프트웨어 공간 내에서 실행되는 컴퓨터의 이미지다. 하이퍼바이저는 처리, 메모리, 스토리지를 포함하여 가상 머신의 리소스를 호스팅하고 할당하는 도구이며, 비디오 디스플레이, 인쇄 및 네트워킹과 같은 주변 장치 및 외부 연결에 대한 I/O 통신을 관리한다. 설계상 가상 이미지는 유연하고 쉽게 복제되며 롤백되거나 복원된다.

가상 머신의 가장 일반적인 구현은 아마존 AWS, 마이크로소프트 애저 및 IBM Cloud와 같은 클라우드 서비스 제공업체를 통해 구현된다. 이러한 서비스는 클러스터로 알려진 유연한 수의 VM을 집계하고 다양한 네트워크 채널을 통해 클러스터된 VM 서비스에 대한 액세스를 제공한다. 대부분의 클라우드 구현은 확장 가능하며, 수요에 맞게 빠르게 확장할 수 있다. 예를 들어, 클라우드 기반 세금 계산 서비스는 계절적 수요 동안 수백 대의 가상 머신을 동시에 확장 및 활용한 다음, 세금 회계 마감일이 지나면 배포된 VM 수를 줄일 수 있다.

 

가상 환경은 또한 애플리케이션 호스트로 존재할 수 있고 애플리케이션이 샌드박스 또는 엄격하게 제어되는 환경 내에서 실행되도록 허용할 수 있다. 샌드박스는 남용될 수 있는 추가 권한 없이 설계나 요구에 의해 애플리케이션에 대한 권한을 부여하면서 코드 선택이 할 수 있는 일을 제한한다. 예를 들어, 웹 브라우저는 본질적으로 샌드박스에서 웹 페이지를 실행한다.


Virtual PC, VirtualBox 및 VMware와 같은 호스트 기반 가상화 프로그램은 하이퍼바이저로 설정할 수 있으며, 데스크탑에서 가상 머신과 네트워크를 실행할 수 있다. 이러한 로컬 VM은 일반적으로 애플리케이션이 포함된 전체 운영 체제를 포함하며, 로컬 호스트 및 기타 가상 머신과 독립적으로 실행된다. 이러한 도구는 개발 및 테스트에 이상적이다. VM을 사용하면 가상화된 운영 체제에 소프트웨어를 설치하고 구성하여 표준 컴퓨터에서 실행되는 것처럼 실행할 수 있다. 샌드박스가 설치된 VM을 사용하면, 멀웨어를 설치하고 분석할 수도 있다.

[3-3] 쿠버네티스

쿠버네티스
쿠버네티스는 애플리케이션 배포 및 관리와 관련된 모든 것을 더 쉽게 해준다.

 

① 쿠버네티스는 롤아웃과 롤백을 자동화하여 서비스 상태를 모니터링하여 서비스 상태가 나빠지지 않도록 한다.

 

② 서비스에 대해 지속적으로 건강 점검을 실행하여, 장애가 발생하거나 중단된 컨테이너를 다시 시작하고 성공적으로 시작된 것을 확인했을 때만 고객에게 서비스를 광고한다.

 

③ 쿠버네티스는 사용률에 따라 서비스를 자동으로 확장하거나 축소하여 필요할 때 필요한 것만 실행하도록 보장한다.

 

④ 쿠버네티스는 컨테이너와 마찬가지로 클러스터를 선언적으로 관리할 수 있으며, 설정을 쉽게 버전 제어하고 복제할 수 있다.

 

쿠버네티스 튜토리얼

https://kubernetes.io/docs/tutorials/kubernetes-basics

쿠버네티스 체험 학습

https://kubernetes.io/docs/tutorials/kubernetes-basics/

구글 쿠버네티스 문서
https://cloud.google.com/kubernetes-engine/docs

VM웨어 쿠버네티스 프리 코스

https://www.kube.academy

[3-4] 컨테이너

컨테이너

컨테이너는 애플리케이션이 실제로 실행되는 환경에서 추상화할 수 있는 논리적 패키징 메커니즘을 제공한다. 이러한 디커플링을 통해 컨테이너 기반 애플리케이션은 대상 환경이 프라이빗 데이터 센터, 퍼블릭 클라우드, 심지어 개발자의 개인용 노트북이든 상관없이 쉽고 일관되게 배포될 수 있다.

컨테이너화는 개발자들이 애플리케이션 로직과 종속성에 초점을 맞추는 반면, IT 운영 팀은 애플리케이션에 특화된 특정 소프트웨어 버전 및 구성과 같은 애플리케이션 세부 사항을 신경 쓰지 않고 구축 및 관리에 집중할 수 있기 때문에 우려 사항을 깔끔하게 분리할 수 있다.

컨테이너 및 구글 클라우드
https://cloud.google.com/containers

도커에 의한 컨테이너 설명
https://www.docker.com/resources/what-container

도커 데스크탑과 랩 실행 환경
https://www.docker.com/101-tutorial
https://www.docker.com/play-with-docker

도커 엔진 프리 트레이닝
https://www.docker.com/products/container-runtime

Google Kubernetes Engine 문서  |  Google Kubernetes Engine(GKE)  |  Google Cloud

Learn Kubernetes Basics