PodSecurityPolicy 대체: Pod Security Admission

(dev.to)

Dev.to DevOps2026년 8월 31일개발자 도구

PodSecurityPolicy 대체: Pod Security Admission

Kubernetes의 PodSecurityPolicy가 제거됨에 따라 도입된 Pod Security Admission(PSA)은 단순화된 프로필과 모드를 통해 클러스터 보안을 효율적으로 관리할 수 있는 실무적인 대안을 제시합니다.

이 글의 핵심 포인트

1PodSecurityPolicy는 Kubernetes v1.21에서 Deprecated 되었고 v1.25에서 완전히 제거됨
2PSA는 privileged, baseline, restricted라는 세 가지 고정된 프로필을 제공함
3enforce, audit, warn 세 가지 모드를 통해 보안 정책 적용 방식을 제어할 수 있음
4클러스터 업그레이드 시 정책이 갑자기 강화되는 것을 방지하기 위해 버전 피닝(Version Pinning)이 필수적임
5restricted 프로필 적용 시 seccomp 설정 누락이나 권한 상승 허용 여부 등 구체적인 체크리스트 준수가 필요함

이 글에 대한 공공지능 분석

왜 중요한가?

Kubernetes 클러스터 보안의 핵심인 PSP가 제거됨에 따라, 운영 중인 서비스의 보안 정책을 중단 없이 전환하는 것이 인프라 안정성 유지의 핵심 과제로 떠올랐기 때문입니다.

어떤 배경과 맥락이 있나?

기존 PSP는 RBAC와 복잡하게 얽혀 관리가 어려웠으나, PSA는 별도의 설치 없이 API 서버에 내장된 단순한 구조를 채택하여 운영 부담을 줄이고 예측 가능성을 높이는 방향으로 진화했습니다.

업계에 어떤 영향을 주나?

보안 정책의 단순화는 DevOps 팀의 운영 복잡도를 낮추지만, 'restricted' 프로필 적용 시 seccomp 설정 누락 등 세밀한 설정 미비로 인한 워크로드 실행 실패 리스크를 동반합니다.

한국 시장에 어떤 시사점이 있나?

클라우드 네이티브 전환을 추진하는 국내 스타트업들은 인프라 업데이트 시 보안 정책이 예기치 않게 강화되어 서비스가 중단되지 않도록 버전 피닝(Version Pinning) 전략을 반드시 도입해야 합니다.

이 글에 대한 큐레이터 의견

PSA로의 전환은 단순한 기술적 교체가 아니라 '보안의 복잡성을 관리 가능한 수준으로 낮추는 전략적 선택'으로 보아야 합니다. PSP의 강력하지만 복잡한 기능을 포기하는 대신, PSA의 단순함을 활용해 보안의 '최저 기준(Floor)'을 확립하는 것이 실무적으로 훨씬 유효합니다. 특히 'warn'과 'audit' 모드를 활용한 단계적 도입 방식은 서비스 가용성을 최우적 가치로 두는 스타트업에게 매우 권장되는 접근법입니다.

다만, PSA의 단순함이 자칫 보안의 허점이 될 수 있다는 점은 경계해야 합니다. PSA는 보안의 '최저 기준'을 설정할 뿐, 고도로 정교한 보안 요구사항을 모두 충족하지는 못합니다. 따라서 보안 규제가 엄격한 금융이나 의료 분야의 스타트업이라면 PSA에만 의존하기보다, 추가적인 보안 레이어를 검토해야 하는 트레이드오프가 존재합니다. 인프라 운영자는 'latest' 태그 대신 버전 피닝을 통해 클러스터 업그레이드가 서비스 장애로 이어지지 않도록 제어권을 유지해야 합니다.

원문 보기 →