[IT-방법] 파드 보안 설정 가이드 – 권한 최소화와 취약점 차단 방법

파드 보안, 왜 방치하면 위험할까요?

어느 날 갑자기 클러스터의 노드 하나가 해커의 통제하에 들어갔다는 보고를 받는다면 어떤 기분이 드실까요? 단순히 컨테이너 하나가 뚫리는 문제에서 끝나지 않아요. 잘못 설정된 파드 하나는 공격자가 클러스터 전체 권한을 탈취할 수 있는 고속도로가 됩니다.

개발 편의를 위해 설정한 privileged: true 설정이나, 습관적으로 사용하는 루트(root) 권한이 바로 그 시작점이에요. 공격자는 취약한 파드로 침입한 뒤, 권한 상승을 통해 호스트 운영체제까지 장악하고 결국 클러스터 내부의 모든 자원을 유린하게 됩니다. 보안 담당자로서 이런 시나리오를 막기 위해서는 파드 수준에서부터 촘촘한 방어선을 구축해야 해요.

지금 이 글을 읽고 계신 분들은 아마도 클러스터의 보안 정책을 수립하거나, 기존 환경의 취약점을 점검해야 하는 과제를 안고 계실 거예요. 복잡한 보안 이론보다는 실무에서 즉시 적용할 수 있는 설정 방법과 검증 절차가 필요하실 겁니다.

이 가이드를 끝까지 읽고 나면 다음과 같은 핵심 내용을 완벽히 파악할 수 있어요.

• 파드 보안을 위협하는 주요 공격 경로와 지점
• 최소 권한 원칙(Least Privilege)을 실현하는 상세 설정법
• Pod Security Admission을 활용한 정책 강제화 방법
• 보안 설정 적용 후 반드시 수행해야 할 점검 및 감사 절차

보안 설정을 시작하기 전 필수 체크리스트

무턱대고 보안 설정을 강화하다 보면, 잘 작동하던 애플리케이션이 권한 부족으로 갑자기 멈춰버리는 상황이 발생해요. 운영 환경에 적용하기 전에 반드시 보안 수준을 결정하고, 현재 클러스터가 어떤 상태인지 파악하는 과정이 선행되어야 합니다.

가장 먼저 결정해야 할 것은 우리 조직에 적합한 Pod Security Standard(PSS) 단계예요. 쿠버네티스는 보안 수준을 세 가지로 표준화하여 제공하고 있습니다. 각 단계의 차이를 명확히 이해해야 애플리케이션의 가용성을 해치지 않으면서 보안을 강화할 수 있어요.

또한, 보안 설정을 적용하기 위해서는 다음과 같은 준비가 필요해요.

• YAML 매니페스트 작성 능력: 보안 컨텍스트(securityContext) 설정을 직접 수정할 수 있어야 해요.
• RBAC 이해도: 파드 보안과 서비스 어카운트(ServiceAccount) 권한 간의 관계를 알아야 합니다.
• 클러스터 관리 권한: 네임스페이스 수준에서 Admission Controller 정책을 적용할 수 있는 권한이 필요해요.

파드 보안 강화를 위한 5단계 실행 전략

이제 본격적으로 파드의 방어력을 높이는 구체적인 방법을 알아볼게요. 단순히 설정을 추가하는 것을 넘어, 공격자가 침투했을 때 이동할 수 있는 경로를 차단하는 데 초점을 맞춰야 합니다.

STEP 1. 사용자 및 그룹 권한 최소화하기

가장 흔하면서도 위험한 실수는 컨테이너를 루트(root) 사용자로 실행하는 것이에요. 컨테이너 내부에서 루트 권한을 얻으면, 설정 오류를 통해 호스트 시스템의 루트 권한까지 획득할 가능성이 매우 높아집니다. 이를 막기 위해 securityContext를 사용하여 비루트 사용자를 명시해야 해요.

먼저, 파드 전체 또는 개별 컨테이너 수준에서 runAsNonRoot: true 설정을 적용하세요. 이 설정은 컨테이너가 UID 0(root)으로 실행되는 것을 커널 수준에서 차단합니다. 그와 함께 runAsUser와 runAsGroup를 사용하여 특정 고정 ID를 할당하는 것이 안전해요. 예를 들어, 보안상 권장되는 UID 범위인 1000번대 이상의 값을 사용하는 것이 좋습니다.

이 단계에서 주의할 점은 애플리케이션 이미지 자체가 루트 사용자로 설계되어 있다면, 설정을 적용하는 순간 실행에 실패한다는 점이에요. 따라서 보안 설정을 적용하기 전, Dockerfile 단계에서부터 USER 명령어를 통해 일반 사용자 계정을 생성해 두어야 합니다.

