기사 공유하기

클라우드 네이티브(Cloud Native) 컴퓨팅에 대한 관심이 높아지고 있다.

컨테이너와 마이크로서비스 아키텍처, 그리고 지속 통합/배포(CI/CD: Continuous Integration & Continuous Deployment) 자동화로 대표되는 클라우드 네이티브 컴퓨팅은 쿠버네티스(Kubernetes)와 같은 오픈소스 기반의 오케스트레이션 도구의 확산에 힘입어 성장세를 가속화 하고 있다.

클라우드 네이티브 컴퓨팅을 지원하는 기관인 CNCF(Cloud Native Computing Foundation)에 참여하고 있는 기업의 수도 이제 상당한 수준에 이르고 있다. 현재 400개가 넘는 기업들이 활동을 하고 있으며 가장 높은 등급인 플래티넘 멤버십을 가지고 있는 18개의 기업에는 아마존, 마이크로소프트, 구글, 알리바바, VM웨어, IBM, 레드햇, 오라클과 같은 대표적인 클라우드 기업이 총 망라되어 있다.

이들 클라우드 서비스 벤더의 클라우드 네이티브 컴퓨팅에 대한 확신(committment)을 통해 최소한 향후 몇 년 동안은 클라우드 네이티브 컴퓨팅이 주요 키워드로 IT 업계에서 주목받을 것으로 짐작할 수 있다. 가트너(Gartner)에서는 현재 컨테이너화 된 애플리케이션을 실행하고 있는 기관이 약 30% 수준이지만, 2022년까지 전체 75%의 기관이 컨테이너화를 할 것으로 예측했다. 즉, 4개 중 3개의 기관은 클라우드 네이티브 컴퓨팅을 적용할 것으로 내다 본 것이다.

3/4
가트너는 2022년까지 전체 75%의 기관이 컨테이너화할 것으로 예측했다.

클라우드 네이티브 컴퓨팅의 중요성, 다양한 영역에서 확인 중 

클라우드 네이티브 컴퓨팅은 이제 단순한 소프트웨어 개발 패러다임을 넘어 다양한 영역에 적용되고 있다. 그 대표적인 예가 5G의 네트워크 가상화이다. SDN(Software Defined Network) 개념에 기반한 네트워크 기능 가상화(NFV: Network Function Virtualization)에 클라우드 네이티브 컴퓨팅의 핵심 요소인 오케스트레이션(Orchestration)이 적용되기 때문이다. 오케스트레이션 대상은 가상화된 네트워크 기능(VNF: Virtualized Network Function)이다.

다시 말해, 각 VNF를 컨테이너화 하여 쿠버네티스와 같은 오케스트레이션 도구를 활용하면 마치 마이크로서비스 기반 구조에서 서비스를 구성하듯 용도와 목적이 상이한 가상 네트워크를 구성할 수 있다는 것이다. 이동통신 서비스 4G부터 나오기 시작한 NFV가 5G에서는 클라우드 네이티브 컴퓨팅 기술을 적용하여 주요 차별화 포인트가 될 것이란 전망이다.

또한, 2019년도 클라우드 컴퓨팅의 주요 키워드로 각광을 받은 하이브리드 클라우드 컴퓨팅에서도 클라우드 네이티브 컴퓨팅은 매우 중요한 역할을 담당한다. 하이브리드 클라우드는 퍼블릭 클라우드와 프라이빗클라우드를 동일 기관 혹은 기업에서 동시에 사용하는 것을 말한다. 회사의 워크로드 중 보안에 민감하거나 실시간 속도 등 반응속도가 중요한 것, 혹은 사용자가 직접 통제를 해야 하는 부분을 프라이빗 클라우드에서 실행하고 그 외 워크로드를 퍼블릭 클라우드에서 실행하는 것이 일반적인 하이브리드 클라우드의 활용 형태다.

또 다른 하이브리드 클라우드의 장점은 프라이빗 클라우드에서 갑자기 증가한 워크로드를 퍼블릭클라우드로 분산시킬 수 있다는 점이다. 그 반대로 프라이빗 클라우드에 여유가 생기면 좀 더 민감한 회사의 워크로드를 퍼블릭 클라우드로부터 가져올 수도 있다. 이 때 프라이빗 클라우드와 퍼블릭 클라우드 간 원활하게 워크로드 재배치가 이루어지기 위해서는 각각 워크로드의 호환성이 매우 중요하다. 이를 해결 할 수 있는 방법이 바로 컨테이너다. 컨테이너화 된 워크로드를 쿠버네티스와 같은 오케스트레이션 도구를 활용하여 프라이빗 클라우드와 퍼블릭 클라우드에 자유롭게 배치할 수 있다. 즉, 하이브리드 클라우드가 그 목적을 제대로 달성하기 위해서는 클라우드 네이티브 컴퓨팅이 필수다.

