쿠버네티스 Pod Security 기준선: 제한보다 먼저 정해야 할 것

Pod가 호스트 네임스페이스를 공유하거나 특권 컨테이너로 실행되고, 임의의 호스트 경로를 마운트하며, 불필요한 Linux capability를 가진다면 하나의 컨테이너 침해가 노드와 다른 워크로드로 확장될 수 있다. 하지만 보안팀이 모든 네임스페이스에 restricted

를 즉시 적용하면 CNI, 스토리지 드라이버, 모니터링 에이전트와 오래된 애플리케이션이 한꺼번에 배포 실패를 일으킬 수 있다.

기준선의 목적은 “경고가 0개”가 아니라 워크로드 종류별로 허용 가능한 실행 경계를 정하고, 더 강한 권한이 필요한 경우 그 이유와 피해 범위를 설명할 수 있게 만드는 것이다.

세 수준과 세 모드를 혼동하지 않는다

Pod Security Standards는 대체로 세 수준으로 나뉜다.

수준	용도	운영 해석
privileged	제한을 거의 두지 않는 신뢰된 시스템 워크로드	일반 앱의 기본값으로 쓰지 않는다
baseline	알려진 특권 상승을 막는 최소 기준	기존 앱의 첫 enforce 후보
restricted	현재의 Pod 보안 모범 사례를 더 엄격히 적용	신규·일반 앱의 목표 기준

Pod Security Admission은 네임스페이스 라벨을 통해 다음 모드로 동작한다.

• enforce: 위반하는 새 Pod 생성을 거부한다.
• audit: 요청은 허용하지만 감사 주석으로 위반을 남긴다.
• warn: 요청자에게 경고를 보여 준다.

audit와 warn은 운영 영향을 관찰하는 수단이지 자동 수정 기능이 아니다. 컨트롤러가 기존 Pod를 계속 유지하는 동안 새 롤아웃만 실패할 수 있으므로, “현재 실행 중이니 안전하다”는 판단도 피해야 한다.

정책 버전을 명시한다

PSS의 세부 조건은 Kubernetes 릴리스와 함께 달라질 수 있다. 라벨의 *-version을 latest로만 두면 클러스터 업그레이드 뒤 예상하지 못한 위반이 생길 수 있다. 조직은 평가한 Kubernetes 마이너 버전으로 정책을 고정하고, 업그레이드 전에 다음 버전의 audit·warn 결과를 검토한다.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.36
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.36
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.36

위 버전은 예시일 뿐이다. 실제 클러스터가 지원하는 버전과 업그레이드 계획을 확인해 바꿔야 한다.

먼저 위반을 자산과 소유자로 묶는다

경고 목록만 쌓으면 개발팀은 무엇부터 고쳐야 할지 모른다. 위반 Pod마다 네임스페이스, 컨트롤러, 이미지, 서비스 소유자, 사용 중인 보안 설정, 실제 필요 이유를 붙인다.

위반 유형	먼저 확인할 질문	흔한 개선
privileged: true	호스트 장치나 커널 기능이 정말 필요한가	전용 노드·별도 데몬 또는 기능 제거
hostNetwork·hostPID	노드 수준 관측인가, 편의 설정인가	플랫폼 네임스페이스 격리
hostPath	어떤 경로를 읽고 쓰는가	CSI·PVC·읽기 전용·경로 축소
root 실행	이미지가 비루트 실행을 지원하는가	UID 지정, 파일 권한 수정
capability 추가	필요한 syscall·네트워크 기능은 무엇인가	기본 drop 후 필요한 항목만 추가
seccomp 미설정	런타임 기본 프로필을 쓸 수 있는가	RuntimeDefault 적용
privilege escalation 허용	setuid 등이 필요한가	allowPrivilegeEscalation: false

위반을 이미지 팀에만 넘기지 않는다. Helm 차트, 운영자(operator), 사이드카, admission mutation이 최종 Pod 사양을 바꿀 수 있으므로 렌더링된 매니페스트와 실제 생성 요청을 기준으로 조사한다.

네임스페이스를 세 부류로 나눈다

1. 일반 애플리케이션: baseline enforce를 빠르게 적용하고 restricted를 목표로 한다.
2. 신규 또는 민감 애플리케이션: 처음부터 restricted를 기본으로 한다.
3. 플랫폼·노드 연동 워크로드: 별도 네임스페이스와 노드 풀에 격리하고, 일반 개발자가 배포하지 못하게 한다.

