Cloud-Native & Container Security

1. Overview

클라우드 네이티브 및 컨테이너 보안(Cloud-Native & Container Security, CCS)은 운영체제 위에 씌워진 얇은 가상화 막(Container) 속에서 벌어지는 수리적 탈옥 시도를 물리적으로 봉쇄하고, 무한히 확장되는 클라우드 하드웨어 자원의 권한 경계를 수치적으로 관리하는 '가상 영토 수호 물리학'입니다.

학습자는 하드웨어 커널을 공유하는 도커 컨테이너의 물리적 격리 한계와, 수천 개의 노드를 제어하는 **쿠버네티스(K8s)**의 보안 정책 수순을 배웁니다. 특히, 빌드된 컨테이너 이미지가 물리 디스크에 저장되기 전 취약점을 수리적으로 스캔하는 Shift Left 보안의 핵심 원리를 익힙니다. 이를 통해 동적으로 변하는 클라우드 환경에서도 시스템의 보안 등급을 상시 일정하게 유지하는 하이엔드 인프라 거버넌스 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Container Isolation Mechanics: Namespace 및 Cgroups를 통한 물리적 자원 격리
• Image Security: Base Image의 수리적 결합 보안 및 서명(Signing) 확인 수순
• Kubernetes Hardening: RBAC, Network Policy, Pod Security Admission의 수치 정책
• Cloud IAM in Depth: 클라우드 하드웨어 자원(S3, EC2 등)에 대한 세밀한 물리 접근 통제
• Runtime Security: 실행 중인 컨테이너에서 발생하는 비정상 시스템 콜 탐지 및 물리 차단

Out-of-Scope

• 퍼블릭 클라우드 서비스 자체의 물리적 데이터센터 보안 (클라우드 사업자의 책임 영역)
• 컨테이너 내부 애플리케이션의 시큐어 코딩 상세 (10-03-02 SCI 영역에서 분담)

Boundaries

• CCS vs. DRI: DRI(10-01-04)가 '데이터를 어떻게 암호화할 것인가'라는 결과에 집중한다면, CCS는 '그 데이터가 처리되는 클라우드 하드웨어 환경 자체를 어떻게 안전하게 격리할 것인가'라는 환경 구축의 물리학에 집중하여 구분합니다.

3. Counterexample

• 단순히 "도커 쓰면 안전하다"라 설명하는 것은 CCS 학습이 아닙니다. 왜 컨테이너가 VM보다 가볍지만 하드웨어 커널 취약점에 노출되었을 때 호스트 OS 전체로 물리적 위협이 전파되는 'Container Escape'에 수리적으로 취약한지 증명할 수 있어야 하며, 쿠버네티스의 'Secrets' 객체가 물리적인 기본 설정($Plaintext$ $base64$) 상태로 방치되었을 때 발생하는 수치적 보안 붕괴를 논증하지 못한다면 클라우드 보안의 실체를 이해하지 못한 것입니다.

4. Prerequisites

• IaC & Deployment Physics (Basic): 09-03-03의 컨테이너 빌드 및 오케스트레이션 기초 이해가 필수입니다.
• Operating Systems & System Mechanics (Basic): 03-01-XX의 리눅스 커널, 네임스페이스, 프로세스 격리 이해가 필수입니다.

5. Learning Map

1. The Transparent Shell: 컨테이너라는 가상의 하드웨어 껍데기가 호스트 OS와 수리적으로 어떻게 격리되는지 이해합니다.
2. Scan Before Ship: 하드웨어 영토에 발을 들이기 전, 보관함(Registry)에 들어오는 모든 짐(Image)을 검사합니다.
3. Orchestrating Walls: 수만 개의 컨테이너가 서로를 물리적으로 침범하지 못하도록 수치적 질서(Policy)를 세웁니다.
4. Cloud Guard: 사람의 손이 닿지 않는 수천 대의 서버 보안을 자동화된 수리 정책으로 완벽히 통제합니다.

6. Learning Topics

Basic

Core: 컨테이너 격리와 하드웨어 커널 (Container Physics)

• Why to Learn: 컨테이너 한 대가 해킹당해도 우리 물리 서버 전체가 털리지 않도록 하기 위해서입니다.
• What to Learn:
  • Namespace: 프로세스가 보는 하드웨어 자원(IP, PID 등)을 수리적으로 분리하는 법
  • Cgroups: 개별 컨테이너가 쓸 수 있는 하드웨어 파워($CPU, MEM$)의 물리적 수치 제한
  • Rootless Container: 컨테이너 내부 사용자가 하드웨어 최고 권한(Root)을 갖지 못하게 하는 물리 수순
• How to Learn:
  • 도커 컨테이너 안에서 hostname을 바꿨을 때, 실제 물리 호스트의 이름은 변하지 않는 수리적 분리 현상 확인 실습
  • --privileged 옵션으로 실행된 컨테이너가 호스트의 하드웨어 장치를 어떻게 직접 만질 수 있는지 위험성 테스트
• Implement: 가장 공격 표면이 적은 정적 바이너리 기반의 HardenedDockerfile

Recommended

Core: 이미지 스캐닝과 취약점 관리 (Supply Chain Hardening)

