Container Network - 컨테이너 격리

컨테이너 아키텍처

컨테이너는 "격리된 프로세스"라고 할 수 있습니다.

• "격리"의 대상은 프로세스, 파일 시스템에 해당하는 커널단을 격리하는 방법과, CPU/Memory와 같은 하드웨어 리소스를 격리하는 방법이 존재합니다.

이때, 커널 Namespace는 프로세스의 격리를 보장하고, cgroup은 시스템 리소스를 제어하는데 사용됩니다.
추가로, SELinux를 통해 호스트, 컨테이너 및 개별 컨테이너 간의 분리를 보장하는데 사용됩니다.

이​번 포스팅에서는 컨테이너의 격리 관점 중 Namespace를 통한 프로세스의 격리를 확인해보도록 하겠습니다.

컨테이너 vs 하이퍼바이저

프로세스 격리를 살펴보기 전에, 컨테이너와 하이퍼바이저의 차이점을 알고 가시면 이해에 도움이 됩니다. 두 방식간의 가장 큰 차이점은 GuestOS의 유/무입니다.

• 하이퍼바이저의 경우 하드웨어 레벨을 가상화한 GuestOS를 활용하기에, 호스트와 거의 완벽하게 격리됩니다(강한 격리).

컨테이너의 경우 GuestOS가 아닌, Host의 커널을 직접 공유하여 활용합니다(약한 격리).

컨테이너의 약한 격리

컨테이너는 Host 커널을 직접 공유한다고 했었습니다.
그렇기에, Host에서도 직접 컨테이너를 제어할 수 있다라고 해석될 수 있습니다.

약한 격리 확인

컨테이너에서 tail 명령을 통해 블로킹 상태를 유지한 후, 호스트에서 프로세스 제어(kill 명령)를 통해 컨테이너에도 영향이 미치는지 확인해보도록 하겠습니다.

docker run --rm -d ubuntu tail -f /dev/null #컨테이너에서 tail 명령 실행
ps -ef | grep tail #호스트에서 tail 프로세스 검색
docker ps #docker ps를 통해 컨테이너 정상 실행중 확인
kill -9 {process_id} #호스트에서 kill 명령 실행
docker ps #컨테이너가 자동적으로 종료됨을 확인

==> 호스트의 kill 명령이 컨테이너에 영향을 미침을 확인

Namespace

Linux는 Namespace(NS)를 통해 프로세스 격리를 지원합니다.

• Namespace에는 ID가 존재하며, 최초 프로세스인 Init Process와 이후 프로세스인 Child Process로 나뉩니다.

두 프로세스를 실습을 통해 호스트에서 컨테이너 격리 시 어떤 점들이 달라지는지 확인해보도록 하겠습니다.

컨테이너 격리시 Namespace 확인

Host에서 확인 진행

먼저, Init process의 NS와 현재 사용중인 쉘의 NS를 확인하도록 하겠습니다.
이후, 새로운 bash 쉘에서의 사용중인 NS를 비교해보겠습니다.

ls -l /proc/1/ns #Init Process NS 확인
echo $$ #$$는 현재 사용중인 프로세스 ID를 의미
ls -l /proc/$$/ns #현재 사용중인 쉘의 NS ID 확인
bash && echo $$ #새로운 쉘 실행 및 새로운 쉘 프로세스 ID 확인
ls -l /proc/$$/ns #새로운 쉘의 NS ID 확인

==> 위의 과정을 통해 호스트에서는 새로운 쉘을 실행하여도, Init Process와 NS ID가 달라지지 않는 점을 확인 가능합니다.

Container에서 확인 진행

컨테이너는 NS를 통해서 커널단이 격리됩니다. 즉, 호스트와는 다른 환경에서 실행하는 것처럼 새로운 NS가 생성될 것이라 예상할 수 있습니다.

docker run --rm -it busybox /bin/sh #쉘 사용이 가능하도록 컨테이너 실행
ls -l /proc/1/ns #컨테이너 내부에서 Init Process NS ID 확인

==> Host의 Init Process와 Container의 Init Process가 User NS를 제외하면 모두 다른 것을 확인 가능합니다.

• User NS ID가 같은 것은 Docker의 기본 동작에 해당하는 정상적인 상황입니다.
  상황에 따라서, User NS 또한 Host와 격리도 가능하다는 점을 참고하시기 바랍니다.
  • 사용자 네임스페이스로 컨테이너 격리