K01: Insecure Workload — 보안이 취약한 워크로드

쿠버네티스에서 컨테이너는 기본적으로 최소 권한으로 실행되어야 합니다. 하지만 별도의 설정이 없으면 컨테이너는 루트(root) 권한으로 실행되거나, 호스트 시스템의 중요한 파일에 접근할 수 있는 위험을 그대로 안게 됩니다. securityContext를 생략하는 것은 “안전하다"가 아니라 “가장 위험한 기본값을 그대로 쓰겠다"는 선택입니다.

미션: 루트 권한 및 권한 상승 방지

컨테이너가 루트 권한으로 실행되면, 컨테이너 내에서 발생한 보안 사고가 호스트 시스템 전체의 침해로 이어질 가능성이 매우 커집니다.

1. 취약한 코드 (`vulnerable.yaml`)

보안 설정(securityContext)이 누락되어 기본값으로 실행되는 Pod입니다.

apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
    - name: app
      image: nginx
      # 🚨 위험: 보안 설정이 없어 컨테이너가 기본적으로 root 권한으로 실행됨

분석: 아무런 제약이 없기 때문에 컨테이너 내부의 프로세스는 루트 사용자로 실행됩니다. 공격자가 컨테이너 내부에 침입할 경우, 루트 권한을 이용해 시스템 설정을 변경하거나 다른 파일에 접근하기 훨씬 수월해집니다.

2. 해결책 코드 (`fixed.yaml`)

securityContext를 명시해 컨테이너의 권한을 엄격하게 제한합니다.

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
    - name: app
      image: nginx
      securityContext:
        runAsNonRoot: true            # ✅ 개선: 루트 사용자로 실행 금지
        runAsUser: 1000               # ✅ 개선: 루트가 아닌 일반 사용자 ID로 실행
        readOnlyRootFilesystem: true  # ✅ 개선: 루트 파일시스템을 읽기 전용으로 설정
        allowPrivilegeEscalation: false # ✅ 개선: 권한 상승 불가능하게 설정

설정	막는 대상
`runAsNonRoot: true`	루트 권한으로 실행되는 것 자체를 원천 차단
`readOnlyRootFilesystem: true`	공격자가 컨테이너 내부에 악성 스크립트를 다운로드하거나 파일을 수정하는 것
`allowPrivilegeEscalation: false`	자식 프로세스가 부모 프로세스보다 더 많은 권한을 얻는 것

allowPrivilegeEscalation이 정확히 어떤 커널 메커니즘(no_new_privs)을 막는지, 그리고 privileged: true와 무엇이 다른지는 privileged:false인데도 위험한 이유에서 더 깊게 다룹니다.

실습: 공격 → 방어 검증

1) 공격 — 취약한 Pod에 침투

kubectl apply -f vulnerable.yaml
kubectl exec -it insecure-pod -- sh

whoami
# root

touch /test.txt
ls -l /test.txt
# 파일이 생성됨 — 루트 파일시스템 쓰기 가능

root로 실행 중이고 파일시스템도 쓰기 가능하다는 것은, 컨테이너 하나가 뚫리면 그 안의 어떤 파일이든 건드릴 수 있다는 뜻입니다.

2) 방어 — 패치 적용 후 동일한 공격 재시도

kubectl apply -f fixed.yaml
kubectl exec -it secure-pod -- sh

whoami
# 1000 (root가 아님)

touch /test.txt
# touch: /test.txt: Read-only file system

더 이상 root가 아니며, 파일시스템 수정 시도는 Read-only file system 에러로 즉시 실패합니다. 공격 표면이 “권한 상승"에서 “애초에 쓸 수 있는 게 없음"으로 바뀐 것입니다.

체크리스트

모든 Pod/컨테이너에 securityContext가 명시되어 있는가 (기본값에 의존하지 않는가)
runAsNonRoot: true가 설정되어 있는가
readOnlyRootFilesystem: true가 애플리케이션 요구사항과 충돌하지 않는 선에서 적용되어 있는가
allowPrivilegeEscalation: false가 설정되어 있는가
이 네 가지를 매번 수동으로 점검하는 대신, Pod Security Admission의 restricted 레벨로 네임스페이스 전체에 강제하고 있는가

K01은 쿠버네티스 보안의 가장 기본인 “컨테이너를 가두고, 권한을 최소화하는 법"을 배우는 첫 관문입니다. 다음 미션(K02: Authorization)에서는 컨테이너 내부가 아니라 클러스터 API에 대한 권한, 즉 RBAC 과다 권한 문제를 다룹니다.

K02: Authorization — 과도한 RBAC 권한