• Why to Learn: 남이 만든 컨테이너 이미지 속에 숨겨진 "보안 폭탄"이 우리 하드웨어에 배포되는 것을 막기 위함입니다.
• What to Learn:
  • Vulnerability Scanning: 이미지 레이어 속의 패키지 버전과 수리적 취약점(CVE) 대조
  • Distroless Images: 패키지 매니저나 쉘조차 빼버린 극단적인 물리적 공격 표면 축소
  • Image Signing: "이 이미지는 우리 팀이 검증한 것"임을 수리적으로 증명하는 도장(Cosign 등)
• How to Learn:
  • Trivy나 Clair를 사용하여 대중적인 이미지(Nginx 등)의 수리적 취약점 개수를 수치로 뽑아보는 실습
  • 이미지 용량($MB$)이 작아질수록 보안성과 하드웨어 배포 속도가 어떻게 동시에 개선되는지 상관관계 분석
• Implement: 빌드 시 자동으로 취약점을 체크하고 통과 시에만 서명하는 SafeShipPipeline

Practical

Core: 쿠버네티스 보안 정책과 가시성 (K8s Governance)

• Why to Learn: 수천 대의 서버로 구성된 거대 클러스터에서 단 한 대의 설정 실수로 인한 하드웨어 붕괴를 막기 위해서입니다.
• What to Learn:
  • Pod Security Admission (PSA): 보안 수칙을 어긴 컨테이너의 물리적 생성을 하드웨어 수준에서 거부
  • Network Policy: 마이크로서비스 간의 통신을 '최소 권한 원칙'에 따라 수치적으로 차단
  • RBAC (Role-Based Access Control): 누가 어떤 하드웨어 자원을 수리적으로 건드릴 수 있는지 결정
• How to Learn:
  • YAML 설정 하나로 특정 Pod가 인터넷에 접속하지 못하도록 물리적으로 고립시키는 Network Policy 적용 실습
  • 'Admission Controller' 가 정상적인 요청을 가로채어 보안 규격에 맞는지 수리 검열하는 물리 수순 연구
• Implement: 외부 노출이 전혀 없는 프라이빗 클러스터용 보안 기준 ClusterHardeningPlan

Advanced

Core: 클라우드 IAM과 실시간 대응 (Cloud Native SOC)

• Why to Learn: 아이디/패스워드가 아닌 '클라우드 하드웨어 간의 수리적 자격 증명'이 털리는 고차원 사고에 대비하기 위함입니다.
• What to Learn:
  • IAM Roles for Service Accounts (IRSA): 하드웨어 노드가 아닌 '코드(Pod)' 단위로 클라우드 권한을 물리 할당
  • Runtime Security Observation: 실행 중인 컨테이너가 갑자기 평소와 다른 파일에 물리 접근하는 행위 감지(Falco 등)
  • Cloud Misconfiguration Audit: 테라폼(IaC) 코드를 분석하여 물리적 보안 구멍을 사전에 수치 감별
• How to Learn:
  • 컨테이너가 갑자기 /etc/shadow 파일에 접근할 때 실시간으로 하드웨어가 알람을 울리는 물리 현상 관찰 실습
  • 클라우드 관리 콘솔에서 'Public S3 Bucket'을 찾아내어 즉각 'Private'으로 수리 자동 전환하는 람다 함수 구현
• Implement: 인프라 코드의 보안 등급을 매기고 취약 설정을 지적하는 CloudInfrastructureAudit

7. Terminology

8. References

Primary

• [P3] CyBOK - Infrastructure Security Knowledge Area (Virtualization & Cloud) — Definitive theory.
• [P5] SFIA v9 - Software Engineering / Methods and tools (Information communications) — Management standards.

Secondary

• [Container Security] Liz Rice — The fundamental textbook for CCS physics.
• [Kubernetes Security and Observability] Brendan Burns — For orchestration focus.

Industry

• [CIS Kubernetes Benchmark] — The gold standard for hardening.
• [NIST SP 800-190: Application Container Security Guide] — Regulatory compliance.

9. Final Checklist

Primary

• '컨테이너'가 '가상 머신(VM)'보다 하드웨어 격리 수준이 물리적으로 왜 낮은지 수리적으로 설명 가능한가? (P3)
• '쿠버네티스 API 서버'가 뚫렸을 때, 물리적 영향을 받는 클러스터 하드웨어의 범위를 수치적으로 기술할 수 있는 가? (P3)

Secondary

• 'Multi-stage Build'가 컨테이너 이미지의 수리적 취약점 개수를 물리적으로 어떻게 줄여주는지 소통 가능한가?
• Cloud IAM Condition 설정을 통해 특정 하드웨어 위치(IP)에서만 요청을 승인하는 물리적 제약을 논증할 수 있는 가?

Industry

• 실무 클라우드 환경에서 'Secrets' 관리 시스템(AWS Secrets Manager 등)을 앱 코드와 물리 분리하는 거버넌스 수순을 제안할 수 있는 가? (SFIA)
• **OPA (Open Policy Agent)**를 통해 '보안 정책 as Code'를 하드웨어 배포 단계에 수리적으로 강제하는 구조를 분석할 수 있는 가?