Pod Security Standards — 네임스페이스 라벨로 Pod 보안 수준을 강제한다
Kubernetes StatefulSet podManagementPolicy 및 Pod Security Standards 공식 문서 종합 (웹 리서치, 2026) — Kubernetes 공식 문서(concepts/workloads/controllers/statefulset, concepts/security/pod-security-admission) Kubernetes 공식문서 Pod Security Admission
이 모듈을 다 읽으면
- privileged/baseline/restricted 세 수준이 무엇을 통제하는지 설명할 수 있다
- enforce/audit/warn 세 모드가 위반 시 각각 어떻게 다르게 반응하는지 설명할 수 있다
k8s-learn-18(RBAC — 누가 API에 접근하는가)과 k8s-learn-20(Admission Webhook — 요청 내용을 검증·수정)을 전제로, Pod 스펙 자체의 위험한 설정(privileged 컨테이너 등)을 막는 내장 Admission 컨트롤러인 Pod Security Standards를 정리한다.
세 수준 — privileged/baseline/restricted
Pod Security Standards는 Pod의 SecurityContext 등 관련 필드에 요구사항을 두는 세 수준을 정의한다 — privileged(사실상 제약 없음, 특권 컨테이너까지 허용), baseline(알려진 권한 상승 경로를 막는 최소한의 제약), restricted(파드 하드닝 모범 사례를 강제하는 가장 엄격한 수준)다. k8s-learn-20의 Admission Webhook과 마찬가지로, Pod가 생성될 때 이 요구사항을 검사하는 내장 Admission 컨트롤러(Pod Security Admission)가 그 역할을 한다.
핵심 포인트
- privileged(사실상 무제한)/baseline(알려진 권한상승 경로 차단, 최소 제약)/restricted(파드 하드닝 모범사례 강제, 가장 엄격) 세 수준
- k8s-learn-20의 Admission Webhook과 유사하게, Pod 생성 시 내장 Admission 컨트롤러(Pod Security Admission)가 이 요구사항을 검사
네임스페이스 라벨로 설정 — enforce/audit/warn 세 모드
이 수준은 네임스페이스에 라벨을 붙이는 방식으로 설정한다 — 그리고 위반 시 반응 방식도 세 모드로 나뉜다. enforce는 정책 위반 Pod를 아예 거부한다(생성 자체가 막힘). audit은 위반이 있어도 Pod 생성은 허용하되, audit 로그에 기록만 남긴다. warn은 위반 시 사용자에게 경고 메시지를 보여주되(예: kubectl apply 실행 시 화면에 경고 출력) 역시 Pod 생성은 그대로 허용한다. 한 네임스페이스에 이 세 모드를 각각 다른 수준으로 동시에 설정할 수도 있다 — 예를 들어 enforce는 baseline으로 실제 차단하면서, warn은 restricted로 걸어 앞으로 강화할 규칙을 미리 경고해보는 점진적 전환 전략이 가능하다.
핵심 포인트
- enforce(위반 시 생성 자체 거부)/audit(허용하되 audit 로그에 기록)/warn(허용하되 사용자에게 경고 메시지) 세 모드
- 한 네임스페이스에 모드별로 다른 수준 동시 설정 가능(예: enforce=baseline + warn=restricted) — 점진적으로 규칙을 강화해가는 전환 전략에 활용