본문 바로가기

Kubernetes(k8s)/chroot의 한계

Chroot의 한계

         1.1.        Chroot란?

 

컨테이너의 역사를 거슬러 올라가면 제일 처음 chroot가 등장한다. chroot는 프로세스의 루트 디렉토리를 변경하는 리눅스 시스템콜/명령어로, 1979년 UNIX V7에서 추가되어 원격 유저(FTP, SSH 등)를 특정 디렉터리에 가두기 위한 용도로 사용되었다. chroot는 Change Root Directory의 줄임말로, 특정 디렉토리를 “루트 디렉토리로 지정할 수 있으면 루트 디렉터리 밖으로는 못 나가기 때문에 해당 경로에 프로세스를 가둘 수 있다는 점에 착안하였고, chroot에 갇힌 프로세스는 현재 디렉터리를 루트로 인지하여 작동하기에 프로세스를 실행할 때 필요한 커맨드 프로그램, 라이브러리, 설정 등을 chroot로 지정할 경로에 함께 넣어 주어야 한다.

 

 

         1.2.        Chroot의 한계

 

     탈옥이 가능하다.

chroot의 목적은 프로세스를 특정 디렉터리에 가두기 위한 것인데, 탈옥이

가능하다는 한계가 있어 실제 컨테이너에서는 사용하지 않는다.

 

     격리되지 않는다.

호스트 상의 다른 프로세스들이 루트 권한만 있으면 chroot 경로에 접근할 수 있고,

chroot한 프로세스도 “ps”, “mount” 등 시스템 바이너리만 복사하면 다른 프로세스

및 시스템 정보들을 볼 수 있다. “보인다"는 것은 곧 격리되지 않음을 의미하고

프로세스 간에 서로 영향을 주고받을 수 있음을 의미한다.

 

     루트 권한 제어가 필요하다.

 chroot 명령을 쓰려면  루트 권한이 필요하고 , chroot로 실행하는 프로세스도 루트 

권한을 가지게 된다. 보안 측면에서 컨테이너를 비롯한 어떤 프로세스든 루트

권한을 가지게 하는 것은 매우 위험하다. 따라서 루트 권한 없이 컨테이너를

기동하고, 컨테이너 프로세스가 필요한 작업을 수행할 수 있도록 적절한 권한을

부여하는 방법이 필요하다.

 

     리소스 제한이 되지 않는다.

chroot로 실행하더라도 호스트의 리소스를 제한 없이 사용할 수 있어 CPU나

Memory, IO, 네트워크 등의 사용량을 제한하지 못한다. 이는 특정 컨테이너에서의

과도한 리소스 사용으로 다른 프로세스에 영향을 줄 수 있다.