클라우드 네이티브 관련 이론 정리

클라우드 네이티브 개요

: 클라우드 환경의 특성을 고려하여 만들어진 애플리케이션 및 시스템

클라우드 네이티브 4C 계층 구조

1. 클라우드 : 기초 인프라 자원을 제공하는 최하위 계층 -> CSP가 관리, 물리적 보안, 네트워크 격리, IAM
2. 클러스터 : 컨테이너화된 애플리케이션을 관리하고 실행하는 오케스트레이션 계층 -> Kubernetes 등이 해당, 노드 간 통신, 스케줄링, API 접근 제어 등..
3. 컨테이너 : 애플리케이션이 구동되는 격리 환경 -> Docker등이 해당한다. 이미지 무결성, 런타임 보안, 컨테이너 탈출 방지, 불필요한 권한 제거 #Seccomp, #Runtime Security,
4. 코드 : 비즈니스 로직이 실행되는 애플리케이션 코드 계층 -> App security, DevSecOps, SCA, FaaS

클라우드 네이티브 전환 단계

1. 레거시 : 온프레미스, 모놀리식 아키텍처, 수동 배포 -> 높은 유지보수 비용과 낮은 유연성
2. 클라우드 : 가상 머신 위주 인프라 활용, Re-Platform, PaaS 부분 도입
3. 클라우드 네이티브 : MSA+컨테이너 기반 애플리케이션, Re-Factor, DevOps+CI/CD 파이프라인 자동화

-> Agility, Scalability, Resilience, Cost Efficiency, Automation

클라우드 서비스 모델 비교

1. IaaS : 리소스를 제공받고, OS 설치부터 미들웨어, 런타임, 데이터까지 사용자의 관리 책임이 가장 넓은 모델
2. PaaS : 인프라와 런타임 관리는 CSP 관할, 사용자는 애플리케이션 코드와 데이터 보안에 전념
3. CaaS : 컨테이너 오케스트레이션 엔진을 관리형으로 제공받음, 사용자는 컨테이너 이미지와 설정 보안에 집중

컨테이너 기술

1. 이미지와 레이어 구조

Union File System : 여러 종류의 File System을 하나로 보이게 하는 기술
: 수정된 Layer만 새로 빌드 후 교체
: Image를 여러개 쌓아가고 그 위에 새로운 Container 생성

2. 격리 기술

컨테이너는 가상의 격리 환경을 만들기 위해 리눅스의 namespace과 cgroup이라는 기능을 사용한다.

1. namespace: 프로세스를 독립시켜주는 가상화 기술로, 각 컨테이너에서 실행된 프로세스가 시스템 등에 대해 독립할 수 있게 해줌

2. Cgroups: 자원에 대한 제어를 가능하게 해주는 리눅스 커널의 기능

3. Dockerfile과 빌드 파이프라인

4. 레지스트리와 배포

Dockerfile : Image 생성에 필요한 명령어를 기재한 문서
위 이미지 생성 후 컨테이너 빌드

push하게 되면 Registry에 Image를 저장하게 된다. 이 레지스트리에서 이미지를 불러와서 컨테이너 실행 가능

• Docker Hub : 깃허브처럼 다른 사용자들이 공유한 Image들 저장소

쿠버네티스 아키텍처

Google이 공개한 대표적인 오픈 소스 컨테이너 오케스트레이션 시스템이다.

*클러스터 구조 : 전체를 관리하는 Kubernetes Master와 Container가 배포되는 Worker Node로 구성되어 있다.

Control Plane Components

1. API server : 클러스터의 중앙 제어점(Gateway), 유일하게 etcd와 통신하는 컴포넌트이다.
2. etcd : 모든 클러스터 데이터(설정,상태)를 저장하는 고가용성 Key-Value 저장소이다. (백업 및 보안이 필수적)
3. kube-scheduler : 새로 생성된 pod를 감지하고 자원 상태, 제약 조건, 우선순위 등을 고려하여 적절한 node에 할당하는 역할을 수행한다.
4. kube-controller-manager : 노드 상태, 복제본 수 유지, 엔드포인트 관리 등 클러스ㅓ의 상태를 지속적으로 모니터링하고 조정한느 역할을 한다.

worker node

1. worker node

• Kubelet : 각 노드에서 실행되는 에이전트, PodSpec에 따라 컨테이너가 정상적으로 동작하도록 관리한다.
• Kube-proxy : 노드의 네트워크 규칙 유지 관리, 서비스 개념을 구현하고 Pod 간 통신을 가능하게 한다.
• Container Runtime : 컨테이너 실행을 담당하는 소프트웨어(CRI-O, docker engine 등이 있다)

2. workload API

• Deployment : 애플리케이션의 선언적 업데이트 및 배포 관리, ReplicaSet을 생성하여 상태를 유지한다.
• ReplicaSet : 지정된 수의 Pod 복제본이 항상 실행되도록 보장한다. (Pod의 생명 주기 관리)
• Managed Pods : 컨트롤러에 의해 생성되고 관리되는 실제 Pod

3. Pod

• 단일 배포 단위 : Kubernetes에서 생성, 관리하는 사장 작은 배포 단위이다.
• 공유 리소스 : Pod 내 컨테이너들은 스토리지와 네트워크를 공유한다.
• Sidecar 패턴 : 주 컨테이너와 보조 컨테이너가 함께 실행되는 구조이다.

클라우드 네이티브 보안의 중요성

1. 공유 책임 모델의 이해

• 책임 경계 변화 : PaaS/CaaS 등 모델에 따른 CSP와 사용자 간 보안 책임 영역 설정