클라우드 네이티브 컴퓨팅의 확산에 가장 큰 기여를 한 오픈소스 프로젝트는 단연 쿠버네티스(참조: 쿠버네티스란 무엇인가)다. 쿠버네티스 자체가 오픈소스 프로젝트로 누구나 직접 가져다 적용할 수 있는 것이지만, 기존 클라우드 벤더나 혹은 솔루션 벤더들이 쿠버네티스를 기반으로 한 다양한 서비스와 솔루션을 제공하고 있으며, 이로 인해 기업에서의 활용이 더욱 확산되었다고 볼 수 있다. 일부 기업은 메조스(Mesos)나 스웜(Swarm) 같은 또 다른 오케스트레이션 도구로부터 쿠버네티스로 갈아타기도 한다. 2018년과 2019년 두 번에 걸쳐 IT 데브옵스(DevOps)와 보안 관계자들을 대상으로 실시한 쿠버네티스 등 오케스트레이션 활용 조사 결과에서도 오케스트레이션 도구 활용 확대, 특히 쿠버네티스의 강세를 확인할 수 있다.

쿠버네티스 https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
쿠버네티스

쿠버네티스가 리드하는 오케스트레이션 시장

쿠버네티스가 메인스트림 오케스트레이션 도구로 자리를 잡는데 큰 역할을 한 것은 포켓몬고 게임이라고 한다. 나이안틱(Niantic)은 포켓몬고를 2016년 출시할 때부터 구글 컨테이너 엔진과 쿠버네티스를 활용한 것으로 알려졌다. 일본 출시 이후 미국으로 확장하면서 원래 예상했던 것보다 50배 많은 사용자가 단시간에 몰려들었다고 한다. 이는 심지어 최악의 시나리오로 산정했던 사용자 폭등 수준의 10배이다. 그러나 컨테이너와 쿠버네티스 기반으로 런칭을 한 덕분에 이런 갑작스러운 사용자 폭등도 큰 이슈 없이 무난히 잘 대응해 나갈 수 있었다는 것이다. 쿠버네티스가 현장에서 확실하게 검증이 된 셈이다.

포켓몬 고

이때부터 쿠버네티스 활용은 크게 증가하기 시작했다. 국내에서 엔씨소프트가 모바일 게임을 대상으로 쿠버네티스를 처음 적용하기 시작한 것도 이 때부터이다. 앞서 언급한 조사 결과에 의하면 2018년 오케스트레이션을 도입한 기업의 57%가 쿠버네티스를 사용하고 있었지만 1년도 채 안된 시점인 2019년의 조사에서는 86%의 기업이 쿠버네티스를 도입하여 활용하는 것으로 나타났다.

다양한 솔루션 벤더들이 매니지드(managed) 서비스를 제공하고 있지만, 자체적으로 쿠버네티스를 관리/운용하는 곳도 44%나 되는 것으로 드러났다. 국내에서 비교적 활발하게 쿠버네티스 도입을 확대하고 있는 엔씨소프트도 자체적으로 쿠버네티스를 관리/운용하는 회사 중 하나다. 거의 매달 나오는 업데이트를 일일이 새로 적용하는 것이 결코 만만하지 않은 일임을 엔씨소프트의 한 인프라 운영 관계자가 필자에게 토로한 적도 있다.

많은 회사가 쿠버네티스 솔루션을 두 가지 이상 사용한다. 퍼블릭 클라우드를 사용하는 기업은 우선 그 벤더가 제공하는 쿠버네티스를 기본적으로 사용해야 하므로 그 외 쿠버네티스를 적용한다면 다수 벤더를 활용하는 것은 어쩌면 매우 자연스러운 현상이기도 하다. 또한 거의 모든 클라우드 서비스 혹은 솔루션 벤더들이 자체 쿠버네티스 버전을 제공하기 때문에 꽤 다양한 벤더 솔루션들이 활용되고 있음을 알 수 있다(아래 도표 참조).

쿠버네티스 벤더별 사용 현황 (출처: Cloud Tech)
쿠버네티스 벤더별 사용 현황 (출처: Cloud Tech)

클라우드 네이티브 컴퓨팅 확산의 걸림돌은 보안?

