[KCSA] Cloud Native 보안과 Kubernetes

GPT를 이용하여 문서를 한국어로 번역하였습니다. 

✨ 클라우드 네이티브 워크로드를 안전하게 운영하는 개념들

Kubernetes는 클라우드 네이티브 아키텍처 기반으로 설계되었으며,
CNCF(Cloud Native Computing Foundation) 가 제시하는 클라우드 네이티브 보안 모범 사례를 따르고 있어.

---

🔐 클라우드 네이티브 정보 보안의 수명 주기

CNCF의 화이트페이퍼에서는 보안 제어와 모범 사례를 각 수명 주기(lifecycle phase) 별로 나눠서 설명하고 있어. Kubernetes도 이 구조를 따름.

---

🔧 1. 개발(Develop) 단계

개발 환경과 애플리케이션 설계를 보안 중심으로 준비하는 단계

• 개발 환경의 무결성 보장
• 보안 모범 사례에 따라 애플리케이션 설계
• 최종 사용자 보안 고려

구체적인 실천 방법:

• 제로 트러스트(Zero Trust) 아키텍처 채택 → 내부 위협도 방어
• 보안을 고려한 코드 리뷰 프로세스 정의
• 시스템의 위협 모델(Threat Model) 작성 → 신뢰 경계 파악, 리스크 도출
• 퍼징(fuzzing), 보안 카오스 엔지니어링 등 자동화된 보안 테스트 도입

---

📦 2. 배포 준비(Distribute) 단계

컨테이너 이미지 및 클러스터 구성요소 등 공급망 보안 관리

구체적인 실천 방법:

• 컨테이너 이미지/컴포넌트에 대해 취약점 스캔
• 전송 중 암호화, 신뢰 체인(chain of trust) 적용
• 보안 패치에 민감하게 반응하고 의존성 업데이트
• 디지털 서명/인증서 등으로 진위 확인
• 보안 피드 구독으로 실시간 위험 감지
• 이미지 접근 제한 (ex. Private Registry 사용)

---

🚀 3. 배포(Deploy) 단계

무엇을, 누가, 어디에 배포할 수 있는지를 제어

• 배포 시 서명된 이미지 검증 등 보안 조치 적용
• Kubernetes 클러스터는 애플리케이션의 실행 기반 인프라 → 클러스터 자체 보안이 핵심!

---

⚙️ 4. 실행(Runtime) 단계

실행 중인 애플리케이션의 접근 권한 / 컴퓨팅 / 저장소 보안 관리

---

🔑 접근 보안 (Access)

• Kubernetes API 보안이 가장 중요
• 인증/권한 설정 필수 (ex. ServiceAccount 사용)
• TLS로 API 통신 암호화 (노드와 컨트롤 플레인 간 포함)
• 자체 CertificateSigningRequest 사용 시 남용 방지 필요

---

🧮 컴퓨팅 보안 (Compute)

• 컨테이너는 격리 & 집합 실행이 가능 → 보안 트레이드오프 조정 필요
• Kubernetes는 특정 컨테이너 런타임을 강제하지 않음, 직접 보안성 확인해야 함

구체적인 실천 방법:

• Pod Security Standards 적용 → 최소 권한 실행 보장
• 컨테이너 전용 운영체제(읽기 전용 OS) 사용
• ResourceQuota, LimitRange로 자원 분배 관리
• 신뢰 수준 다른 워크로드는 노드 분리
• AppArmor 또는 seccomp 등 Linux 보안 모듈 사용
• 보안성 있는 컨테이너 런타임 선택

---

💾 저장소 보안 (Storage)

구체적인 실천 방법:

• 암호화 지원 스토리지 플러그인 사용
• Kubernetes API 오브젝트 암호화 설정
• 백업 및 복구 테스트 수행
• 스토리지 연결 시 인증 보장
• 앱 내에서 자체적으로 데이터 암호화 처리
• HSM(하드웨어 보안 모듈) 을 통한 키 생성/운영

