[프로젝트/보안 실전 가이드] 처음부터 제대로 배우는 도커

도커(DOCKER)

1.  뉴스 & 요약 (https://www.itworld.co.kr/news/203644)

2013년을 기점으로 리눅스와 유닉스에서 사용되던 컨테이너가 오픈소스 프로젝트인 도커 기술로 보편화 되었다. 과거 서비스 플렘폼으로 시작하여 소프트웨어 컨테이너 보편화로 변화된 도커는 닷클라우드 플렛폼을 구동할 기저 기술에 대한 많은 개발자들의 관심과 노력으로 탄생되었다. 도커는 간단한 방식으로 복제하고 이동하고 백업 할수 있기 때문에 기존의 것보다 이식성과 유연성이 더 높다. 이를 통해 도커는 개발자에게 VM시대로부터 벗어나게 해 실행환경을 격리시키고 기저 OS커널을 공유할수 있게 되었다. 이렇게 도커에는 오케스트레이션과 스케일링에 대한 이점과 이식성, 컴포저블이라는 장점을 가지고 있지만 이자체가 VM이 아니기 때문에 호스트 운영체제 리소스의 제어된 부분을 사용하여 베어메탈에 근접하지만 동일한 속도를 낼 수 없다. 또한 VM처럼 여러 세션들에 걸쳐 지속성이 뛰어나지 않아 메모리가 제거되면 영원히 사라진다.

 

2.  실행과정

Docker란 Linux 컨테이너를 만들고 사용할 수 있도록 하는 컨테이너화 기술이다.

 

-   도커와 리눅스 컨테이너의 차이점

 

전통적인 리눅스 컨테이너는 멀티플 프로세스를 관리할 수 있는 초기화 시스템을 사용한다. 즉, 전체 애플리케이션을 하나로 실행할수 있다.

 

하지만 도커는 애플리케이션을 개별적으로 프로세스를 새분화하여 수행할 수 있는 툴을 제공한다.

 

-   도커 컨테이너의 이점

①    모듈성

전체 애플리케이션을 분해할 필요 없이 일부를 분해해서 업데이트 또는 복구하는 능력이 뛰어나다. 또한 멀티플 애플리케이션 사이에서 프로세서 공유가 가능하다. (SOA와 동일)

②    계층 및 이미지 버전 제어

도커 이미지는 일련의 계층으로 이루어져 있다. 이 계층들은 단일 이미지로 결합되고 복사 실행과 같은 명령을 지정할 때 혹은 이미지가 변경될 때마다 계층이 생성된다. 이때 이러한 계층을 재사용하므로 구축 프로세서가 빠르고 내장 변경 로그가 기본적으로 적용되므로 컨테이너 이미지를 완전히 제어할 수 있다.

③    롤백

롤백 기능은 계층화에서 유용한 이점이다. 모든 이미지에 계층이 존재하고 원한다면 이전 버전으로 롤백이 가능하다.

④    신속한 배포

각 프로세서에 대한 컨테이너를 생성함으로써 유사한 프로세스를 새 앱과 빠르게 공유 가능하고 OS 부팅 필요성이 없어 배포 시간이 대폭 감소한다.

 

-   도커 다운받는 실습 과정

 

< docker 다운 확인 결과 >

-   이미지 pull

도커는 docker hub를 통해 이미지를 다운받아 그 image를 실행하는 것을 container이라고 한다. 즉, dockerhub라는 공간에서 imgae를 다운받는 것을 pull이라고 하고 이 image를 실행한 과정(container)을 run이라고 한다.

-   DOCKER HUB에 대한 세부 설명

docker hub에는 개발에 필요한 거의 모든 환경을 이미지라는 형태로 찾을 수 있다. node라는 것또한 이미지로 올라와있다. 이처럼 도커의 이미지란 리눅스 컴퓨터의 특정 상태를 캡쳐해 보관한 것을 말한다. 이처럼 node 이미지는 Node.js가 설치된 상태를 그대로 캡쳐해서 클라우드에 올려놓은 것이다.

 

도커(DOCKER)

 

1.  뉴스 & 요약

[사이버 공격 동향①] 쉽게 공격해 높은 수익 얻는 공격자 - 데이터넷 (datanet.co.kr)

공급망을 이용한 대규모의 피해는 가성비 끝판왕이라고 불릴정도로 적은 노력으로 큰 피해를 입힐수 있다고한다. 그 이유는 하나의 해킹으로 다른 기업도 침투가 가능하기 때문이다. 소프트웨어 패치 및 업데이트 파일을 오렴시키고 감염된 도커 이미지를 도커허브에 게시하면 이를 이용한 모든 서비스는 공격이 가능하다. 그렇게 되면 이 서비스를 이용한 모든 고객에게 피해가 가능하다.

 

 

[클라우드 보안-컨테이너 보안①] 도커 보안 기술 경쟁 시작 - 데이터넷 (datanet.co.kr)

클라우드 인프라 효율성을 극대화하는 서버리스 컴퓨링으로 진화하는 만큼 기존 클라우드 보안 솔루션도 많은 변화가 필요하다고 한다. 이에 컨테이너 기반 네트워크 보안 경쟁이 시작되었다고 한다. 컨테이너 서버리스는 매우 빠르게 변경되기 때문에 컨테이너 내에서 혹은 통신에서 이상징후 여부로 파악하는 방안을 제시했다. 기존에 데브옵스로는 클라우드 전체를 다루기 적합하지 않았고 팔로알토네트웍스에서는 CNSP를 구현하는 방법으로 클라우드 네이티브 아키텍처 내에 보안이 자연스럽게 프로세싱 될수 있도록 하는 NGFW를 소개했다.

 

 

 

2.  조사한 자료 및 실행 과정 Ⅰ

도커 컨테이너 보안

다른 컨테이너 보안과 비슷하게 호스트에서 네트워크 사이의 모든 것을 보호하는 포괄적인 접근 방식이 필요하다. 이동하는 부분으로 인해 많은 조직에서 컨테이너 보안을 보장하기는 어렵지만 기초적 수준 이상의 경계가 필요하다.

 

< 고려해야할 사향 >

▶    리소스 할당량 활용

리소스 할당량을 사용하면 메모리 및 CPU를 컨테이너로 제한 할 수 있습니다. 각 컨테이너에서 리소스 할당량을 구성하면 환경의 효율성을 높이는데 도움이 될뿐만 아니라 환경의 모든 컨테이너에서 리소스의 불균형을 방지 할 수 있습니다.

이를 통해 컨테이너는 예상한 속도로 성능을 발휘하고 보안을 강화할 수 있습니다. 컨테이너 하나가 악의적인 콘텐츠에 감염되면 할당량으로 인해 컨테이너에 많은 양의 리소스를 허용 할 수 없으므로 공격에 미치는 영향을 최소화 할 수 있습니다. 이것은 간단한 보안 전술이며 command-line 플래그를 사용하여 수행 할 수 있습니다.

-   리소스 할당량 활용 COMMAND [메모리제한]

①  컨테이너 설정 지원 확인하는 방법

docker inspect <컨테이너>

id서부터 memory, image까지 컨테이너의 설정정보를 확인할 수 있다.

②  메모리 제한

docker run -d –memory=”1g” –name=<컨테이너> nginx

단위는 MB, GB로 제한할수 있는 최소메모리는 4MB이다.

위 컨테이너는 메모리가 1기가바이트로 한정되 있는 시스템으로써 NginX서버를 실행시키는 컨테이너이다. 따라서 컨테이너에서 작동하는 프로세스가 컨테이너에 할당된 메모리를 초과하면 컨테이너는 자동으로 종료된다. 따라서 실행할 어플리케이션에 따라서 메모리를 적절하게 할당하는 것이 좋다. 반대로 악성 리소스가 침범할경우 많은 양의 리소스를 허용 할 수 없어서 공격에 미치는 영향을 최소화할수 있다. 만약, 메모리가 부족한 상태로 컨테이너를 실행하면 에러가 발생하며 실행되지않는다.

swing1 이라는 이름으로 메모리는&amp;amp;nbsp;1기가로 도커를 실행시켰다.

&amp;amp;lsquo;docker ps&amp;amp;rsquo;를 통해&amp;amp;nbsp;swing1에 대한 컨테이너가 생성된 것을 확인할수 있다.

③  메모리 제한 확인 방법

docker inspect <컨테이너> | grep \”Memory\”

swing1을 1기가 바이트로 메모리를 제한했기 때문에 Memory가 1073741824로 설정된 것을 볼수 있다. 이숫자는 1기가 바이트를 바이트 단위로 환산했을 때 나오는 숫자이다.

④  부족한 메모리로 컨테이너를 실행할 경우
아래 그림과 같이 최소한의 메모리가 6MB라고 에러 문구가 등장하면서 컨테이너가 실행되지 않는다. 

- 리소스 할당량 활용 COMMAND [CPU제한]
①  --cpu-shares: 기본값은 1024로 CPU 할당에서는 1을 뜻한다. 2048로 설정할 경우 기본 컨테이너보다 2배 많은 시간을 할당 받을 수 있다.
②  --cpuset-cpus : 호스트에 여러개의 CPU가 있을 때 컨테이너가 특정 CPU만 사용하도록 설정한다.
③  --cpu-period: CPU 주기를 설정하며 -period의 기본값은 100000이며 100ms를 뜻한
④  --cpu-quota: -period에 설정된 시간 중 CPU 스케줄링에 얼마나 할당할 것인지 설정한다
>> 예를 들어 -period = 100000이고 -quota=25000을 할당하면 CPU주기가 ¼로 줄어 일반적인 컨테이너보다 CPU성능이 ¼로 감소한다. 즉, 컨테이너는 [-cpu-quota 값] / [--cpu-period 값]만큼 CPU 시간을 할당받습니다.
⑤  --cpus : 이전의 --cpu-period, --cpu-quota, --cpu-share와 비슷하지만 좀더 직관적으로 CPU사용량을 정의할 수 있다. 예를 들어 --cpus=0.1이라고 한다면 해당 컨테이너는 전체 CPU 중에 10%를 사용한다는 뜻이다.
▶ 도커 컨테이너가 루트로 실행되면 안되는 이유
▶ 도커 컨테이너 레지스트리 보안
▶ 신뢰할 수 있는 출처 사용
▶ 코드 소스로 이동

3. 조사한 자료 및 실행 과정 Ⅱ
< 이미지를 실행시켜 컨테이너를 만드는 실습 >
: command로 run하는 실습 
① docker run [OPTIONS] IMAGE [COMMAND] [ARG..]
httpd 이미지를 사전에 pull명령어를 통해 가져왔다. 이후 httpd 이미지를 실행시켜 컨테이너를 만들었다.

docker run 이후 명령이 끝나는 것이아니라 실시간으로 도커의 실행(도커 logs)을 확인 가능

docker run httpd와 는 달리 --name이라는 옵션을 사용하여 swing1이라고 지칭했다. 만약 --name이라는 옵션을 사용하지 않고 run할 경우 위 그리과 같이 컴퓨터 내에서 임의로 알아서 지정해준다. –name은 이미지 이름 앞에 오는 대표적인 OPTIONS중 하나이다. 

지금 보면 httpd, 하나의 이미지로 여러 개의 도커 컨테이너를 만들수 있음을 알수있다. 

②  docker stop [컨테이너 이름]
docker을 끝내고 싶을경우에는 stop 명령을 사용한다.

지금 위 사진을 보면 shutting down gracefully라고 마무리하면서 도커가 중지됨을 확인할수 있다.&nbsp;

stop명령어를 통해 중지시켰다 하더라고 docker자체가 사라지는 것은 아니다. docker ps상에서는 사라져 안보이지만 docker ps -a에서는 아직 swing1이 남아있다. 따라서 stop을 하더라고 해당 도커가 완전히 삭제된 것은아니고 실행이 중지된다고 이해하면 된다.

③  docker start [컨테이너 이름]
중지한 도커를 다시 실행하고 싶을경우 사용하는 명령어이다.

④  docker logs [컨테이너 이름] / docker logs -f [컨테이너 이름]
stop으로 중지한 도커를 다시 start를 통해 실행시키더라도 stop으로 한번 중지시켰기 때문에 실시간으로 logs가 보이지 않는다. 이 logs를 다시 보여주는 명령어가 docker logs [컨테이너 이름]이다. 만약 정적인 것이 아니라 실시간으로 보고싶을경우에는 docker logs [컨테이너 이름]을 사용하면 된다. 

⑤  docker rm [컨테이너 이름] / docker rm --force [컨테이너 이름]

swing1과&nbsp;condescending_villani&nbsp;컨테이너가&nbsp;실행중임

docker rm swing1을 할 경우 swing1이 &lsquo;docker ps&rsquo;실행 사진상 실행되고 있는 컨테이너로 나타나기 때문에 삭제가 안된다. 즉, 실행중인 컨테이너는 rm으로 일반적으로 삭제가 안된다. 따라서 docker stop swing1을 통해 정지시킨후 삭제시켜야한다.

또는 condescending_villani가 실행중인 컨테이너이지만 rm --force를 통해 강제적으로 삭제할수 있다.&nbsp;

⑥ docker rmi [이미지 이름]

두개의 이미지중 httpd 이미지를 삭제하고자 했고 docker rmi httpd를 실행시켰다. 

그런데 위 그림과 같이 오류가 발생했고 오류 내용을 읽어보니 1d6cb8ebb6cb라는 컨테이너가 이미지에 사용되고 있어 삭제가 안된다고 나타났다.&nbsp;

아까 컨테이너를 삭제할때와 같은 흐름인것같아서 docker ps를 통해 남아있는 컨테이너를 확인했다. docker ps상에서는 남아있는 컨테이너가 없어서 docker ps -a를 하니까 &lsquo;1d6cb8ebb6cb&rsquo;이라는 id를 가진 hardcore_cartwright 컨테이너를 확인할수 있었다.&nbsp; &nbsp;&nbsp;

docker stop후 docker rm을 통해 컨테이너 삭제를 했다.

docker ps -a상에서도 보이지 않았다. &nbsp;

이후 docker rmi httpd를 다시 실행시켜본 결과 제대로 이미지가 삭제되는 것을 볼수 있었다.&nbsp;

docker images에서도 hello-world를 제외한 이미지는 모두 없는 것을 확인 할 수 있었다.