컨테이너와 쿠버네티스의 확산세가 지속되는 가운데, 기업 입장에서 가장 우려하는 부분은 역시 보안이다. 클라우드 네이티브의 기본 사상은 컨테이너 이미지를 자동으로 분산 배치하여 실행하는 것이다. 이는 컨테이너 이미지가 만들어진 다음 분산 배치 단계와 실행단계를 거치며 공격의 표적이 될 수 있음을 의미한다.

특히 매우 빈번하게 빌드 및 배포가 이루어지는 클라우드 네이티브의 특성상 매번 빌드나 배포가 자동으로 이루어질 때마나 공격을 받을 수도 있다. 빌드 시 컨테이너를 오염시키거나, 배포 시 일부 컨테이너를 교체할 수도 있다. 만일 오케스트레이션을 관장하는 쿠버네티스 관리자 권한이 침해될 경우는 말 그대로 재앙에 가까운 결과를 초래할 수도 있다. 실제로 CNCF에서는 보안 감사를 통해 쿠버네티스 코드의 34개 취약점을 공개하기도 했다.

보고된 취약점들은 지속적인 쿠버네티스 업그레이드를 통해 해결이 되기도 하지만, 일부는 단순히 쿠버네티스 업그레이드만으로 완벽하게 해결 될 수는 없다. 쿠버네티스를 본격적으로 도입하기 위해서는 기존 보안 정책으로 커버되기 어려운 많은 부분들이 보완되어야 한다는데 의견이 일치한다. 특히 개발 사이클에서 CI와 CD로 연결되는 파이프라인에서의 보안 통제가 절대적으로 필요하다는 의견이다.

컨테이너 라이프 사이클을 빌드(build), 배포(deployment), 실행(runtime), 이 세 가지로 구분했을 때 기본적으로 실행단계에서의 취약점에 대한 우려가 가장 높지만, 빌드와 배포 단계에서의 취약점에 대한 우려도 만만치 않게 높은 편이다. 특히 2018년과 2019년 조사를 비교해 보면 2019년에는 배포 단계에서의 우려가 다소 더 높아진 것을 볼 수 있다(아래 도표 참조)

가장 보안에 취약한 단계가 어디인지에 대한 조사 결과 (출처: Cloud Tech)
가장 보안에 취약한 단계가 어디인지에 대한 조사 결과 (출처: Cloud Tech)

CI/CD 파이프라인 단계에서 취약점을 보완할 수 있는 방안으로 이미지 스캐닝을 통합하는 것도 제시되고 있다. 빌드 단계에서 만들어진 결과물 자체의 취약점은 없는지 분석하는 과정을 빌드와 배포단계 사이에 넣는 것이다. 특히 오픈소스 컴포넌트, 라이브러리, 프레임워크에 대한 스캐닝을 강조하고 있다. 만일 취약점이 확인된 오래된 버전을 활용하여 만들어진 컨테이너라면 당연히 문제가 있는 것으로 판단할 수 있다. 물론 이미지 스캐닝으로 모든 취약점이 파악될 수는 없지만, 지속적인 모니터링과 학습을 통해 알려진 취약점들을 발견할 확률을 높일 수 있다.

이 밖에도 가트너에서는 다음과 같은 보안 관련 사안들을 제시했다.

  • CIS(Center for Internet Security)에서 제시한 도커(Docker) 및 쿠버네티스 벤치마크에 기반하여 철저한 형상관리를 실시할 것.
  • 접근 제어를 강제화 하고 보안정책에 따른 의무를 강화하며, 특히 암호 키나 데이터베이스 접근 권한 등이 외부로 노출되지 않도록 쿠버네티스에 의해 런타임 동안 생성되고 관리될 수 있도록 할 것.
  • 루트 권한과 같은 특별 권한을 갖는 컨테이너는 반드시 피할 것.
  • 컨테이너의 이상 동작이나 악성 시도를 탐지할 수 있는 도구를 최대한 활용할 것.

쿠버네티스 등 컨테이너 오케스트레이션 도구를 활용하는 기업들이 많아졌다고 하나, 지금과 같은 확산단계에서 아직 드러나지 않은 잠재적 보안 위협들은 분명 존재한다. 악성 의도를 품은 컨테이너로 인한 보안 침해가 가장 자주 발생할 것으로 예상되지만, 쿠버네티스 환경을 설정하는 과정에서의 인적 과실에 의한 보안 위협도 간과할 수 없다.

보안

