DEVOCEAN

kubernetes를 운영하기위해 kubectl을 사용하여 cli접근하는 경우도 많지만 필요에따라서는 UI를 활용할 필요가 있다.

kubernetes dashbord는 이러한 요구를 해소하고자 WebUI를 제공하고 있다.

(https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)

출처: https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/

공식툴 외에도 다양한 3rd party 제품들이 있으나 그 중 lens(https://k8slens.dev/)가 군계일학으로 가장 간결하면서도 많은 기능을 제공한다고 판단하여 초창기(2019년)부터 써오고 있다.

기본적인 UI를 통한 운영현황 모니터링 및 조작을 제공하는 것 외에도 secret의 값을 ui상에서 decord해주거나 서비스나 워크로드에 포트포워딩도 제공하고 개별 pod로 접근하게 하는 등 다양한 부가기능이 있다.

작년부터 수익사업을 위해 유료화 움직임이 있었고 2023년 상반기에 기업사용자의 무료사용이 불가해질 예정이다.

출처: https://k8slens.dev/

이에따라 오픈소스부분을 패키징하여 배포하는 대용품이 있어 이로 전환하였다.

(https://github.com/MuhammedKalkan/OpenLens)

오픈소스버전을 사용하면서 대부분 동일한데 기존 사용하던 Lens에 비해 가장 아쉬운 부분이 Lens UI에서 k8s 클러스터의 각 노드의 shell에 접근하여 필요한 작업을 하던 부분이다.

이에 따라 이를 대용할 방법을 찾게 되었고 이 글을 통해 찾은 방법을 공유하고자 한다.

LENS에서 노드 shell에 접근방법

클러스터에 연결한 상태에서 위와 같이 노드 정보에서 노드를 선택하여 접속아이콘을 누르면 shell에 연결된 창이 열린다.

대부분의 작업을 root 권한으로 수행할 수 있다. 다만 kubelet이나 containerd (혹은 dockerd)를 재시작하면 문제상황에 만날수 있으니 주의하자.

그 이유는 아래 기본동작원리를 확인하면 유추할 수 있다.

기본원리

Shell에 접근하는 기본원리는 매우 간단하게 권한이 있는 컨테이너를 실행시키고, 실행된 컨테이너에 접속하는 방식이다.

아래를 살펴보면 shell 접근을 한경우 nsenter-xxx이라는 pod가 실행되고 있음을 확인할 수 있다.

이 pod는 해당 노드에 접근권한이 있는 컨테이너를 갖고 있으며 해당 컨테이너에 접근하므로써 실제 노드에 접근한 것과 동일한 수준의 작업이 수행가능하게 된다.

kubectl-node-shell

이제 아쉬운 부분의 대용품을 찾아보자. 이를 대용할수 있는 오픈소스 프로젝트가 https://github.com/kvaps/kubectl-node-shell이다.

이를 활용하면 LENS에서 제공했던 동일한 기능을 획득할 수 있다. 이를 설치하고 사용하는 방법은 매우 단순하다.

리눅스의 경우 아래와 같이 binary를 다운받아 실행가능위치에 옮기면 끝난다. (kubectl의 sub-command로 동작하므로 kubectl은 해당 환경에 미리 준비되어야 한다.)

curl -LO https://github.com/kvaps/kubectl-node-shell/raw/master/kubectl-node_shell
chmod +x ./kubectl-node_shell
sudo mv ./kubectl-node_shell /usr/local/bin/kubectl-node_shell

바이너리가 실행가능한 위치로 옮겨졌으면 kubectl node-shell 명령을 통해 노드에 접근할 수 있다.

출처: https://github.com/kvaps/kubectl-node-shell

siim@dev:~$ kubectl get no
NAME   STATUS   ROLES                  AGE    VERSION
c1     Ready    <none>                 244d   v1.23.6
c2     Ready    <none>                 244d   v1.23.6
c3     Ready    <none>                 244d   v1.23.6
com1   Ready    <none>                 244d   v1.23.6
com2   Ready    <none>                 244d   v1.23.6
m1     Ready    control-plane,master   244d   v1.23.6
m2     Ready    control-plane,master   244d   v1.23.6
m3     Ready    control-plane,master   244d   v1.23.6

siim@dev:~$ kubectl node-shell m1
spawning "nsenter-8d43y2" on "m1"
If you don't see a command prompt, try pressing enter.
root@m1:/#root@m1:/# whoami
root
root@m1:/# hostname
m1

위 실행내역을 보면 root계정으로 해당 노드에 접근한 것을 확인할 수 있다.

이때 클러스터의 default 네임스페이스에 “nsenter-8d43y2” 라는 pod가 노드 m1에 생성됐음을 확인할 수 있다.

siim@dev:~$ kubectl get po -o wide
NAME                            READY   STATUS    RESTARTS         AGE     IP                NODE   NOMINATED NODE   READINESS GATES
busybox                         1/1     Running   1204 (17m ago)   50d     192.168.105.165   com1   <none>           <none>
dev-my-nginx-66cb9474dd-d2mxc   1/1     Running   0                50d     10.233.30.213     com1   <none>           <none>
dev-my-nginx-66cb9474dd-zws2f   1/1     Running   0                50d     10.233.33.173     com2   <none>           <none>
nsenter-8d43y2                  1/1     Running   0                9m44s   192.168.105.101   m1     <none>           <none>
xk6-loki                        1/1     Running   1 (77d ago)      94d     10.233.33.156     com2   <none>           <none>

마치며

본 글을 통해 간단하게 kubernetes 노드에 root 권한으로 접근할 수 있는 방법에 대해 알아보았다.

이것은 또한 보안적으로 기본 설정을 사용하는 것이 얼마나 위험한 것인지도 보여주는 사례라 할 수 있다.

kubernetes 클러스터에 접근해서 권한이 있는 컨테이너로 pod를 생성할 수 있다면 시스템의 root권한을 갖는 것이기 때문에 상용으로 사용하는 클러스터라면 이를 막을수 있는 방법이 필요하다.

이 방법에 대해서는 다음 글을 통해 알아볼 예정이다.