kube-system 같은 시스템 네임스페이스를 무작정 라벨링하거나 예외 처리하지 않는다. 관리형 서비스와 배포 애드온이 요구하는 권한, 공급업체 지원 범위, 업그레이드 동작을 확인한다. 네임스페이스 전체를 예외로 두면 그곳에 들어온 모든 Pod가 넓은 권한을 얻을 수 있으므로 배포 주체와 이미지 출처를 더 강하게 제한해야 한다.

단계적 롤아웃

1. 전 클러스터의 audit·warn 기준선 수집

현재 워크로드와 신규 배포 모두에서 위반을 모은다. 서버 측 dry-run과 렌더링된 매니페스트 검사를 CI에 추가해 개발자가 배포 전에 볼 수 있게 한다.

2. 비운영 네임스페이스에 baseline enforce

오류율뿐 아니라 ReplicaFailure, FailedCreate, admission 거부, 롤아웃 정체를 모니터링한다. 기존 Pod가 살아 있어도 재시작 때 실패할 수 있으므로 노드 드레인과 오토스케일 상황을 시험한다.

3. 운영 카나리와 신규 네임스페이스 확대

신규 네임스페이스 생성 템플릿에 라벨을 기본 포함하고, 라벨이 없는 네임스페이스를 주기적으로 탐지한다. 운영에서는 영향이 작은 서비스부터 확대한다.

4. restricted 전환

baseline에서 허용되지만 restricted에서 막히는 항목을 서비스별로 제거한다. 이미지의 비루트 실행, seccomp, capability, 볼륨 권한을 테스트하고 성능·기능 회귀를 확인한다.

실패 모드와 롤백

가장 위험한 실패는 정책을 완전히 꺼서 배포를 복구하는 것이다. 우선 마지막 라벨 변경을 이전 수준으로 되돌리거나 특정 네임스페이스만 한시적으로 baseline으로 낮춘다. 예외에는 소유자, 위반 항목, 보완 통제, 만료일, 제거 작업을 남긴다.

다음 신호가 나타나면 확대를 멈춘다.

• admission 거부율 급증
• Deployment·DaemonSet의 새 Replica 생성 실패
• 노드 교체 뒤 핵심 에이전트 미기동
• 모니터링·로그·스토리지 기능 공백
• 예외 네임스페이스 또는 privileged Pod의 예상 밖 증가

정책 변경 전후의 네임스페이스 라벨과 위반 목록을 저장하면 원인을 빠르게 비교할 수 있다.

다른 통제가 필요한 영역

PSS는 이미지 취약점, 악성 코드, 네트워크 이동, 서비스 계정 RBAC, 시크릿 노출, 이미지 출처를 모두 해결하지 않는다. 빌드 출처와 아티팩트 검증은 SLSA 프로비넌스 강화를, 사용자·워크로드 신원은 제로 트러스트 신원 경계를 함께 본다.

운영 체크리스트

• 현재 Kubernetes·PSS 버전과 CNI·스토리지 애드온 요구를 확인했다.
• audit·warn 위반을 컨트롤러와 서비스 소유자에 연결했다.
• 일반 앱, 민감 앱, 플랫폼 워크로드의 목표 수준을 나눴다.
• 정책 버전을 명시하고 클러스터 업그레이드 전에 다음 버전을 평가한다.
• 서버 측 dry-run과 CI 렌더링 검사로 배포 전 위반을 보여 준다.
• 노드 드레인·재시작·오토스케일 상황에서 새 Pod 생성까지 시험했다.
• 예외에는 범위·사유·보완 통제·만료일이 있다.
• admission 거부, Replica 실패, privileged Pod 수를 운영 지표로 본다.

참고 기준

• Kubernetes Pod Security Standards
• Enforce Pod Security Standards with Namespace Labels
• Kubernetes Security Checklist

Pod Security 기준선이 잘 정착했다는 증거는 모든 팀이 같은 YAML을 쓰는 것이 아니다. 일반 워크로드는 좁은 실행 권한을 기본으로 받고, 특권이 필요한 시스템은 별도 경계와 소유자 아래 있으며, 업그레이드와 재배포 때도 그 상태를 반복할 수 있는 것이다.