90DaysOfDevOps (Day 84)

고태규·2026년 2월 1일

DevOps

목록 보기
79/87
post-thumbnail

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 84 - Hacking Kubernetes For Beginners


1. 쿠버네티스 해킹


해킹이란 마법이 아니라, 설계자가 의도하지 않았던 무언가를 활용하는 창의적 접근이다.

해당 프레젠테이션은 쿠버네티스 클러스터를 공격하는 5가지 주요 시나리오를 통해 공격자의 관점과 방어자의 대응 전략을 살펴본다.

  • 시나리오1: Kubelet 해킹

  • 시나리오2: 서비스 및 웹 애플리케이션 해킹

  • 시나리오3: 컨테이너 탈출

  • 시나리오4: 이미지 레지스트리 오염

  • 시나리오5: 악의적인 관리자와 특권 파드


2. 시나리오1: Kubelet 해킹


2-1. 정상적인 흐름

관리자가 kubectl을 사용하여 파드에 접속하려 할 때, 요청은
API Server -> etcd(검증) -> Kubelet(노드) 순으로 전달된다.

Kubelet은 각 워커 노드의 문지기 역할을 하며 파드와 컨테이너를 관리한다.

2-2. Red Team: 공격 방법

공격자는 API 서버를 거치지 않고, 워커 노드의 Kubelet 포트(기본 10250)로 직접 통신을 시도한다.

  • 공격 기법: curl -k https://<node-ip>:10250/pods 등과 같이 비인증 요청을 보낸다.

  • 결과: Kubelet이 적절히 보호되지 않은 경우, 공격자는 인증 없이 파드 목록을 조회하거나 exec API를 통해 컨테이너 내부로 진입하여 명령어를 실행할 수 있다.


2-3. Blue Team: 방어 및 조치 전략

강연에서는 보안 담당자가 파라미터를 설정했다고 언급했다.

이를 구체적으로 구현하기 위해서는 Kubelet 설정 파일(/var/lib/kubelet/config.yaml)을 다음과 같이 수정해야 한다.

  1. 익명 인증 비활성화: 누구나 접근하지 못하도록 설정

    • authentication.anonymous.enabled: false
  2. Kubelet 권한 부여 모드 설정: 모든 요청이 API 서버를 통해 권한 검사를 받도록 설정

    • authorization.mode: Webhook
  3. 인증서 기반 접근 제어: 클라이언트 인증서(x509)가 있는 요청만 수락하도록 설정한다.

  4. 네트워크 정책 (NetworkPolicy): 워커 노드의 10250 포트에 대한 접근을 API 서버 등 신뢰할 수 있는 소스로만 제한하는 방화벽 규칙을 적용한다.


3. 시나리오2: 서비스 및 웹 애플리케이션 해킹


3-1. 정상적인 흐름

사용자가 웹사이트에 접속하면
Ingress -> Service -> Pod(Frontend) 순으로 트래픽이 전달된다.

프론트엔드에서 User ID를 입력하면 백엔드 DB와 통신하여 인증을 수행한다.

3-2. Red Team: 공격 방법

공격자는 웹 애플리케이션의 입력 필드(User ID 창)에 정상적인 ID 대신 악의적인 명령어를 주입한다.

  • 공격 기법: SQL Injection 또는 Command Injection

    • ; cat /etc/passwd 또는 MySQL 제어 명령
  • 결과: 애플리케이션의 취약점을 통해 백엔드 데이터베이스를 탈취하거나, Reverse Shell을 실행하여 컨테이너 내부 쉘 권한을 획득한다.

3-3. Blue Team: 방어 및 조치 전략

강연에서는 코드를 수정하고 출력 제어를 추가했다고 했다.

이는 애플리케이션 레벨과 인프라 레벨의 보안이 모두 필요하다.

  1. 입력 값 검증: 애플리케이션 코드 단계에서 사용자 입력값에 대한 엄격한 타입 체크와 특수문자 필터링을 수행한다. (Secure Coding)

  2. WAF (Web Application Firewall): Ingress 단계에서 ModSecurity나 AWS WAF 등을 연동하여 SQL Injection 등의 잘 알려진 공격 패턴을 차단한다.

  3. 최소 권한 원칙: 만약 뚫리더라도 피해를 최소화하기 위해 컨테이너를 Non-Root 사용자로 실행하고, 파일 시스템을 Read-Only로 설정한다.


4. 시나리오3: 컨테이너 탈출


4-1. 정상적인 흐름

공격자가 시나리오 2를 통해 컨테이너 내부 쉘을 획득했다고 가정한다.

4-2. Red Team: 공격 방법

공격자는 먼저 정찰을 수행한다. id 명령어로 루트 권한인지 확인하고, ls / 등을 통해 도커 환경임을 파악한다.

  • 공격 기법: 컨테이너가 과도한 권한을 가지고 있거나 커널 취약점이 있는 경우, 특수 제작된 스크립트를 실행하여 컨테이너 격리를 뚫고 호스트 또는 워커 노드의 쉘을 획득한다.

  • 결과: 워커 노드의 루트 권한을 장악하여 해당 노드의 모든 컨테이너를 제어한다.

4-3. Blue Team: 방어 및 조치 전략

