MSA에 따라 구현하며 lightweight container로 실행하여 개발, 통합, 테스트, 배포가 지속적으로 이루어진다.
민첩한 애플리케이션 개발 및 배포
빠르고 효율적인 서비스 제공 가능
높은 유연성, 확장성, 비용 효율
Cloud-Native Layer (4C)
Code: FaaS/애플리케이션 코드 실행
E.g., Google Cloud Functions, AWS Lambda, Knative
Container: 컨테이너 애플리케이션 구동 (경량화된 가상화 환경)
E.g., Cilium, Containerd, Docker
Cluster: 컨테이너의 컴퓨팅 자원 제공 (Container Orchestration으로 여러 컨테이너의 배치, 스케줄링, 네트워킹, 로깅 등을 자동화)
E.g., K8s, OpenShift, Istio
Cloud: 물리 서버/네트워크 등 인프라 자원 제공 (on-demand방식으로 application이 실행될 infrastructure 제)
E.g., Google Cloud, AWS, Azure
--> 컨테이너 기술은 2000년대 중반 Linux Container(LXC) 기술이 시초로 '호환성' 문제를 해결하기 위해 등장하였습니다. Software가 다른 computing 환경 (네트워크 환경, 스토리지, 보안 등의 정책)으로 이동하더라도 안정적인 실행을 가능하도록 하는 것이 목표입니다.
Copy-on-Write: 초기에 Read-only였다가 수정요청이 들어온 데이터나 계층만 복사해서 Read-write layer에 저장하는 방식
수정된 부분만 pull하면 되니까 maintenance 측면에서 Fast&Convenient하다는 강점이 있음
Layer
Read-Only Layer -> 컨테이너를 제외한 하위 layer
Read-Write Layer -> 수정 가능한 컨테이너, 항상 최상
Networking
Docker 내 Networking Overlay Network를 활용한다. (Network Virtualization) 물리적 네트워크는 손대지 않고도 다양한 네트워크 토폴로지를 구현할 수 있도록 한다. 패킷을 가상 네트워크 헤더와 물리 네트워크 헤더로 나누어 캡슐화하고 라우팅한다.
Container Orchestration
Container Orchestration은 다수의 컨테이너(서비스)의 실행을 관리 및 조율하는 것이다. 컨테이너 수가 많아지면 관리와 운영에 어려움이 생기는데 이때 컨테이너 배포 및 관리를 효율적으로 제어 / Scaling (Scheduling, Load Balancing) / Clustering (Grouping) / Logging, Monitoring을 하는 것이다.
주요 platform으로는 Docker Swarm, Google Kubernetes, Apache Mesos, AWS ECS가 있다.
(좌) Docker Swarm (우) K8s
Docker Swarm
Docker에서 개발한 자체 오케스트레이션 기능으로, Conrol plane은 master, data plane은 worker의 구조를 가지고 있다.
단순하고 간결성 및 사용의 용이성을 원한다면 Docer Swarm
K8s
Google에서 공개한 오픈소스 Container Orchestration System으로 자사에서 사용. 완벽한 Master-Worker 구조를 따른다.
커스터마이증 및 기능적인 탄력성이 필요하고 Complexity가 높은 경우 K8s (especially, Auto-Scaling)
--> 현재는 Docker (Engine) + K8s (Orchestration)가 실질적인 표준으로 자리를 잡고 있다. 최근 Google에서 Containerd engine을 사용하여 시장 점유율을 높이려는 노력을 하고 있다.
3. Container Security
3.1 Containers limitations
Persistence
VM은 자체 파일 시스템을 가져서 persistency가 제공되지만, Container는 프로세스 형태로 실행되기 때문에 이전 전 컨테이너에 대한 정보가 없으며 이를 위해서는 migration을 하는 작업이 필요
Performance
VM보다 overhead는 적지만 native에는 미치지 못함 (daemon, cgroup 등 사용하기 때문에)
Security (Isolation)
어쨌든 Host OS와 동일한 OS kernel을 공유하기 때문에 VM에 비해 Isolation이 느슨하다.
Fault Tolerance 등의 장치가 존재하지만, 보안성 및 안정성 측면에서 떨어질 수 밖에 없다.
--> 기존의 시스템/네트워크 보안 위협 + 가상화 환경에서의 보안 위혐 + "컨테이너에서의 보안 위협"
3.2 Container Sucurity
호스트 공격을 통한 컨테이너 공격
문제: Host OS kernel을 공유하기 떄문에 privilege software인 Host OS가 손상되면 모든 컨테이너의 위험으로 이어진다.
해결: 호스트 보호 & 컨테이너 보호 기술
Compliance Test: Host 내 주요 파일 Permission 및 OS Configuration에 대한 변조 검사 (안전한 설정을 유지하고 있는지 확인하는 테스트이다.)
Orchestrator 및 Container Engine 취약점
문제: 플랫폼이 해킹당하면 컨테이너를 마음대로 조작 및 삭제 가능
해결: 플랫폼 보호 기술
즉, Docker와 K8s 플랫폼에 대한 보호라고 생각하면 쉽다. (E.g., 관련 프로세스 모니터링, 플랫폼 변조 감지, 주요 Event 점검(e.g., 컨테이너가 이상하게 종료) 등)
컨테이너 네트워킹 관련 보안 취약점
문제: 통신이나 네트워크를 악용한 공
해결: 컨테이너 보호 및 인증 기술
컨테이너 보호: 시스템 보안(OS 내 보안 기능 활용, SELinux, AppArmor) + 네트워크 보안(컨테이너 간 통신 모니터링, eBPF)의 결합체이다. 또한 AI 기반으로 악성 컨테이너 탐지를 할 수도 있다. (e.g., system call trace, flow-level information)
SELinux는 리눅스 커널에서 동작하는 보안 모듈로, 시스템 리소스 접근을 엄격히 제안하고 AppArmor는 리눅스 시스템에서 프로세스의 행동을 제한하는 보안 모듈이다.
인증 기술: Zero Trust Indentity로 인증 절차 없이는 컴포넌트 간 신뢰를 보장하지 않는다는 의미이다. 시스템 내 모든 operation 전에 authentication을 통한 확인을 거친다. (user ↔ Container ↔ Registry/Data Storage)
