도입: PSP 폐기와 새로운 보안 표준의 필요성
Kubernetes 보안의 역사에서 중요한 전환점이 찾아왔습니다. Kubernetes v1.25 릴리스(2022년 8월)를 기점으로 Pod Security Policy(PSP)가 완전히 폐기되었습니다. PSP는 오래전부터 클러스터 수준의 Pod 보안을 제어하는 주요 메커니즘이었지만, 복잡한 정책 규칙, 일관성 없는 동작, 유지보수의 어려움으로 인해 많은 운영자들이 어려움을 겪었습니다. PSP를 대신하여 등장한 Pod Security Standards(PSS)와 Pod Security Admission(PSA)은 더 명확한 보안 모델, 간단한 적용 방식, 업계 표준 기반의 설계 철학을 제공합니다. 이는 단순한 기술 전환이 아니라 Kubernetes 보안 거버넌스의 패러다임 변화를 의미합니다.
배경 지식: Pod Security Standards와 Pod Security Admission 이해하기
Pod Security Standards(PSS)는 NIST 및 CIS Kubernetes Benchmarks를 기반으로 설계된 표준 보안 프로필입니다. 세 가지 수준의 정책을 제공합니다. 'Restricted' 수준은 보안 모범 사례를 엄격하게 적용하며 대부분의 Linux 보안 기능을 제한합니다. 'Baseline' 수준은 알려진 권한 상승 공격을 방지하면서도 기존 워크로드의 호환성을 유지합니다. 'Unrestricted' 수준은 정책을 적용하지 않는 것과 동일하며 레거시 애플리케이션 지원 시에만 사용합니다.
Pod Security Admission(PSA)은 이러한 보안 표준을 실제로 Kubernetes 클러스터에 적용하는 admission controller입니다. PSA는 세 가지 모드로 작동합니다. 'enforce' 모드는 정책 위반 시 Pod를 거부합니다. 'audit' 모드는 위반을 로깅하지만 Pod 생성을 허용합니다. 'warn' 모드는 사용자에게 경고 메시지를 표시합니다. 네임스페이스 레이블을 통해 세밀한 제어가 가능하여 전체 클러스터에 일괄 적용하거나 특정 네임스페이스에만 정책을 적용할 수 있습니다.
전제 조건: 환경 요구사항
Kubernetes v1.23 이상의 클러스터가 필요합니다(PSA는 v1.25 이후 기본 활성화). kubectl 명령어 도구와 클러스터에 대한 관리자 접근 권한이 필수입니다. 기존 PSP를 사용 중이라면 마이그레이션 계획 수립이 필요합니다. 현재 실행 중인 Pod들의 보안 프로필을 사전에 확인하고 문서화하는 것이 권장됩니다. Kyverno 또는 OPA/Rego 같은 정책 엔진의 기초 지식이 있으면 도움이 됩니다.
환경 설정: PSA를 위한 클러스터 구성
먼저 현재 Kubernetes 버전을 확인하고 PSA 기능이 활성화되어 있는지 검증합니다.
#!/bin/bash
# Kubernetes 버전 확인
kubectl version --short
# PSA API 버전 확인 (v1.25+에서는 기본 활성화)
kubectl api-resources | grep podsecuritypolicies
# 현재 실행 중인 Pod들의 보안 컨텍스트 확인
kubectl get pods -A -o json | jq '.items[] | {name: .metadata.name, namespace: .metadata.namespace, securityContext: .spec.securityContext}'
다음으로 Kubernetes 컴포넌트의 설정을 확인합니다. API 서버 로그에서 PSA 관련 이벤트를 모니터링하도록 설정합니다.
# /etc/kubernetes/manifests/kube-apiserver.yaml
# API 서버에서 PSA admission controller 활성화 확인
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
namespace: kube-system
spec:
containers:
- name: kube-apiserver
image: registry.k8s.io/kube-apiserver:v1.27.0
command:
- kube-apiserver
- --enable-admission-plugins=PodSecurityPolicy,PodSecurity
# PSA는 v1.25+에서 기본 활성화되며,
# 기존 PSP와의 호환성을 위해 둘 다 활성화 가능
단계별 가이드: PSS/PSA 구현하기
1단계: 현재 Pod 보안 수준 감사
먼저 클러스터의 모든 Pod가 어떤 보안 정책을 따르고 있는지 파악합니다. audit 모드로 'restricted' 정책을 적용하여 정책 위반 사항을 로깅합니다.
# audit-namespace.yaml
# Pod Security Admission을 audit 모드로 설정한 네임스페이스 생성
apiVersion: v1
kind: Namespace
metadata:
name: audit-namespace
labels:
# audit 모드: Restricted 정책 위반을 로깅하지만 Pod 생성은 허용
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: latest
# warn 모드도 함께 활성화하여 사용자에게 경고
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: latest
이 네임스페이스에 기존 Pod들을 마이그레이션하고 로그를 분석합니다.
#!/bin/bash
# PSA 감사 로그 확인 (API 서버 로그)
kubectl logs -n kube-system deployment/kube-apiserver | grep "PodSecurity"
# 특정 네임스페이스의 Pod 생성 이벤트 확인
kubectl get events -n audit-namespace -w
# 정책 위반 Pod 찾기 (exec 권한, root 실행 등)
kubectl get pods -A -o json | jq '.items[] | select(.spec.securityContext.runAsUser == 0) | {name: .metadata.name, namespace: .metadata.namespace, runAsUser: .spec.securityContext.runAsUser}'
2단계: Baseline 정책 적용
모든 워크로드에 'Baseline' 정책을 적용합니다. 이는 알려진 권한 상승 공격을 방지하면서도 기존 애플리케이션의 호환성을 유지합니다.
# baseline-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: production-apps
labels:
# Baseline 정책을 enforce 모드로 적용
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: latest
# audit과 warn도 함께 사용하여 더 엄격한 위반 사항 추적
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: latest
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/warn-version: latest
Baseline 정책이 적용된 네임스페이스에 Pod를 배포하고 동작을 확인합니다. 정책 위반으로 거부된 Pod는 스펙을 수정해야 합니다.
3단계: Restricted 정책으로 마이그레이션
충분한 검증 후 'Restricted' 정책을 적용합니다. 이 수준에서는 다음과 같은 제약이 적용됩니다.
- 모든 Linux 기능(capabilities)은 제거되어야 합니다.
- Root 사용자로 실행할 수 없습니다.
- 읽기 전용 루트 파일시스템이 필수입니다.
- 권한 상승(privileged escalation)이 허용되지 않습니다.
- SELinux 제한이 적용됩니다.
# restricted-deployment.yaml
# Restricted 정책을 준수하는 Deployment 예제
apiVersion: apps/v1
kind: Deployment
metadata:
name: secure-app
namespace: production-apps
spec:
replicas: 3
selector:
matchLabels:
app: secure-app
template:
metadata:
labels:
app: secure-app
spec:
# Pod 수준 보안 컨텍스트
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 2000
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: myapp:1.0
# 컨테이너 수준 보안 컨텍스트
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
volumeMounts:
- name: tmp
mountPath: /tmp
- name: var-cache
mountPath: /var/cache
volumes:
- name: tmp
emptyDir: {}
- name: var-cache
emptyDir: {}
이 배포 파일의 특징은 root가 아닌 사용자(UID 1000)로 실행되며, 루트 파일시스템은 읽기 전용이고, 임시 데이터를 위한 writable 볼륨을 별도로 마운트합니다.
4단계: 시스템 네임스페이스 예외 처리
kube-system, kube-public 등 시스템 네임스페이스는 일부 보안 정책을 만족할 수 없는 컴포넌트가 있으므로 예외 처리가 필요합니다.
# kube-system-exemption.yaml
apiVersion: v1
kind: Namespace
metadata:
name: kube-system
labels:
# 시스템 네임스페이스는 unrestricted 수준 사용
pod-security.kubernetes.io/enforce: unrestricted
또한 특정 Pod를 개별적으로 예외 처리할 수 있습니다. 클러스터 관리자 권한으로 Pod를 생성하거나, 정책을 우회하는 특별한 주석을 사용할 수도 있습니다.
5단계: 정책 모니터링 및 로깅
PSA 이벤트를 중앙화된 로깅 시스템으로 전송하여 정책 위반을 추적합니다.
#!/bin/bash
# API 서버 감사 로그에서 PSA 관련 이벤트 추출
kubectl logs -n kube-system -l component=kube-apiserver \
| grep -i "podsecurity\|pod-security" \
| tail -100
# 정책 위반 Pod 조회
kubectl get events -A --sort-by='.lastTimestamp' \
| grep -i "denied\|forbidden\|pod-security"
# 특정 네임스페이스의 정책 설정 확인
kubectl get namespace production-apps -o jsonpath='{.metadata.labels}' | jq .
예상 결과
audit 모드 설정 후 Pod를 생성하면 다음과 같은 경고 메시지가 나타납니다: "Warning: existing pods in namespace [namespace] violate the new PodSecurity enforce level [level]"
Restricted 정책이 enforce 모드로 적용된 네임스페이스에 root 사용자로 실행되는 Pod를 배포하려고 하면 다음 오류가 발생합니다: "Error from server (Forbidden): error when creating pod: admission webhook denied the request: violates PodSecurity restricted: runAsNonRoot != true"
정책을 올바르게 준수하는 Pod는 정상적으로 생성되며, 모든 컨테이너가 지정된 보안 컨텍스트로 실행됩니다. kubectl describe pod 명령으로 적용된 보안 설정을 확인할 수 있습니다.
문제 해결: 일반적인 오류와 해결 방법
오류 1: Pod 생성 거부 - "allowPrivilegeEscalation must be false"
이 오류는 컨테이너 스펙에서 allowPrivilegeEscalation을 명시적으로 false로 설정하지 않았을 때 발생합니다. 해결 방법은 Pod 매니페스트의 securityContext에 allowPrivilegeEscalation: false를 추가합니다. 또한 실행 시점에 Linux 기능(capabilities)도 함께 제거해야 합니다.
오류 2: "runAsNonRoot violation" - Root 사용자로의 실행 거부
애플리케이션이 root로 실행되도록 설계된 경우가 있습니다. 이 경우 Dockerfile을 수정하여 별도의 비-root 사용자를 생성합니다. 예를 들어 'RUN useradd -u 1000 appuser'를 추가하고 'USER appuser'로 전환합니다. PSA 정책은 반드시 준수해야 하므로, root 실행이 필수라면 별도의 네임스페이스를 생성하여 baseline 또는 unrestricted 정책을 적용하는 방법이 있습니다.
오류 3: "readOnlyRootFilesystem" - 읽기 전용 루트 파일시스템 호환성
애플리케이션이 루트 파일시스템에 쓰기 권한이 필요한 경우 emptyDir 볼륨을 사용하여 writable 디렉터리를 별도로 제공합니다. 예를 들어 /tmp, /var/cache, /var/log 등은 emptyDir로 마운트하여 컨테이너가 동적 파일을 생성할 수 있도록 합니다.
오류 4: 시스템 Pod의 정책 위반
etcd, scheduler, controller-manager 등 시스템 컴포넌트는 restricted 정책을 만족할 수 없습니다. 해결 방법은 kube-system 네임스페이스에 대해 unrestricted 정책을 적용하거나, Pod 스펙에 seccomp 프로필을 명시적으로 설정합니다. 또한 Pod에 특별한 주석을 추가하여 개별 정책 예외 처리도 가능합니다.
오류 5: 정책 버전 불일치
PSA 정책은 Kubernetes 버전에 따라 변경될 수 있습니다. "pod-security.kubernetes.io/audit-version: latest"는 항상 최신 정책을 사용하므로, 예상치 못한 정책 변경이 발생할 수 있습니다. 안정성을 위해 명시적 버전(예: v1.25, v1.26)을 지정하고, 클러스터 업그레이드 시에 정책 버전도 함께 검토합니다.
고급 활용: 정책 확장 및 커스터마이징
PSS는 표준 정책이지만, 조직의 특수한 요구사항에 맞게 확장할 수 있습니다. Kyverno는 Kubernetes 네이티브 정책 엔진으로서 PSS를 보완합니다. Kyverno ClusterPolicy를 사용하면 PSS보다 세밀한 제어가 가능합니다. 예를 들어 특정 이미지 레지스트리만 허용, 특정 라벨 필수화, NetworkPolicy 자동 생성 등을 구현할 수 있습니다.
#!/bin/bash
# Kyverno 설치
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
OPA/Gatekeeper도 PSS 정책을 Rego 언어로 작성하여 더 복잡한 정책 로직을 구현할 수 있습니다. 예를 들어 특정 조직의 이미지 스캔 결과에 따른 승인, 환경 변수 암호화 여부 검증 등이 가능합니다. 또한 PSS와 함께 여러 admission controller를 조합하면 심층 방어(defense in depth) 전략을 구현할 수 있습니다. API 서버의 admission plugin 순서를 최적화하여 성능 영향을 최소화합니다.
정책 성능 튜닝을 위해서는 audit 로그를 분석하여 실제로 위반하는 Pod의 비율을 파악합니다. 만약 위반 비율이 높다면 정책 수준을 낮추거나 특정 워크로드에 대한 예외를 추가합니다. 또한 정책 변경 시에는 항상 audit 또는 warn 모드에서 충분히 테스트한 후 enforce 모드로 전환합니다.
보안 고려사항
PSS/PSA는 Pod 생성 시점의 정책 검증만 수행합니다. 실행 중인 Pod의 동작을 감시하려면 런타임 보안 도구(Falco, osquery 등)가 필요합니다. 또한 PSA는 admission 수준의 제어이므로 이미지 스캔, 네트워크 정책, RBAC과 함께 다층적 보안을 구성해야 합니다.
정책 우회를 방지하기 위해 kubelet 설정에서 --pod-manifest-path를 비활성화하고, 정적 Pod 사용을 최소화합니다. 또한 pod-security admission controller는 반드시 API 서버 --enable-admission-plugins에 포함되어야 하며, 추가 admission controller 비활성화를 방지하기 위해 권한 제어를 엄격하게 합니다. 감시 네임스페이스나 시스템 컴포넌트에 대해서는 최소한의 정책만 적용하되, 정기적으로 감사 로그를 검토하여 예상치 못한 동작을 탐지합니다.
PSS/PSA와 FRIIM CNAPP의 통합
FRIIM CNAPP(Cloud Native Application Protection Platform)은 Kubernetes 환경의 보안을 종합적으로 관리합니다. PSS/PSA의 정책 적용 상태를 자동으로 검증하고, 정책 위반 Pod를 실시간으로 탐지합니다. FRIIM CNAPP은 admission controller 로그를 수집하여 정책 위반 트렌드를 분석하고, 조직의 보안 요구사항에 맞게 정책을 자동으로 조정하는 기능을 제공합니다. 또한 Pod의 런타임 동작을 모니터링하여 PSS/PSA만으로는 탐지할 수 없는 이상 행동을 감지하고, Seekurity SOAR와 연동하여 자동 대응 플레이북을 실행합니다.
결론
Pod Security Standards와 Pod Security Admission은 Kubernetes 보안의 현대적 표준입니다. PSP 폐기 후 강제되는 이 기술은 더 이상 선택이 아닌 필수입니다. 단계별 마이그레이션 전략을 수립하고, audit 모드에서 충분히 테스트한 후 enforce 모드로 전환하는 것이 안전합니다. Kyverno, OPA/Gatekeeper 같은 고급 정책 엔진과 조합하면 더욱 강력한 보안 체계를 구축할 수 있습니다. 다음 단계로는 네트워크 정책, RBAC, 이미지 스캔을 함께 구성하여 심층 방어 전략을 완성하기 바랍니다. FRIIM CNAPP을 도입하면 PSS/PSA의 적용과 모니터링을 자동화하고, 클라우드 네이티브 환경의 보안 운영을 대폭 단순화할 수 있습니다.