STEP 2. 리눅스 기능(Capabilities) 관리하기

리눅스 커널은 프로세스가 수행할 수 있는 특정 권한을 Capabilities라는 단위로 관리합니다. 쿠버네티스 컨테이너는 기본적으로 몇 가지 권한을 가지고 시작하는데, 이 중 불필요한 것들이 공격에 이용될 수 있어요. 예를 들어 CAP_SYS_ADMIN은 사실상 루트 권한과 다름없어 매우 위험합니다.

보안을 강화하는 가장 확실한 방법은 모든 기능을 먼저 제거한 뒤, 필요한 것만 골라서 추가하는 것이에요. YAML 설정에서 capabilities: drop: ["ALL"]를 먼저 선언하세요. 그 후, 웹 서버가 80번 포트를 열어야 한다면 add: ["NET_BIND_SERVICE"]와 같이 딱 필요한 기능만 명시적으로 허용하는 방식을 권장합니다.

STEP 3. 파일 시스템 보호 및 읽기 전용 설정

공격자가 컨테이너에 침입하면 가장 먼저 하는 일은 악성 스크립트를 다운로드하거나 설정 파일을 수정하는 일이에요. 이를 차단하기 위해 컨테이너의 루트 파일 시스템을 읽기 전용으로 만들어야 합니다. readOnlyRootFilesystem: true 설정을 적용하면, 컨테이너 내부의 어떤 파일도 수정할 수 없게 됩니다.

물론 애플리케이션이 로그를 남기거나 임시 파일을 생성해야 하는 경우가 있죠? 이럴 때는 파일 시스템 전체를 잠그는 대신, emptyDir 볼륨을 활용하세요. 쓰기가 필요한 특정 디렉토리(예: /tmp, /var/log)에만 임시 볼륨을 마운트하면, 루트 파일 시스템의 보안을 유지하면서도 앱의 동작을 보장할 수 있습니다.

STEP 4. 프로세스 및 네트워크 격리 강화

컨테이너가 호스트의 자원을 직접 공유하는 것은 보안상 매우 치명적이에요. 특히 hostNetwork: true나 hostPID: true 설정은 컨테이너가 호스트의 네트워크 인터페이스나 프로세스 목록을 그대로 볼 수 있게 만들어, 격리 환경을 완전히 무너뜨립니다.

이러한 설정을 절대 사용하지 않는 것을 원칙으로 삼으세요. 만약 네트워크 통신이 복잡하다면, 파드 보안 설정보다는 Network Policy를 사용하여 파드 간의 통신 허용 범위를 정의하는 것이 훨씬 올바른 접근 방법입니다. 또한, 프로세스의 동작 범위를 제한하기 위해 seccomp 프로필을 적용하여 허용되지 않은 시스템 콜(syscall)을 원천 차단하는 것도 강력한 방어 수단이 됩니다.

STEP 5. Pod Security Admission(PSA)으로 정책 강제화

개별 개발자가 보안 설정을 빠뜨리지 않기를 기대하는 것은 불가능에 가까워요. 따라서 시스템 차원에서 보안 정책을 강제하는 Pod Security Admission(PSA)을 반드시 도입해야 합니다. PSA는 네임스페이스 단위로 보안 수준을 선언하고, 기준에 맞지 않는 파드는 아예 생성되지 못하도록 막아주는 수문장 역할을 합니다.

예를 들어, 중요한 고객 데이터를 처리하는 네임스페이스에는 다음과 같이 restricted 정책을 적용할 수 있습니다.

apiVersion: v1
kind: Namespace
metadata:
  name: secure-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

이렇게 설정해 두면, 실수로 루트 권한을 요청하는 파드를 배포하더라도 쿠버네티스 API 서버가 즉시 거부합니다. 운영 환경에 적용하기 전에는 반드시 warn 레이블을 먼저 사용하여 기존 서비스에 미칠 영향을 시뮬레이션해 보세요.

자주 하는 실수와 해결법

현장에서 보안 설정을 적용하다 보면 예상치 못한 에러 때문에 당황하는 경우가 많아요. 가장 빈번하게 발생하는 패턴 5가지를 정리했습니다.

❌ 실수 1: 모든 설정을 한꺼번에 적용하여 서비스 중단
왜 발생하는가: 기존 앱이 루트 권한이나 특정 시스템 호출에 의존하고 있다는 사실을 모르고 바로 Enforce 모드를 켰기 때문이에요.
✅ 해결법: 먼저 Audit 모드로 설정하여 위반 로그를 수집하고, 문제가 되는 앱을 수정하거나 예외 처리를 한 뒤 단계적으로 강화하세요.

