- Authors
- Name
- Youngju Kim
- @fjvbn20031
- 1. Pod Security Standards란?
- 2. 3가지 보안 프로파일
- 3. PSA 동작 모드
- 4. Restricted 프로파일 호환 Pod 작성
- 5. 마이그레이션 전략
- 6. Namespace별 예외 처리
- 7. AdmissionConfiguration으로 클러스터 기본값 설정
- 8. 실전 트러블슈팅
- 9. 퀴즈
1. Pod Security Standards란?
Kubernetes 1.25부터 PodSecurityPolicy(PSP)가 완전히 제거되고, Pod Security Admission(PSA)이 기본 보안 메커니즘이 되었습니다. PSA는 Pod Security Standards(PSS)라는 3단계 보안 프로파일을 기반으로 동작합니다.
PSP에서 PSA로의 전환 배경
PSP는 복잡한 RBAC 설정이 필요하고 디버깅이 어려웠습니다. PSA는 namespace 라벨만으로 간단하게 보안 정책을 적용할 수 있어 운영 부담이 크게 줄었습니다.
2. 3가지 보안 프로파일
Privileged (특권)
모든 것이 허용되는 프로파일입니다. 시스템 수준 워크로드(CNI, 스토리지 드라이버 등)에 사용합니다.
# kube-system namespace에 Privileged 적용
apiVersion: v1
kind: Namespace
metadata:
name: kube-system
labels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/audit: privileged
pod-security.kubernetes.io/warn: privileged
Baseline (기본)
알려진 권한 상승을 방지하면서 대부분의 워크로드가 동작할 수 있는 프로파일입니다.
제한 항목:
- hostNetwork, hostPID, hostIPC 사용 금지
- privileged 컨테이너 금지
- 위험한 capabilities 추가 금지 (NET_RAW 등)
- hostPath 볼륨 금지
apiVersion: v1
kind: Namespace
metadata:
name: app-staging
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/enforce-version: v1.30
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
Restricted (제한)
가장 엄격한 프로파일로, 보안 모범 사례를 강제합니다.
추가 제한 항목:
- runAsNonRoot 필수
- Seccomp 프로파일 설정 필수
- 모든 capabilities drop 필수
- allowPrivilegeEscalation: false 필수
apiVersion: v1
kind: Namespace
metadata:
name: app-production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: v1.30
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
3. PSA 동작 모드
PSA는 세 가지 모드로 동작합니다:
| 모드 | 동작 | 용도 |
|---|---|---|
| enforce | 위반 Pod 생성 거부 | 실제 정책 적용 |
| audit | 감사 로그 기록 | 모니터링 |
| warn | 사용자에게 경고 표시 | 마이그레이션 준비 |
# namespace에 라벨 적용
kubectl label namespace my-app \
pod-security.kubernetes.io/enforce=baseline \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/warn=restricted
4. Restricted 프로파일 호환 Pod 작성
Restricted를 만족하는 Pod spec 예제입니다:
apiVersion: v1
kind: Pod
metadata:
name: secure-app
namespace: app-production
spec:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: nginx:1.27-alpine
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
capabilities:
drop:
- ALL
resources:
limits:
memory: '128Mi'
cpu: '500m'
requests:
memory: '64Mi'
cpu: '250m'
volumeMounts:
- name: tmp
mountPath: /tmp
- name: cache
mountPath: /var/cache/nginx
- name: run
mountPath: /var/run
volumes:
- name: tmp
emptyDir: {}
- name: cache
emptyDir: {}
- name: run
emptyDir: {}
5. 마이그레이션 전략
기존 클러스터를 PSA로 마이그레이션하는 단계별 접근법입니다.
Step 1: 현재 상태 감사
# 모든 namespace에 대해 dry-run 검사
kubectl label --dry-run=server --overwrite ns --all \
pod-security.kubernetes.io/enforce=baseline
# 특정 namespace의 위반 사항 확인
kubectl get pods -n my-app -o json | \
kubectl apply --dry-run=server -f - 2>&1 | grep -i "warning"
Step 2: warn/audit 모드로 시작
# 먼저 warn과 audit만 적용
kubectl label namespace my-app \
pod-security.kubernetes.io/warn=baseline \
pod-security.kubernetes.io/audit=baseline
Step 3: 위반 워크로드 수정
# audit 로그에서 위반 사항 확인
kubectl logs -n kube-system -l component=kube-apiserver | \
grep "pod-security.kubernetes.io"
Step 4: enforce 모드 활성화
# 충분한 테스트 후 enforce 적용
kubectl label namespace my-app \
pod-security.kubernetes.io/enforce=baseline \
--overwrite
6. Namespace별 예외 처리
특정 워크로드가 상위 권한이 필요한 경우, namespace를 분리하는 것이 권장됩니다:
# 모니터링 에이전트용 별도 namespace
apiVersion: v1
kind: Namespace
metadata:
name: monitoring-agents
labels:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/warn: restricted
---
# 일반 앱용 namespace
apiVersion: v1
kind: Namespace
metadata:
name: production-apps
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
7. AdmissionConfiguration으로 클러스터 기본값 설정
API 서버 설정으로 클러스터 전체 기본 정책을 지정할 수 있습니다:
# /etc/kubernetes/psa-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
enforce: 'baseline'
enforce-version: 'latest'
audit: 'restricted'
audit-version: 'latest'
warn: 'restricted'
warn-version: 'latest'
exemptions:
usernames: []
runtimeClasses: []
namespaces:
- kube-system
- kube-public
- istio-system
8. 실전 트러블슈팅
흔한 오류와 해결법
# 오류: Pod 생성 거부
# Error: pods "my-pod" is forbidden: violates PodSecurity "restricted:v1.30"
# 1. 어떤 필드가 위반인지 확인
kubectl describe pod my-pod -n production-apps 2>&1
# 2. 임시로 warn 모드에서 상세 확인
kubectl label namespace production-apps \
pod-security.kubernetes.io/enforce=baseline \
pod-security.kubernetes.io/warn=restricted \
--overwrite
자주 발생하는 위반 체크리스트
#!/bin/bash
for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
echo "=== Namespace: $ns ==="
kubectl get pods -n "$ns" -o json | \
jq -r '.items[] | select(
.spec.containers[].securityContext == null or
.spec.securityContext == null
) | .metadata.name'
done
9. 퀴즈
Q1: PSA의 세 가지 동작 모드는 무엇이며, 각각의 역할은?
- enforce: 정책을 위반하는 Pod의 생성을 거부합니다.
- audit: 위반 사항을 감사 로그에 기록하지만 Pod 생성은 허용합니다.
- warn: kubectl 사용자에게 경고 메시지를 표시하지만 Pod 생성은 허용합니다.
마이그레이션 시에는 warn/audit를 먼저 적용하고, 충분한 검증 후 enforce를 활성화하는 것이 안전합니다.
Q2: Restricted 프로파일에서 반드시 설정해야 하는 securityContext 항목 4가지는?
- runAsNonRoot: true — root 사용자로 실행 금지
- allowPrivilegeEscalation: false — 권한 상승 금지
- capabilities.drop: ["ALL"] — 모든 Linux capabilities 제거
- seccompProfile.type: RuntimeDefault — Seccomp 프로파일 설정
이 4가지를 모두 설정하지 않으면 Restricted namespace에서 Pod 생성이 거부됩니다.
Q3: 기존 클러스터를 PSA로 마이그레이션할 때 권장되는 단계는?
- 현재 상태 감사: dry-run으로 위반 사항 파악
- warn/audit 적용: 실제 차단 없이 모니터링
- 위반 워크로드 수정: securityContext 추가, 권한 최소화
- enforce 활성화: 충분한 테스트 후 실제 정책 적용
- 클러스터 기본값 설정: AdmissionConfiguration으로 신규 namespace에 자동 적용
점진적 접근이 핵심이며, 절대 한 번에 enforce를 적용하지 않습니다.