K04: Policy Enforcement — 보안 정책 강제 적용

쿠버네티스 환경이 커질수록 수많은 개발자가 클러스터에 리소스를 배포하게 됩니다. 이때 관리자가 일일이 설정을 검사할 수 없으므로, 보안 정책을 위반한 리소스는 아예 배포되지 않도록 강제하는 것이 필수입니다. K04는 Admission Controller(OPA Gatekeeper, Kyverno 등)를 활용한 이 자동화된 방어 체계를 다룹니다.

미션: 정책 위반 리소스 차단

취약한 환경에서는 보안 정책을 무시하고, 위험한 설정(예: 루트 권한 사용, 호스트 네트워크 사용 등)을 가진 Pod가 자유롭게 생성될 수 있습니다.

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

보안 정책이 적용되지 않은 환경에서는 아래와 같은 위험한 설정도 아무런 제재 없이 클러스터에 올라갑니다.

apiVersion: v1
kind: Pod
metadata:
  name: risky-pod
spec:
  hostNetwork: true  # 🚨 위험: 호스트 네트워크 사용 (호스트 통신 가로채기 가능)
  containers:
    - name: app
      image: nginx
      securityContext:
        privileged: true # 🚨 위험: 권한 상승 가능

분석: hostNetwork: true와 privileged: true는 쿠버네티스 보안에서 가장 피해야 할 설정입니다. 별도의 정책 강제 수단이 없다면, 누구든 이런 위험한 Pod를 배포해 클러스터 전체의 보안을 위협할 수 있습니다.

2. 해결책 (정책 적용 및 차단)

개별 Pod를 수정하는 대신, 클러스터 수준에서 ‘제약 조건(Constraint)‘을 정의해 배포 자체를 차단합니다.

# 예시: OPA Gatekeeper 제약 조건 (ConstraintTemplate으로 정의한 커스텀 정책 적용)
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDisallowHostNetwork
metadata:
  name: disallow-host-network
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    forbiddenHostNetwork: true # ✅ 개선: 호스트 네트워크 사용 Pod 배포 차단

실습: 공격 → 방어 검증

1) 공격 — 정책 없이 위험한 Pod 배포

kubectl apply -f vulnerable.yaml
# pod/risky-pod created

아무 제지 없이 Created가 뜹니다. 공격자는 이 Pod를 통해 호스트 네트워크와 커널 권한을 그대로 가져갈 수 있습니다.

2) 방어 — Admission 정책 활성화 후 동일한 배포 재시도

kubectl apply -f vulnerable.yaml
# Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request:
# [disallow-host-network] hostNetwork is not allowed

동일한 매니페스트가 API 서버 단에서 즉시 거부됩니다. 사용자의 실수나 공격자의 시도가 배포 시점에 원천 차단되는 ‘가드레일’이 형성된 것입니다.

체크리스트

• hostNetwork, hostPID, hostIPC, privileged: true를 금지하는 정책이 클러스터 전역에 걸려 있는가
• 정책이 Enforce(차단) 모드인지, 아니면 Audit(경고만) 모드로 방치되어 있는지 확인했는가
• 정책 위반 시도가 kubectl get events --field-selector reason=PolicyViolation으로 기록·조회되는가
• PSA와 어드미션 정책(Kyverno/Gatekeeper)이 서로 다른 계층에서 중복 방어하고 있는가 (하나가 뚫려도 다른 하나가 막도록)

“관리자가 일일이 다 검사할 수 없다면, 시스템이 자동으로 거부하게 하라"는 것이 K04의 핵심입니다. 다음 미션(K05: Network Segmentation)에서는 Pod가 배포된 이후의 문제, 즉 Pod 간 통신을 어떻게 격리할지를 다룹니다.