2. 공격면 화장

• 마이크로서비스 간 통신 증가로 인한 네트워크 경로 복잡화
• 컨테이너 엔진, 오케스트레이터(k8s) 등 새로운 관리 대상 등장
• 수시로 변경되는 IP, port로 인해 전통적 방화벽 통제 한계

3. 보안의 자동화

• DevSecOps 통합
• IaC 보안 : 인프라 배포 전 코드 단계에서 설정 오류 사전 탐지
• 불변 인프라

4. 제로 트러스트 원칙 적용

• 지속적 검증 필요
• 워크로드 식별
• 업무에 필요한 최소한 권한만 부여

5. 통합 가시성 확보

• 실시간 모니터링
• 추적성 강화 : 분산 환경에서의 트랜잭션 추적 및 이상 행위 탐지 체계 구축

컨테이너 환경의 보안 위협

클라우드 환경에서 가장 많이 발생하는 사고 유형은 miscofiguration, data leak, unsafe interface/API 등이 있다.

1. 커널 공유 리스크 : 호스트 OS 커널 공유로 인한 격리 취약성
2. 이미지/레지스트리 위협 : 공급망 공격 취약점
3. 네트워크/런타임 위협 : ARP 스푸핑, 컨테이너 간 무단 통신(Lateral Movement)
4. 오케스트레이터 취약점 : Kubernetes API 노출, misconfiguration으로 인한 제어권 탈취

CSA Top Threats

1. Data breaches
2. Misconfiguration
3. Account Hijacking
4. Insecure APIs
5. Insider Threats
6. Workload Config

Host 레벨 보안 위협 대응 방안

1. Compliance Test : Docker Bench for Security, CIS Benchmark 등을 활용한 정기적인 호스트 설정 및 무결성 점검

-> Host 내 주요 파일 Permission 및 OS configuration에 대한 변조 검사

2. 커널 보안 강화 : SELinux, AppArmor, Seccomp를 활성화하여 커널 레벨에서 프로세스의 시스템 호출 및 접근을 강제 통제

3. 호스트 모니터링 : 호스트 레벨의 로그 감사(Auditd), 파일 무결성 모니터링(FIM) 및 이상 징후 실시간 탐지

4. 최소 권한 OS 사용 : COntainer Optimized OS(COS)와 같이 컨테이너 실행에 최적화되고 공격 표면을 줄인 전용 OS 도입

컨테이너 엔진 취약점

1. Docker demon 권한
   : Docker 데몬은 기본적으로 Root 권한으로 실행되기 때문에 데몬이 침해당할 경우 호스트 시스템 전체 제어권을 탈취당할 위험 존재

2. 소켓 노출 위험
   : 소켓을 컨테이너 내부에 마운트할 경우(/var/run/docker.sock) 컨테이너에서 호스트의 도커 데몬을 제어하여 Root 권한 획득 가능(Docker-out-of-Docker)

3. 런타임 취약점
   : Containerd-shim 등 런타임 구성요소의 버그로 인해, 컨테이너 프로세스가 상위 프로세스로 탈출하거나 좀비 프로세스화될 위험

4. 주요 CVE 사례 : CVE-2019-5736
   : 악성 컨테이너가 호스트의 runc 바이너리를 덮어씌워 실행 시 Root 권한을 획득하는 치명적 취약점

이미지/레지스트리 보안 위협

1. 취약한 라이브러리 포함
2. 임베디드 시크릿
3. 타이포스쿼팅
4. 신뢰할 수 없는 레지스트리

-> 공급망 공격

악성 컨테이너 이미지

• 리소스 하이재킹
• 익명 이미지, 봇 실행

-> 이렇기 때문에 리소스 사용량의 비정상적 급증을 모니터링하고, 신뢰할 수 있는 레지스트리만 허용하고, 런타임에서 프로세스 실행 차단이 필요하다.

오케스트레이터(K8s) 보안 위협

1. API 서버 노출
2. 인증 및 인가 부실
3. 구성요소 취약점
4. 부적절한 RBAC

• Kubernetes Security : Attacking And Defending Modern Infrastructure, RSA 2024

권한 상승 공격

시나리오

1. privileged 컨테이너 실행 시, 호스트의 모든 장치 접근 및 커널 기능 사용이 가능하다.
2. CAP_SYS_ADMIN 등 과도한 리눅스 커널 권한을 부여하여 시스템 제어권을 획득할 수 있다.
3. /proc, /sys, Docker 소켓 등을 마운트하여 호스트 OS 조작 및 탈출이 가능하다.
4. 커널 취약점 악용 : Dirty COW 등...

방어 전략

1. Security Context 설정 : allowPrivilegeEscalation : false, privileged: false 강제화
2. Drop Capabilities: 불필요한 리눅스 권한 제거
3. pod Security Standards: PSS 및 Admission Controller를 통한 정책 위반 차단
4. 런타임 보안(Seccomp & AppArmor) : 시스템 콜 필터링 및 프로필 적용으로 공격 표면 최소화

컨테이너 탈출

1. Escape the local Container
2. Attack Kubernetes Cluster
3. Attack Cloud Security Center

*usenix의 sec23_slides_he

데이터 유출 및 손실

1. 미암호화 etcdd/시크릿
2. 퍼블릭 클라우드 스토리지 : S3 버킷, Azure Blob 등 오브젝트 스토리지의 접근 제어(ACL) 설정 미비
3. 스냅샷 및 이미지 유출 : 민감 정보가 포함된 EBS 스냅샷이나 VM 이미지가 실수로 퍼블릭 리포지터리에 공개되어 유출
4. 백업 데이터 미보호