강연에서는 컨테이너 보안 파라미터를 설정했다고 했다. 이는 SecurityContext와 런타임 보안을 의미한다.

  1. SecurityContext 강화: 파드 배포 시 다음 설정을 강제한다.

    • allowPrivilegeEscalation: false (권한 상승 방지)

    • privileged: false (특권 모드 금지)

    • runAsNonRoot: true (루트 사용자 실행 금지)

  2. Linux Capabilities 제한: 컨테이너에 불필요한 리눅스 커널 권한을 제거한다. (drop: ["ALL"])

  3. Seccomp 및 AppArmor 프로파일 적용: 컨테이너가 호스트 커널에 요청할 수 있는 System Call을 제한하여 탈출 가능성을 차단한다.

  4. Sandbox 컨테이너: gVisor나 Kata Containers와 같은 샌드박스 기술을 사용하여 커널 레벨의 격리를 강화한다.


5. 시나리오4: 이미지 레지스트리 오염


5-1. 정상적인 흐름

Kubelet은 파드를 생성할 때 지정된 레지스트리에서 이미지를 Pull하여 컨테이너를 실행한다.

5-2. Red Team: 공격 방법

공격자가 레지스트리 접근 권한을 탈취하여 정상 이미지를 악성 코드가 심어진 이미지로 교체한다.

  • 공격 기법: 이미지 내부에 백도어나 리버스 쉘 코드를 삽입하여 기존 태그로 덮어쓰기한다.

  • 결과: 관리자가 정상적인 절차로 파드를 생성하더라도, 실행되는 컨테이너는 이미 오염된 상태이므로 공격자가 즉시 접속할 수 있다.

5-3. Blue Team: 방어 및 조치 전략

강연에서는 이미지 스캔 및 해시 키 비교를 언급했다. 이를 자동화된 파이프라인으로 구축해야 한다.

  • 이미지 서명 및 검증:

    • Cosign이나 Notary를 사용하여 이미지를 서명한다.

    • 배포 시 Admission Controller(Kyverno, OPA Gatekeeper)가 서명이 유효한 이미지만 실행되도록 강제한다.

  • 이미지 취약점 스캔: CI/CD 파이프라인 및 레지스트리(Harbor 등) 단계에서 Trivy, Clair 등을 사용해 이미지를 주기적으로 스캔한다.

  • 불변 태그 사용: 레지스트리 설정에서 한 번 푸시된 태그(예: v1.0)를 덮어쓰지 못하도록 설정하거나, 이미지 태그 대신 고유한 해시값(sha256:abcd...)을 사용하여 배포한다.


6. 시나리오5: 악의적인 관리자와 특권 파드


6-1. 정상적인 흐름

쿠버네티스 관리자 권한을 가진 사용자(혹은 탈취된 계정)가 파드를 생성한다.

6-2. Red Team: 공격 방법

관리자 계정이라도 호스트 서버(마스터/워커 노드)의 루트 파일 시스템에는 직접 접근할 수 없다. 하지만 관리자는 파드를 생성할 권한이 있다.

  • 공격 기법: 호스트의 루트 디렉토리(/)를 파드 내부의 볼륨으로 마운트(hostPath 방식 이용)하는 특권 파드를 생성한다.
  • volumes:
      - name: host-root
        hostPath:
          path: /
  • 결과: 파드 내부로 진입(exec)하면 마운트된 볼륨을 통해 호스트의 모든 파일(Shadow 파일, SSH 키 등)을 읽고 수정할 수 있어 호스트를 완전히 장악한다.

6-2. Red Team: 공격 방법

강연에서는 관리자 권한 제한 및 모니터링을 언급했다.

이는 50:50의 싸움이라고 했지만, 기술적으로 통제 가능하다.

  • Pod Security Admission (PSA) 적용: 네임스페이스 수준에서 Restricted 또는 Baseline 정책을 적용하여 hostPath 사용이나 privileged 모드를 원천 차단한다.

  • 정책 엔진 도입 (Policy-as-Code): OPA Gatekeeper나 Kyverno를 사용하여 "특정 그룹을 제외하고는 hostPath 마운트 금지"와 같은 세밀한 정책을 강제한다.

  • RBAC 최소화:

    • 파드 생성 권한은 생각보다 강력한 권한이다.

    • 개발자에게는 파드 생성 권한 대신, 제한된 범위의 권한만 부여하거나 ArgoCD와 같은 GitOps 도구를 통해서만 배포하도록 통제한다.

  • Audit Logging: 쿠버네티스 Audit Log를 활성화하고, SIEM 시스템(Falcosecurity 등)과 연동하여 특권 파드 생성이 시도될 때 즉시 알람을 발생시킨다.


7. 정리


방어자의 업무는 매우 어렵다.

공격자는 수많은 취약점 중 단 하나만 성공시키면 클러스터를 장악할 수 있지만, 방어자는 모든 구멍을 막아야 하기 때문이다.

오늘 살펴본 5가지 시나리오는 빙산의 일각이며, 쿠버네티스 보안을 강화하기 위해서는 'Hacking Kubernetes', 'Container Security'와 같은 전문 서적을 참고하고, 지속적으로 클러스터의 보안 태세를 점검하는 것이 필수적이다.


0개의 댓글