SSH 없이 Kubernetes Node에 접근 하기

2–3분

1. 언제 사용할까?

보안 정책상 SSH 접근이 차단된 환경에서 Kubernetes 노드에 직접 접근해야 할 경우가 있다. 서비스 장애 대응이나 노드의 상태를 점검하려면 SSH 없이도 접근할 수 있는 방법이 필요하다.

이 글에서는 Pod + nsenter 조합을 활용하여 SSH 없이 노드에 접근하는 방법과, 추가적으로 systemddbus를 활용해 systemctl을 활용하는 방법에 대해 이야기 하려고 한다.


2. Pod를 통한 노드 접근

Kubernetes에서 특정 노드의 프로세스 네임스페이스 및 시스템 리소스에 접근하기 위해 특수한 Pod를 생성

2.1 Pod 생성 예시 (YAML)

아래 YAML 파일을 사용하면 Kubernetes Pod가 노드의 파일 시스템과 프로세스에 접근할 수 있도록 설정

apiVersion: v1
kind: Pod
metadata:
  name: systemctl-access
spec:
  hostPID: true  # 노드의 PID 네임스페이스 공유
  containers:
  - name: ubuntu
    image: ubuntu
    command: ["sleep", "3600"]
    securityContext:
      privileged: true  # 노드의 시스템 자원에 접근 가능
    volumeMounts:
    - mountPath: /mnt/host
      name: host-root
    - mountPath: /run/dbus/system_bus_socket
      name: dbus-socket
    - mountPath: /run/systemd/system
      name: systemd-socket
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory
  - name: dbus-socket
    hostPath:
      path: /run/dbus/system_bus_socket
      type: Socket
  - name: systemd-socket
    hostPath:
      path: /run/systemd/system
      type: Directory

2.2 Pod 실행 및 접근

kubectl apply -f systemctl-access.yaml
kubectl exec -it systemctl-access -- bash

Pod 내부에서 실행하면 노드의 파일 시스템과 프로세스에 접근


3. nsenter를 이용한 노드 직접 접근

Pod 내부에서 nsenter 명령어를 실행하면 해당 노드의 네임스페이스로 이동

3.1 nsenter 명령어 실행

nsenter --target 1 --mount --uts --ipc --net --pid /bin/bash

3.2 nsenter 옵션 설명

옵션설명
--target 1PID 1(systemd)의 네임스페이스를 가져옴
--mount파일 시스템 접근 가능
--uts호스트 이름 및 도메인 네임스페이스 공유
--ipc프로세스 간 통신 네임스페이스 공유
--net네트워크 네임스페이스 공유
--pid프로세스 네임스페이스 공유

이 명령을 실행하면 Pod 내부에서 노드의 네임스페이스로 전환되며, 노드에 직접 접근한 것과 같은 환경에서 작업할 수 있다.


4. systemddbus를 활용한 데몬 제어

4.1 systemd와 dbus를 마운트하는 이유

  • systemctl 명령어를 실행하려면 systemd의 소켓 및 프로세스 접근 권한이 필요
  • /run/systemd/system 디렉터리와 /run/dbus/system_bus_socket을 마운트하면 Pod 내부에서 systemd 명령어를 직접 사용 가능

4.2 데몬 컨트롤 예시

Pod 내부에서 systemctl을 실행하여 노드의 서비스를 관리

(1) 서비스 상태 확인

systemctl status kubelet

(2) 서비스 재시작

systemctl restart kubelet

(3) 특정 유닛 실행

systemctl start docker

이제 SSH 없이도 Kubernetes 노드에서 서비스를 관리하고 디버깅 필요


5. 보안 고려 사항

5.1 보안 리스크

  • privileged: true 설정을 사용하면 컨테이너가 호스트의 모든 리소스에 접근 가능
  • 잘못된 설정 시 노드 전체의 서비스가 중단될 위험

5.2 보안 강화 방법

  • RBAC을 활용해 특정 사용자만 실행할 수 있도록 제한
  • Pod 실행 후 바로 삭제 kubectl delete pod systemctl-access
  • DaemonSet을 사용할 경우 특정 노드에서만 실행되도록 조정 필요

6. 결론

  • systemddbus를 마운트하면 SSH 없이도 Kubernetes 노드의 데몬을 직접 관리
  • 이를 활용하면 시스템 제어가 가능하며, 클러스터 내에서 노드의 상태를 직접 확인
  • 보안 리스크가 크므로 필요한 경우에만 사용하고 접근을 제한하는 것이 중요

이 방식은 긴급 장애 대응, 자동화된 서비스 관리, 운영 효율화, SSH가 차단된 환경에서 사용 해볼 수 있다.

원격 접속이 안된다고 당황하지 말고 pod를 통해 호스트에 직접 접근 해보자!