K06: Exposed Components — 외부 노출된 컴포넌트

쿠버네티스 클러스터에는 API 서버, Kubelet, 대시보드(Dashboard), etcd 등 운영에 필수적인 관리용 컴포넌트가 존재합니다. K06은 이처럼 강력한 권한을 가진 관리 도구가 인터넷에 무방비로 노출되었을 때 발생하는 위험을 다룹니다.

미션: 인증되지 않은 관리 인터페이스 노출

쿠버네티스 대시보드나 관리 인터페이스를 공인 IP로 노출하고 적절한 인증 절차를 거치지 않으면, 공격자가 클러스터 제어권을 완전히 빼앗을 수 있습니다.

1. 취약한 코드 (vulnerable.yaml)

대시보드 서비스를 LoadBalancer 타입으로 설정해 외부 인터넷에서 직접 접속 가능하게 만든 상태입니다.

apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard
spec:
  type: LoadBalancer # 🚨 위험: 외부에서 접속 가능한 공인 IP 할당
  ports:
    - port: 80
      targetPort: 9090

분석: 인증 기능이 비활성화된 대시보드를 외부로 노출하면, 공격자는 브라우저만으로 클러스터 상태를 확인하고 Pod를 삭제·수정하는 등 관리자 권한 수준의 공격을 수행할 수 있습니다.

2. 해결책 코드 (fixed.yaml)

외부 노출을 차단하고, 내부에서만 접근 가능하도록 변경하거나 인증을 강화합니다.

# 1. 서비스 타입을 ClusterIP로 변경하여 외부 노출 차단
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard
spec:
  type: ClusterIP # ✅ 개선: 클러스터 내부에서만 접근 가능
  ports:
    - port: 80
      targetPort: 9090

# 2. 접근이 꼭 필요하다면 반드시 인증(RBAC/OIDC)을 거치도록 설정
#    (대시보드 설정에서 --enable-skip-login=false 확인 등)

분석: type: ClusterIP로 변경하면 해당 서비스는 클러스터 내부 IP로만 접근할 수 있어 외부 공격으로부터 안전해집니다. 운영상 외부 접속이 꼭 필요하다면 반드시 VPN을 거치거나, OAuth/OIDC 같은 강력한 인증 레이어를 앞에 두어야 합니다.

실습: 공격 → 방어 검증

1) 공격 — 인증 없이 대시보드 접속

kubectl apply -f vulnerable.yaml
# 브라우저에서 <LoadBalancer-IP> 접속
# → 로그인 없이 관리자 화면이 그대로 표시됨

2) 방어 — ClusterIP 전환 후 재확인

kubectl apply -f fixed.yaml
# 외부에서 <이전 IP>로 접속 시 Connection Refused

# 관리자는 안전한 터널링으로만 접근
kubectl proxy
# http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

ClusterIP로 바꾸는 순간 외부 접속 경로 자체가 사라지고, 관리자는 kubectl proxy 같은 인증된 터널을 통해서만 접근할 수 있습니다.

체크리스트

• 대시보드, etcd, Kubelet API 등 관리용 컴포넌트가 LoadBalancer/NodePort로 외부 노출되어 있지 않은가
• 꼭 외부 접근이 필요한 컴포넌트라면 VPN 또는 OIDC 인증 레이어를 거치는가
• --enable-skip-login, anonymousAuth 같은 인증 우회 옵션이 비활성화되어 있는가
• 클러스터 외부에서 kubectl get pods --insecure-skip-tls-verify 류의 요청이 거부되는지 주기적으로 점검하는가

“관리용 도구는 절대로 인터넷에 직접 노출하지 마라"는 보안의 금기 사항을 배우는 실습입니다. 다음 미션(K07: Cluster Components)에서는 노출 여부를 넘어, 클러스터 핵심 컴포넌트 간의 통신 자체가 암호화·인증되어 있는지를 다룹니다.