제로 트러스트 아키텍처 컨테이너, 쿠버네티스 보안은 어떻게?

On-premise 서버나 클라우드의 VM의 경우 Vault 라 불리는 제로 트러스트 아키텍처 솔루션에 의해 접근제어 권한 제어가 가능합니다. 하지만 도커의 컨테이너 또는 쿠버네티스 환경에서는 어떻게 접근제어를 적용할 수 있을까 라는 물음에서 시도했던 정책 한 가지 소개하려 합니다. 

 

사실 컨테이너의 경우 IaC 로서 장애가 났거나 다른 문제점이 있을 경우 기존의 것을 내리고 새로운 컨테이너를 run 시키기 때문에 컨테이너에 어떻게 접근하고 어떻게 접근을 제어하지를 고려할 필요가 없습니다. 

 

하지만 일부 희박하게 컨테이너 내부에 들어가서 필요한 작업이 있을수도 있다라는 생각에 컨테이너 접근제어 방안에 대해 생각하게 되었습니다. 사실 위의 아키텍처처럼 Baston(kubectl) 또는 도커의 호스트 OS 에서 exec 명령어를 통해 접근하는 방법이 있긴 하지만 이미 이곳에 접근해있다는 것 자체가 모든 권한을 가지고 있음을 의미합니다. 

 

어쨌든 kubectl 또는 docker의 모든 명령어를 허용해 줄 수는 없지만 컨테이너에 들어가게만 해줄게라는 컨셉으로 만들어 본 정책을 소개하려 합니다. 

 

기존의 방식대로 Bastion에서 kubectl/docker 명령어가 아닌 vault 에서 직접 컨테이너에 ssh 접근이 가능합니다. 사용자에게 컨테이너의 정보가 공개되며 원하는 컨테이너를 클릭해 접속이 가능합니다. 

 

예를 들어 yaml 파일을 통해 tomcat pod/deployment 를 EKS에 올렸습니다. 원래라면 bastion에서 exec -it <pod name> /bin/bash 와 같은 명령어로 컨테이너 내부에 들어갈 수 있지만 bastion을 거치지 않고 바로 컨테이너에 들어갈 수 있습니다. 

 

이 과정을 차례대로 나열 하자면

 

1. yaml 파일을 통해 tomcat을 올림. 

2. Vault에 tomcat 이 하나 자동으로 올라옴.

3. 사용자는 이 컨테이너에 바로 root로 접속한다.

 

 

tomcat을 올리니 이렇게 2개의 컨테이너가 떴습니다. (replica set을 올려 2개가 올라왔습니다.)

 

서버의 ssh처럼 컨테이너에 바로 접속할 수 있습니다. 

 

이제는 기술적인 측면에서 어떻게 컨테이너를 빌드했는지를 설명하려 합니다. 원래 기본적으로 컨테이너는 하나의 프로세스만을 실행시키고 있습니다. 예를 들어 nginx 컨테이너는 nginx 하나를 PID 1번으로 mysql은 mysql을 PID 1번으로 실행시킬 뿐 다른 어떠한 프로세스는 존재하지 않습니다. One conatiner One process 인 것입니다. 

 

실제로 컨테이너 내부에 들어가 ps -ef을 입력하게 되면 아예 실행조차 안됩니다. 왜냐하면 ps 가 입력 가능한 app 조차 깔려있지 않기 때문입니다. 어쨌든 ps를 깔고 ps -ef를 쳐보면 이렇게 나옵니다. 

실제로는 ps 명령어조차 실행되지 않습니다. 

PID 1번인 ngnix master process와 PID 1에서 파생된 2개의 process 만 존재합니다. 

 

다시 말하면 컨테이너는 경량화된 리눅스 OS로 필요 없는 app 들은 아예 깔려있지 않습니다. (예 ps, vi 등등) 마찬가지로 ssh 가 깔려있지 않아 원격으로 컨테이너에 접속하는 것은 원칙상 불가능합니다. 

 

하지만 ssh 등 몇 가지 app을 추가로 설치해 사용자가 컨테이너에 직접 붙을 수 있게 해 주었습니다.

원래라면  PID 16 인 아파치가 1로 혼자 있어야 하지만 ssh 도 깔고 나머지 의존성이 걸린 app들도 깔고 vault와 api 통신을 위한 에이전트까지 설치했습니다. 그렇기 때문에 프로세스를 관리해줄 프로세스 매니저 역할을 할 init가 PID 1 로서 나머지 프로세스를 관리해주는 모습입니다. 

 

다시 한번 워크플로우를 정리하자면

 

1. 개발자는 컨테이너를 빌드하고 ECR에 배포한다.

2. EKS 운영자는 이 컨테이너를 EKS 환경에 올린다.

3. 컨테이너가 생성되고 실행되고 있다.

4. 개발자는 로그 수집 등의 업무를 위해 컨테이너에 vault를 통해 접근한다.

5. EKS 운영팀은 개발자에게 따로 baston을 제공해 주지 않아도 된다.

 

사실 저는 이렇게 쓰는 게 맞는지는 모르겠습니다. 다만 컨테이너, K8S의 보안은 어떻게 하나 라는 물음에서 시작되었지만 현실적으로 이 방법은 불가능할 것이라 예상합니다. 

 

1. docker hub에 있는 이미지를 모두 수정해야 한다 (ssh, vault agent, init 설치를 위해)

2. 사이드카 방식으로 pod 내부에서 하나의 보안용 컨테이너가 다른 컨테이너 보안을 위해 쓰이기보다는 모든 컨테이너를 이렇게 사용해야 한다.

3. 하나의 컨테이너에 이렇게 멀티 프로세스를 구현하는 방식이 맞는가 라는 의구심이 든다. 

4. 실제로 컨테이너에 접근해야 할 빈도가 얼마나 될까.

 

라는 이유로 실제로 쓰이기는 어렵지 않을까라고 생각합니다. 개인적인 생각으로 컨테이너 사용이 일상적이 되었지만 보안정책은 아직 미비하지 않나라고 생각하고 있습니다. 제로 트러스트 아키텍처라는 컨셉이 나온 시점도 아마 컨테이너까지는 고려하지 못하지 않나라고 생각합니다. 

 

아무튼 하나의 특이한 경우라고 생각하고 봐주시기 바랍니다.