🛡️ 쿠버네티스 보안의 새로운 표준: Pod Security Admission (PSA) 완벽 가이드

안녕하세요! 오늘은 쿠버네티스 보안 설정의 핵심인 Pod Security Admission (PSA)에 대해 깊이 있게 다뤄보려고 합니다.

v1.25부터 기존의 Pod Security Policy (PSP)가 완전히 제거되면서, 이제 PSA가 그 자리를 대신하게 되었습니다. "보안 설정은 어렵다"는 편견을 깨고, 쿠버네티스 네이티브 방식(Built-in)으로 아주 심플하게 적용할 수 있는 PSA의 모든 것을 상세히 정리해 드립니다. 🚀

---

1. PSA란 무엇인가요? 🤔

Pod Security Admission (PSA)은 파드(Pod)가 생성될 때, 해당 파드가 사전에 정의된 보안 표준(Pod Security Standards)을 준수하는지 검사하는 입장 관리자(Admission Controller)입니다.

과거 PSP는 설정이 복잡하고 권한 관리가 까다로웠지만, PSA는 별도의 CRD(Custom Resource Definition) 설치 없이 네임스페이스에 라벨(Label)을 붙이는 것만으로 즉시 동작합니다.

2. 핵심 개념 1: 보안 수준 (Levels) 📊

PSA는 Pod Security Standards (PSS)라고 불리는 3가지 보안 수준을 기준으로 파드를 검사합니다. 상황에 맞춰 적절한 레벨을 선택해야 합니다.

레벨 (Level)	설명	추천 대상
Privileged	제약이 전혀 없습니다. 호스트의 커널 기능에 접근 가능합니다.	시스템 관리용 에이전트 (CNI, 스토리지 드라이버 등)
Baseline	권한 상승(Privilege Escalation)을 방지하는 최소한의 제약입니다.	일반적인 마이크로서비스, 웹 애플리케이션
Restricted	가장 강력한 보안 수준입니다. Root 실행 금지, 볼륨 타입 제한 등을 포함합니다.	보안이 매우 중요한 금융/개인정보 처리 앱

3. 핵심 개념 2: 제어 모드 (Modes) 🎛️

정책을 위반했을 때 어떻게 처리할지 3가지 모드로 결정할 수 있습니다. 하나의 네임스페이스에 여러 모드를 동시에 적용할 수도 있습니다!

1. Enforce (강제): 정책 위반 시 파드 생성을 차단(Reject)합니다.
2. Audit (감사): 파드 생성은 허용하되, 위반 사실을 감사 로그(Audit Log)에 남깁니다.
3. Warn (경고): 파드 생성은 허용하되, 사용자에게 경고 메시지를 보여줍니다.

---

4. 실전! PSA 적용 가이드 🛠️

이제 실제로 네임스페이스에 정책을 적용해 보겠습니다. 가장 권장되는 방식은 "경고(Warn) 모드로 먼저 확인하고, 강제(Enforce) 모드로 전환"하는 것입니다.

Step 1. 테스트용 네임스페이스 생성

kubectl create ns psa-test

Step 2. 정책 적용 (레이블링)

psa-test 네임스페이스에 가장 강력한 보안인 restricted 레벨을 적용해보겠습니다. 처음에는 차단되지 않도록 warn 모드만 켜보겠습니다.

# 문법: pod-security.kubernetes.io/<MODE>=<LEVEL>

# 1. 경고 모드 설정 (Restricted 위반 시 경고)
kubectl label ns psa-test pod-security.kubernetes.io/warn=restricted

# 2. 강제 모드 설정 (Baseline 위반 시 차단) -> 이중 적용 가능
kubectl label ns psa-test pod-security.kubernetes.io/enforce=baseline

Step 3. 정책 위반 파드 생성 테스트

보안 설정이 전혀 없는 Nginx 파드를 생성하려 하면 어떻게 될까요?

Bash

kubectl run nginx --image=nginx -n psa-test

 

출력 결과 (Warn 모드 작동):

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), ...

pod/nginx created

 

enforce=baseline은 통과했기 때문에 파드는 생성(created)되었지만, warn=restricted에 의해 수많은 경고 메시지가 뜬 것을 볼 수 있습니다.

Step 4. 'Restricted' 준수하도록 파드 수정

Restricted 레벨을 통과하려면 securityContext를 꼼꼼하게 설정해야 합니다.

YAML

apiVersion: v1
kind: Pod
metadata:
  name: secure-nginx
  namespace: psa-test
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: nginx
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      runAsUser: 1001 # Root(0)가 아닌 사용자 지정

---

5. 고급 설정: 예외 처리 (Exemptions) 🔓

특정 네임스페이스에서 대부분의 파드는 막아야 하지만, 특정 관리자나 컨트롤러는 허용해줘야 할 때가 있습니다. 이는 네임스페이스 레이블이 아니라 Cluster-level 설정 파일(AdmissionConfiguration)을 통해 제어합니다.

주의: 이 설정은 API 서버의 설정 파일을 수정해야 하므로, 매니지드 쿠버네티스(EKS, GKE, AKS)에서는 직접 설정이 제한될 수 있습니다.

 

YAML

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1beta1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "baseline"
      enforce-version: "latest"
    exemptions:
      # 특정 사용자 이름 예외 처리
      usernames: ["admin", "system:serviceaccount:kube-system:replicaset-controller"]
      # 특정 런타임 클래스 예외 처리
      runtimeClasses: ["kata-containers"]
      # 특정 네임스페이스 예외 처리
      namespaces: ["kube-system"]

---

6. 마무리: 안전한 도입을 위한 로드맵 🗺️

PSA를 운영 환경에 도입할 때는 서비스 중단을 막기 위해 아래 순서를 따르는 것을 추천합니다.

1. 현황 파악: 현재 클러스터 버전을 확인하고(v1.23 이상 권장), 네임스페이스별 용도를 분류합니다.
2. Audit/Warn 모드 적용: enforce 없이 warn=baseline 또는 warn=restricted를 먼저 적용하여 로그를 수집합니다.
3. 애플리케이션 수정: 경고가 발생하는 파드의 securityContext를 수정합니다.
4. Enforce 전환: 경고가 사라지면 enforce 모드로 전환하여 보안을 강제합니다.

PSA는 이제 선택이 아닌 필수입니다. 복잡한 서드파티 도구 없이도 강력한 보안 거버넌스를 구축할 수 있는 PSA, 지금 바로 시작해보세요! 💪

---