🛡️ 쿠버네티스 PSA 보안 레벨, 도대체 무엇을 막는 걸까? (심층 분석)

안녕하세요! 지난 포스팅에서는 Pod Security Admission (PSA)의 개념과 적용 방법에 대해 알아봤습니다. 오늘은 그 후속편으로, PSA의 핵심인 3가지 보안 표준(Pod Security Standards)이 구체적으로 "어떤 설정"을 막고 허용하는지 아주 뼛속까지 파헤쳐 보겠습니다.

PSA를 적용했는데 파드가 자꾸 Error 상태에 빠지나요? 혹은 Restricted 레벨을 적용하고 싶은데 무엇을 고쳐야 할지 막막한가요? 이 글 하나로 완벽하게 정리해 드립니다. 🚀

---

1. 레벨 0: Privileged (특권) 🔓

"모든 것이 허용된 무법지대"

이 정책은 의도적으로 완전하게 개방되어 있습니다.

• 제한 사항: 없음
• 허용: 호스트 커널 접근, 루트 권한, 호스트 네트워크 사용 등 모든 것이 가능합니다.
• 사용 대상: CNI 플러그인, 스토리지 드라이버, 노드 관리 에이전트 등 시스템 수준의 파드.

⚠️ 주의
일반적인 웹 애플리케이션이나 마이크로서비스에는 절대 이 레벨을 적용하면 안 됩니다. 해킹당하면 노드 전체가 위험해집니다!

---

2. 레벨 1: Baseline (기준) 🚧

"최소한의 안전장치, 일반적인 앱을 위한 표준"

기본적인 보안 정책입니다. 권한 상승(Privilege Escalation)을 통해 호스트 노드에 피해를 줄 수 있는 행위들을 막습니다. 대부분의 일반적인 컨테이너 이미지는 수정 없이 이 레벨에서 잘 동작합니다.

🚫 주요 제한 사항 (차단되는 것들)

1. 특권 컨테이너 금지 (privileged: true)
   • 컨테이너가 호스트의 장치에 직접 접근하는 것을 막습니다.
2. 호스트 네임스페이스 공유 금지
   • hostNetwork: true: 호스트의 네트워크 망을 같이 쓰지 못합니다.
   • hostPID: true: 호스트의 프로세스 ID를 볼 수 없습니다.
   • hostIPC: true: 호스트의 프로세스 간 통신에 접근할 수 없습니다.
3. 호스트 포트 제한
   • 호스트의 특정 포트(0-65535)를 점유하는 것을 제한합니다.
4. 특정 리눅스 기능(Capabilities) 추가 제한
   • 시스템에 치명적인 기능(예: CAP_SYS_ADMIN, CAP_MKNOD 등)을 추가(add)하는 것을 막습니다.
5. 위험한 Sysctls 금지
   • 커널 파라미터를 수정하는 sysctls 설정 중 안전하지 않은 것은 사용할 수 없습니다.
6. 호스트 경로(HostPath) 볼륨
   • 참고: Baseline은 HostPath 자체를 완전히 금지하지는 않지만, 엄격하게 제한하는 것이 권장됩니다 (실질적 차단은 Restricted에서 수행).

---

3. 레벨 2: Restricted (제한) 🏰

"최고 수준의 보안, 베스트 프랙티스"

Baseline의 모든 제한 사항을 포함하며, 파드를 더 격리하고 공격 표면을 최소화하기 위한 강력한 규칙들이 추가됩니다. 이 레벨을 통과하려면 파드 스펙(YAML)을 수정해야 할 수도 있습니다.

🚫 추가 제한 사항 (Baseline + α)

이 레벨은 아래 조건들을 반드시 명시적으로 설정해야 통과됩니다.

1. 루트(Root) 실행 금지 👮

• 컨테이너는 반드시 Root(UID 0)가 아닌 사용자로 실행되어야 합니다.
• YAML 필수 설정:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000 # 0이 아닌 숫자

 

2. 권한 상승 금지 (Privilege Escalation) 📉

• 프로세스가 부모 프로세스보다 더 높은 권한을 얻는 것을 막습니다. setuid 바이너리 실행 등이 차단됩니다.
• YAML 필수 설정:

containers:
  securityContext:
    allowPrivilegeEscalation: false

 

 

3. 리눅스 기능(Capabilities) 초기화 🗑️

• 컨테이너 런타임이 기본으로 제공하는 기능조차도 다 버려야(DROP) 합니다. 필요한 경우 NET_BIND_SERVICE 정도만 명시적으로 허용됩니다.
• YAML 필수 설정:

containers:
  securityContext:
    capabilities:
      drop: ["ALL"]

 

 

4. 볼륨 타입 제한 💾

• 호스트의 파일 시스템에 접근할 수 있는 HostPath 볼륨은 절대 사용할 수 없습니다.
• 허용되는 볼륨: ConfigMap, Secret, EmptyDir, PersistentVolumeClaim, DownwardAPI, Projected 등 쿠버네티스 추상화 볼륨만 가능합니다.

5. Seccomp 프로파일 적용 🛡️

• 시스템 콜(System Call) 필터링 기능인 Seccomp가 설정되어야 합니다.
• YAML 필수 설정:

securityContext:
  seccompProfile:
    type: RuntimeDefault # 또는 Localhost

 

---

🧐 한눈에 비교하는 요약표

제한 항목	Privileged (특권)	Baseline (기준)	Restricted (제한)
Privileged 컨테이너	허용 ✅	차단 🚫	차단 🚫
Host Network/PID/IPC	허용 ✅	차단 🚫	차단 🚫
Linux Capabilities	제한 없음	위험한 기능 추가 금지	모두 버림(DROP ALL) 필수
Root 유저 실행	허용 ✅	허용 ✅	금지 (Non-Root 필수)
권한 상승 (Escalation)	허용 ✅	허용 ✅	금지 (False 필수)
Volume Types	모두 허용 (HostPath 포함)	모두 허용	Core 볼륨만 허용 (HostPath 금지)

---

💡 Restricted 레벨 통과를 위한 모범 답안 YAML

Restricted 네임스페이스에 배포하려면 아래 템플릿을 참고하세요. 이것이 바로 보안 모범 사례(Best Practice)입니다.

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  # [필수] Pod 레벨 보안 컨텍스트
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: my-app:1.0
    # [필수] 컨테이너 레벨 보안 컨텍스트
    securityContext:
      allowPrivilegeEscalation: false
      runAsUser: 1001  # Root(0) 금지
      capabilities:
        drop:
          - ALL # 모든 권한 삭제

마치며 📝

처음에는 Baseline으로 시작해서 운영 감각을 익히고, 점차 Restricted로 강화해 나가는 것이 좋습니다. 특히 인터넷에 직접 노출되는 웹 애플리케이션이라면 Restricted 적용을 강력하게 권장합니다.

보안은 불편한 것이 아니라, 우리의 서비스를 더 단단하게 만드는 과정이니까요! 다음 포스팅에서는 PSA 트러블슈팅 사례를 들고 오겠습니다. 👋

---