---

🌐 네트워크 보안 (Networking and Security)

• NetworkPolicy, Service Mesh 등을 활용해 트래픽 제어
• VPN 등의 네트워크 암호화 기능을 제공하는 플러그인 사용 가능
• 어떤 네트워크 플러그인을 사용하느냐가 전송 중 데이터 보안에 큰 영향을 줌

---

👀 관측성과 실행 보안 (Observability & Runtime Security)

• Kubernetes는 다양한 모니터링 도구, 대시보드, 로깅 도구와 연동 가능
• 보안 사고 상황에서도 신뢰할 수 있도록 데이터 수집 체계 전반의 무결성 보호 필요

보안 수준을 높이려면:

• Kubernetes 아래 계층의 보안 조치도 고려 (예: Measured Boot, 인증된 시간 분배)
• 감사 로그를 변조 불가능하고 기밀성 있는 방식으로 보호

---

🛡️ AppArmor란?

✅ 한 줄 요약:

"컨테이너가 어떤 파일에 어떻게 접근할 수 있는지 제어해주는 보안 도구"

📌 특징:

• 프로파일(profile) 기반으로 동작해.
  즉, 특정 애플리케이션이나 컨테이너에 대해 “어디에 접근 가능하고, 뭘 할 수 있는지”를 정리한 규칙 집합이야.
• 예를 들어:
  • /etc/passwd는 읽기만 가능
  • /var/log/에는 접근 불가
  • 특정 바이너리 실행만 허용

🔧 Kubernetes에서 어떻게 적용해?

• Pod의 metadata에 AppArmor 주석(annotation) 을 달아 사용해:

annotations:
  container.apparmor.security.beta.kubernetes.io/my-container: localhost/my-apparmor-profile

---

🔐 seccomp란?

✅ 한 줄 요약:

"컨테이너가 어떤 리눅스 시스템 호출(syscall)을 쓸 수 있는지 제한하는 기술"

📌 시스템 콜(syscall)이 뭐야?

• 리눅스에서 파일 읽기, 네트워크 연결, 포트 열기 등을 할 때 시스템 콜을 통해 커널에 요청해.
• seccomp는 이 시스템 콜 중 위험한 것들만 차단할 수 있어.
  • 예: mount, ptrace, clone 같은 민감한 syscall 차단 가능

🔧 Kubernetes에서 어떻게 적용해?

• 예전에는 이런 주석으로 사용했지만 (지금은 deprecated):

annotations:
  seccomp.security.alpha.kubernetes.io/pod: runtime/default

• 지금은 securityContext 안에 seccompProfile로 설정해:

securityContext:
  seccompProfile:
    type: RuntimeDefault  # or Localhost for custom profile

---

🧱 정리 비교

항목 AppArmor seccomp

작동 방식	파일 시스템 접근 제어	시스템 콜 접근 제어
적용 단위	애플리케이션, 컨테이너	컨테이너, 프로세스
보안 수준	중간~높음 (정밀 제어)	기본~높음 (위험 syscall 차단)
사용 방식	프로파일을 정의해서 지정	허용할 syscall 목록 지정 또는 기본 프로필 사용

---

✅ Kubernetes에서 왜 중요한가?

• Kubernetes는 다양한 애플리케이션이 함께 실행되는 환경이기 때문에, 각 애플리케이션의 권한을 최소화해서 격리시키는 게 매우 중요해.
• AppArmor와 seccomp는 컨테이너 탈출(Container Escape) 같은 치명적인 보안 위협을 막아주는 필수 무기야 🔐

"컨테이너 탈출(Container Escape)" 은 컨테이너 안에서 실행되던 애플리케이션이 컨테이너 경계를 벗어나서 호스트 시스템에 접근하는 심각한 보안 사고입니다. 컨테이너의 목적은 격리(isolation) 인데, 이게 깨지는 거니까 보안 쪽에서는 최악의 상황입니다.