❌ 실수 2: securityContext를 파드와 컨테이너에 중복 설정
왜 발생하는가: 설정이 덮어씌워지는 우선순위를 정확히 모르기 때문입니다.
✅ 해결법: 컨테이너 수준의 설정이 파드 수준의 설정보다 우선합니다. 중복된 설정이 충돌하지 않도록 상위 수준에는 공통 설정을, 컨테이너 수준에는 개별 설정을 배치하세요.

❌ 실수 3: readOnlyRootFilesystem 적용 후 로그 기록 실패
왜 발생하는가: 앱이 로그 파일을 루트 디렉토리에 쓰려고 시도하기 때문이에요.
✅ 해결법: 로그 전용 디렉토리에 emptyDir 볼륨을 마운트하거나, stdout/stderr로 로그를 출력하도록 앱 구조를 변경하세요.

❌ 실수 4: non-root 설정 시 UID 매핑 오류
왜 발생하는가: 이미지 내 파일들의 소유권이 루트로 되어 있어, 일반 사용자로 실행하면 파일 접근 권한이 없기 때문이에요.
✅ 해결법: Dockerfile에서 chown 명령어를 사용해 필요한 파일들의 소유권을 실행 사용자 UID로 변경해 주세요.

❌ 실수 5: Capabilities drop ALL 이후 필요한 권한 누락
왜 발생하는가: 앱이 기본적으로 사용하는 커널 기능(예: 네트워크 바인딩)을 고려하지 않았기 때문이에요.
✅ 해결법: 앱 실행 로그를 모니터링하며 Permission Denied 에러가 발생하는지 확인하고, 필요한 기능만 하나씩 추가하세요.

자주 묻는 질문

Q. Pod Security Admission(PSA)만 있으면 충분할까요?

PSA는 파드의 보안 수준을 강제하는 아주 좋은 도구이지만, 모든 것을 해결해주지는 않아요. 파드 내부의 코드가 취약하거나, 서비스 어카운트의 권한(RBAC)이 너무 과도하게 설정되어 있다면 공격자는 여전히 클러스터를 장악할 수 있습니다. PSA와 함께 RBAC 관리, 네트워크 정책, 이미지 스캐닝을 병행해야 합니다.

Q. 기존에 사용하던 Pod Security Policy(PSP)는 어떻게 되나요?
쿠버네티스 최신 버전에서는 PSP가 완전히 제거되었습니다. 이제는 PSA를 사용하는 것이 표준입니다. 만약 아직도 PSP를 사용 중이라면, 빠른 시일 내에 PSA로 전환하는 계획을 세워야 합니다.

Q. 보안 설정을 강화하면 성능이 떨어지나요?
보안 설정 자체는 커널 수준에서 체크되므로 성능 저하가 거의 없습니다. 다만, 보안을 위해 복잡한 네트워크 정책이나 사이드카 프록시를 추가하는 경우에는 리소스 사용량이 늘어날 수 있으니 모니터링이 필요해요.

Q. 어떤 보안 수준을 기본값으로 잡아야 할까요?
보안 담당자라면 모든 네임스페이스에 Baseline을 기본으로 적용하고, 서비스의 중요도에 따라 Restricted로 상향하는 전략을 추천합니다.

보안 운영을 위한 최종 체크포인트

파드 보안은 한 번 설정하고 끝나는 프로젝트가 아니에요. 지속적인 모니터링과 업데이트가 필요한 운영의 영역입니다. 오늘 배운 내용을 바탕으로 지금 바로 클러스터를 점검해 보세요.

당장 실행해야 할 액션 플랜:

• 오늘 할 일: 현재 운영 중인 네임스페이스 중 가장 중요한 곳의 파드들이 루트 권한으로 실행 중인지 확인하기
• 이번 주 할 일: 테스트 환경에서 PSA의 Warn 모드를 활성화하여 위반 사례 리스트 뽑아보기
• 실행 직전 할 일: 애플리케이션의 Dockerfile을 수정하여 전용 사용자 계정 생성하기

파드 보안 설정은 어렵게 느껴질 수 있지만, 하나씩 적용하다 보면 클러스터 전체의 안전도가 눈에 띄게 높아지는 것을 경험하실 수 있을 거예요. 실습 환경에서 직접 설정값을 바꿔보며 테스트해 보시고, 적용 과정에서 막히거나 궁금한 점이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하고 해결해 나가겠습니다.

함께 읽으면 좋은 글:
– 쿠버네티스 파드 기본 개념 이해하기
– 안정적인 쿠버네티스 클러스터 구축 입문 가이드