실제로 퍼블릭 클라우드를 활용하면서 나올 수 있는 보안 침해사고의 흔한 유형이라고도 알려져 있다. 이에 클라우드 네이티브 컴퓨팅을 도입하는 기관에서는 해당 기술과 프레임워크를 구축하는 것 보다, 이를 운영할 인적자원에 대한 교육이 선결되어야 한다고 가트너에서도 강조한다.

또한, 마이크로서비스 기반 개발 패러다임에서 가장 핵심이면서도 취약한 요소인 API에 대한 보안도 더욱 강화되어야 한다. 권한부여 및 인증, 암호화는 기본이고 위협이 될 수 있을만한 요소들을 모두 체크해 보는 것도 필요하다. 클라우드 네이티브 컴퓨팅 환경에서 보안은 이처럼 복잡성이 증대되고 있다.

개발과 운영이 밀접하게 결합되어 CI/CD로 가면서 데브옵스(DevOps)가 보편화되었지만, 아직 보안은 또 다른 영역으로 여겨지는 것이 일반적이다. 하지만 컨테이너를 근간으로 하는 클라우드 네이티브에서의 보안은 새로운 도전적인 과제들을 제시하고 있다. 이를 해결하는 것은 결국 개발/보안/운영이 매끄럽게 결합된 형태의 방식이 필요할 것으로 전문가들은 바라보고 있다. 즉 데브섹옵스(DevSecOps)가 이제 데브옵스를 대체할 수도 있다는 뜻이다.

그러면 앞으로 클라우드 네이티브 컴퓨팅은?

비록 보안 이슈가 클라우드 네이티브 컴퓨팅 도입의 넘어야 할 장애물이긴 하지만, 그럼에도 불구하고 확산 속도는 줄어들지 않을 것이다. 컨테이너와 쿠버네티스를 활용함으로써 누릴 수 있는 장점들을 결코 가벼이 볼 수 없기 때문이다. 소프트웨어 개발과 배포의 속도, 유연함, 규모 확대, 신기술 적용 등 보안에 대한 우려를 넘어설 수 있는 강점들이 너무 많기 때문이다.

기업들도 실제 상용 서비스를 컨테이너 기반으로 운영하는 비율을 점차 늘여가고 있다. 앞서 언급한 클라우드 테크(Cloud Tech) 조사에 의하면 상용 서비스의 50% 이상을 컨테이너 기반으로 운영한다고 답한 회사 비율이 2018년에는 13%였으나 2019년 조사에서는 22%로 무려 70%나 늘어났다. 반면 상용서비스의 10% 미만을 컨테이너 기반으로 운영한다고 답한 회사는 52%에서 39%로 줄었다. 클라우드 네이티브의 확산은 계속되고 있다.

클라우드 컴퓨팅

그러나 만일 클라우드 네이티브를 우선 적용하고 보안 이슈는 그 이후 대응한다는 도입/확산 전략을 수립하고 있다면, 이는 잘못된 전략이다. 클라우드 네이티브의 강점을 제대로 살리기 위해서는 잠재적 보안 위협에 대한 충분한 사전 고려가 필요하다. 특히 민감한 워크로드를 컨테이너화 하는 것은 충분한 검토와 조직 내 공감대를 형성한 후 실시해도 늦지 않다. 잠재적 위협을 최대한 예방할 수 있도록 조직 역량이 확보되었는지 체크리스트부터 준비하여야 할 것이다.

이는 매니지드(managed) 서비스를 통해 클라우드 네이티브를 도입한다고 해도 마찬가지이다. 제3의 전문기관과의 협력도 좋은 접근 방식이다. 외부의 시각에서 내 조직이 클라우드 네이티브를 도입하는 목적과 예상되는 성과, 그리고 잠재적 리스크에 대해 정리함으로써 좀 더 안정적인 도입 및 단계별 확산을 이룰 수 있다.

어떤 경우든 ‘왜 클라우드 네이티브인가?’에 대한 질문에 모두가 공감할 수 있는 답을 갖고 시작하는 것이 결국 핵심이다.

이제 클라우드 네이티브 컴퓨팅은 대세다. 그리고 남은 문제는 '보안'이다.
이제 클라우드 네이티브 컴퓨팅은 대세다. 그리고 남은 문제는 ‘보안’이다.

 

[divide style=”2″]

[box type=”note”]

본 글은 한국정보화진흥원의 지원을 받아 작성되었으며, 클라우드스토어 씨앗 이슈리포트에 동시 게재합니다.

[/box]

관련 글