쿠버네티스 보안을 “클러스터 설정”에서만 찾다 보면 정작 가장 자주 뚫리는 지점인 워크로드(파드) 를 놓치기 쉽습니다. 이 글에서는 파드 보안의 핵심 원칙과 Pod Security Admission(Restricted) 중심의 실천 체크리스트, 그리고 최근 팀에서 자주 나오는 “AI 개발 코파일럿 시대의 잠재 리스크”를 어떻게 함께 다뤄야 하는지 정리합니다.
왜 파드 보안이 출발점인가요?
쿠버네티스에서 파드는 애플리케이션이 실제로 실행되는 단위입니다. 파드가 침해되면 영향은 그 컨테이너 내부에서 끝나지 않고, 아래처럼 노드·네트워크·시크릿·클러스터 권한으로 확장될 수 있습니다.
- 컨테이너 탈출/권한 상승 → 노드 장악 가능성
- 서비스어카운트 토큰 탈취 → Kubernetes API 악용(RBAC 범위 내에서 횡이동)
- 네트워크로 내부 서비스 스캔 → 동서(East-West) 트래픽 기반 확산
- 시크릿/환경변수/볼륨 마운트 노출 → 데이터 유출
그래서 저는 쿠버네티스 보안을 “네트워크/클러스터”가 아니라 파드 보안 정책을 기본값으로 강제하는 것에서 시작하는 편이 가장 현실적이라고 봅니다.
파드 보안의 핵심 원칙: 최소권한 + 방어심층
파드 보안은 한 가지 설정으로 끝나지 않습니다. “최소권한(Least Privilege)”을 기본으로 하고, 침해를 가정한 “방어심층(Defense in Depth)”을 겹겹이 쌓는 접근이 필요합니다.
- 최소권한: 꼭 필요한 권한만 부여(권한 상승 불가, 루트 불가, capability 최소화 등)
- 방어심층: 파드 보안 + RBAC + 네트워크 정책 + 시크릿 관리 + 이미지 신뢰/스캔 + 모니터링
실천 체크리스트: Restricted 수준에서 요구되는 것들
아래 항목들이 “Restricted 수준”으로 가기 위한 핵심 습관입니다.
1) 루트 금지: runAsNonRoot
컨테이너를 루트로 실행하지 않게 강제합니다.
securityContext:
runAsNonRoot: true
runAsUser: 10001
runAsGroup: 10001
- 베이스 이미지/엔트리포인트가 루트 전제를 갖고 있으면 여기서부터 막히는 경우가 많습니다.
- 이게 “Restricted 적용을 어렵게 만드는” 대표 장애물 중 하나입니다(레거시 이미지, 루트 기반 설치 스크립트 등).
2) 권한상승 차단: allowPrivilegeEscalation: false
sudo, setuid 바이너리 등을 통해 컨테이너 내부에서 권한을 더 올리지 못하게 합니다.
securityContext:
allowPrivilegeEscalation: false
3) Filesystem을 읽기 전용으로: readOnlyRootFilesystem
쓰기 가능한 루트 파일시스템은 웹셸 드롭, 바이너리 치환 같은 공격에 취약합니다.
securityContext:
readOnlyRootFilesystem: true
- 로그/캐시/임시파일이 필요하면
emptyDir등을 특정 경로에만 마운트하는 방식으로 설계합니다.
4) Linux capability 최소화: capabilities.drop: ["ALL"]
기본 capability도 공격자에겐 좋은 도구가 됩니다. 원칙적으로 전부 제거하고, 필요한 것만 추가합니다.
securityContext:
capabilities:
drop: ["ALL"]
5) 위험한 옵션 피하기: privileged, hostNetwork, hostPID, hostIPC
privileged: true는 사실상 “컨테이너로 노드를 만지는” 수준이 됩니다.hostNetwork/hostPID/hostIPC는 격리 경계를 허무는 옵션이라 가급적 회피해야 합니다.
6) 자원 제한: requests/limits
보안은 “침해”뿐 아니라 “장애/남용”까지 포함합니다. 자원 제한이 없으면 특정 파드가 노드를 고갈시켜 서비스 거부 상태를 만들 수 있습니다.
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
Pod Security Admission(PSA)로 “기본값”을 강제하기
쿠버네티스는 Pod Security Admission을 통해 네임스페이스 단위로 Privileged / Baseline / Restricted 수준을 강제할 수 있습니다. 팀/조직 관점에서 중요한 포인트는 “권장”이 아니라 거부(enforce) 를 걸 수 있다는 점입니다.
예시(네임스페이스 라벨):
metadata:
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
- 처음부터
enforce로 들어가면 충돌이 크니, 보통warn/audit로 현황을 파악한 뒤 점진적으로enforce로 올리는 전략이 현실적입니다.
파드 보안만으로는 부족합니다: RBAC·NetworkPolicy·시크릿·이미지·모니터링
RBAC: 서비스어카운트 권한을 최소화하기
파드가 침해되었을 때 가장 흔한 다음 단계는 Kubernetes API 악용입니다. 서비스어카운트에 불필요한 권한이 있으면 피해가 커집니다.
- 서비스별로 분리된 ServiceAccount 사용
- cluster-admin 같은 과도 권한 금지
- 감사 로그로 “누가 어떤 리소스를 요청했는지” 추적
NetworkPolicy: 동서 트래픽을 기본 차단하고 필요한 것만 허용하기
네트워크 정책이 없으면 내부 서비스 스캔과 횡이동이 쉬워집니다.
Secrets 관리: “노출될 수 있다”를 전제로 설계하기
- 시크릿을 환경변수로 마구 뿌리기보다, 접근 경로/권한을 좁히고 로테이션 전략까지 포함합니다.
이미지 신뢰/스캔: 공급망 공격에 대비하기
- 베이스 이미지 최소화, 이미지 서명/검증, 취약점 스캔을 파이프라인에 고정합니다.
지속 모니터링: 침해 가정하에 탐지까지 포함하기
- 이상 네트워크, 권한 상승 시도, 비정상 프로세스 실행 등을 관측할 수 있어야 합니다.
(대화에서 나온 현실 이슈) AI 개발 코파일럿 시대의 “잠재 리스크”와 파드 보안의 연결
조직에서 외부 개발 코파일럿을 쓰는 경우, 당장 사고가 나지 않았더라도 잠재 리스크에 대비해야 합니다. 제가 특히 연결해서 보는 지점은 “AI가 만든 코드/설정이 곧바로 쿠버네티스 워크로드 보안 수준에 영향을 준다”는 점입니다.
- AI가 생성한 배포 YAML에
privileged: true,hostNetwork: true같은 설정이 섞일 수 있음 - 보안 컨텍스트가 누락된 “동작만 되는 예시”가 그대로 프로덕션으로 흘러갈 수 있음
- IaC/Helm/Kustomize에 잘못된 패턴이 들어가면 반복 확산(Blast radius 확대)
대화에서 이야기한 것처럼, 하네스 엔지니어링(자동화된 배포/게이팅/정책 적용 체계) 을 갖춘 조직일수록 AI 산출물이 빠르게 전파될 수 있어서 “더 면밀한 검수”가 필요해 보입니다. 다만 저는 여기서 “사람의 눈을 더 늘리기”보다, 아래처럼 정책/자동화로 검수를 강제하는 방향이 더 지속 가능하다고 생각합니다.
- PSA(Restricted)로 애초에 위험한 파드가 생성되지 않게 차단
- PR 단계에서 정책 검사(예: privileged 금지, runAsNonRoot 강제)
- 이미지 스캔/SAST/OSS 스캔을 머지 게이트로 고정
반대로 그런 체계가 약한 조직이라면, 말씀하신 것처럼 AI 사용 범위를 최소화하거나(예: 민감 리포지토리는 금지/격리), 적어도 “쿠버네티스 매니페스트/배포 관련 변경은 반드시 정책 검사를 통과” 같은 최소 통제부터 시작하는 게 안전합니다.
마무리
파드 보안은 “있으면 좋은 옵션”이 아니라, 파드 하나가 뚫렸을 때 클러스터 전체로 번지는 경로를 끊는 출발점입니다. Restricted를 완벽히 한 번에 적용하기 어렵더라도, warn/audit → enforce로 단계적으로 올리고 RBAC·NetworkPolicy·이미지/시크릿·모니터링까지 함께 쌓아가면 보안 수준이 눈에 띄게 안정됩니다.
