ClickCease 컨테이너화된 워크로드의 보안을 유지하는 데 KernelCare가 도움이 되는 방법 - TuxCare

인기 뉴스레터 구독하기

4,500명 이상의 Linux 및 오픈소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

컨테이너화된 워크로드의 보안을 유지하는 데 KernelCare가 도움이 되는 방법

2021년 1월 6일 TuxCare 홍보팀

컨테이너화된 워크로드의 보안을 유지하는 데 KernelCare가 도움이 되는 방법OS 가상화는 대규모 엔터프라이즈 컴퓨팅 애플리케이션을 제공하는 데 있어 큰 진전을 이루었습니다. 하지만 가상 머신은 시작에 불과했습니다. 컨테이너는 가상화를 한 단계 더 발전시켜 애플리케이션을 거의 원활하게 전송할 수 있는 전례 없는 유연성을 제공합니다.

그러나 컨테이너에는 컨테이너화의 특성에서 비롯된 숨겨진 보안 위험이 있습니다. 이 문서에서는 기업에서 컨테이너화의 역할에 대해 논의하고, 컨테이너가 기업 보안 위험이 될 수 있는 이유를 설명하며, 효과적인 해결책을 제시합니다.

콘텐츠:

  1. 컨테이너화된 워크로드란 무엇인가요?

  2. 가상화에서 컨테이너화까지

  3. 기업에서 컨테이너를 사용하는 방법

  4. 컨테이너와 호스트의 관계

  5. 격리되었지만 여전히 취약한 상태

  6. 패치되지 않은 Kernel: 숨겨진 컨테이너 보안 위험?

  7. Kernel 패치 관련 문제

  8. KernelCare 라이브 패치 통합

  9. 컨테이너 Kernel 보안을 위한 기타 팁

  10. 결론

 

잠깐만요. 컨테이너화된 워크로드란 무엇인가요?

컨테이너가 보안 위험이 될 수 있는 이유를 이해하려면 컨테이너가 정확히 무엇인지, 컨테이너화된 워크로드가 무엇인지 이해해야 합니다.

먼저 가상화에 대해 다시 한 번 살펴보겠습니다. 얼마 전까지만 해도 컴퓨터 운영체제와 그 운영체제가 실행되는 하드웨어는 뗄 수 없이 연결되어 하나의 물리적 서버가 하나의 운영체제와 연결되었습니다. 가상화는 하드웨어와 하드웨어에서 실행되는 운영 체제 사이에 계층을 삽입하여 이를 변경합니다. 가상화는 운영 체제와 하드웨어 간의 일대일 구속 관계를 제거합니다.

가상화된 운영 체제에서는 마치 하드웨어에 유일한 운영 체제인 것처럼 보입니다. 백그라운드에서는 가상화 소프트웨어(하이퍼바이저)가 추상화 계층을 관리하여 각 OS가 머신에 다른 운영 체제가 있는지 인식하지 못하도록 합니다.

가상화 덕분에 하나의 머신에서 여러 운영 체제를 실행할 수 있고, 한 머신에서 다른 머신으로 운영 체제를 쉽게 전송할 수 있습니다. 결과적으로 효율성과 유연성이 향상됩니다.

 

가상화에서 컨테이너화까지

가상화를 언급하는 이유는 컨테이너화가 무엇을 하는 것인지 설명하는 데 도움이 되기 때문입니다. 가상화가 물리적 장비와 운영 체제 사이에 추상화 계층을 두는 것이라면, 컨테이너화는 운영 체제와 애플리케이션 사이에 추상화 계층을 추가합니다.

기본적으로 가상화가 하드웨어를 가상화한다면 컨테이너화는 운영 체제를 가상화합니다 . 컨테이너화를 사용하면 각 애플리케이션이 컨테이너라는 격리된 유닛에 캡슐화됩니다. 컨테이너화된 애플리케이션은 각 컨테이너가 독립적으로 작동하기 때문에 운영 체제 환경을 공유하지 않습니다.

그러나 컨테이너는 Kernel을 포함한 운영 체제의 요소에 대한 읽기 전용 액세스를 공유합니다. 그럼에도 불구하고 각 애플리케이션은 운영 체제에서 단독으로 실행되는 것처럼 보이며, 애플리케이션은 운영 체제 환경을 공유하고 있다는 사실을 서로 인식하지 못합니다.

결과적으로 컨테이너화된 워크로드는 엔터프라이즈 요구 사항을 지원하는 애플리케이션이 호스트 운영 체제 내부의 격리된 컨테이너에서 실행되는 환경을 의미합니다.

 

기업에서 컨테이너를 사용하는 방법

컨테이너 내부에 애플리케이션을 격리하면 보안과 안정성 측면에서 이점이 있다고 생각할 수 있으며, 이는 맞습니다. 하지만 컨테이너화의 이점은 그 이상입니다.

컨테이너화를 통해 기업은 표준화된 방식으로 다양한 유형의 인프라에 애플리케이션을 패키징하고 배포할 수 있습니다. 이론적으로는 (호환 가능한) 컨테이너를 호스팅할 수 있는 모든 호스트는 컨테이너화된 애플리케이션도 호스팅할 수 있습니다.

이는 컨테이너화가 애플리케이션 계층을 추상화하기 때문에 발생합니다. Docker와 같은 컨테이너 기술은 표준화된 방식으로 이러한 추상화를 용이하게 합니다. 이 표준화된 동작의 핵심은 컨테이너 이미지라고 하는 것입니다. 컨테이너 이미지에는 애플리케이션 코드뿐만 아니라 컨테이너화된 애플리케이션을 바로 사용할 수 있도록 하는 시스템 라이브러리 및 기타 주요 설정도 포함됩니다.

컨테이너는 애플리케이션 보안과 안정성을 뛰어넘는 컨테이너화의 핵심 이점을 제공합니다. 컨테이너는 본질적으로 이식성이 뛰어나다는 점입니다. 이는 엔터프라이즈 애플리케이션에 몇 가지 중요한 이점으로 이어집니다:

  • 이동성은 민첩성을 의미합니다. 컨테이너화된 애플리케이션은 익숙하지 않은 새로운 환경에서도 쉽게 실행할 수 있습니다. 개발자는 컨테이너 이미지를 릴리스할 수 있으며, 기업 고객은 컨테이너가 Docker와 같은 표준 컨테이너 환경에 적합하기만 하면 애플리케이션을 안심하고 배포할 수 있습니다. 컨테이너를 사용하면 애플리케이션을 매우 민첩하게 배포할 수 있습니다.
  • 컨테이너는 리소스가 가볍습니다. 컨테이너화된 애플리케이션은 전체 가상 운영 체제를 시작하는 것보다 훨씬 쉽고 빠르게 증설할 수 있습니다. 동시에 단일 호스트 머신은 가상 OS 인스턴스보다 훨씬 더 많은 컨테이너를 지원할 수 있습니다. 그렇기 때문에 컨테이너는 데이터센터 효율성 측면에서 가상화보다 훨씬 더 큰 이점을 제공합니다.
  • 자동화된 배포 및 관리. 컨테이너의 표준화된 특성 덕분에 기업은 컨테이너화된 애플리케이션을 동적으로 배포하고 관리할 수 있습니다. 이를 컨테이너 오케스트레이션이라고 합니다. Kubernetes와 같은 오케스트레이션 도구는 대규모로 애플리케이션을 롤아웃하고 모니터링하는 작업을 자동화합니다.

컨테이너화는 가상화의 이점을 확장하고 증폭합니다. 엔터프라이즈 사용자는 표준화된 컨테이너를 통해 애플리케이션을 배포할 때 전례 없는 수준의 확장성과 관리 편의성을 얻을 수 있습니다.

 

컨테이너와 호스트의 관계

컨테이너화는 특히 대규모 엔터프라이즈 애플리케이션과 관련된 경우 상당한 이점을 제공합니다.

그러나 컨테이너는 애플리케이션 배포 방식에 큰 변화를 가져왔으며, 실용적이고 실제로 보안적인 관점에서 컨테이너와 호스트 간의 관계를 파악하는 것이 도움이 됩니다.

컨테이너가 격리된 방식으로 실행되는 것은 사실이지만, 컨테이너도 구성 요소를 공유한다는 점을 이해하는 것이 중요합니다. 이렇게 하면 컨테이너의 모든 애플리케이션에 대해 별도의 운영 체제를 실행하는 데 따른 오버헤드를 제거할 수 있습니다.

또한 컨테이너는 전체 운영 체제에 비해 시작이 더 빠르다는 것을 의미합니다. 그렇다면 컨테이너는 호스트의 어떤 요소를 공유할까요? 운영 체제 Kernel은 가장 중요한 공유 요소입니다. 호스트에는 실행 중인 Kernel이 하나만 있으며 호스트의 모든 컨테이너가 이 Kernel을 공유합니다.

다음으로, 드라이버와 OS 애플리케이션 바이너리는 컨테이너가 공유하며, 컨테이너는 호스트 OS 스토리지도 공유하지만 스토리지는 격리되어 있습니다. 마지막으로, 컨테이너는 컨테이너 플랫폼(예: Docker)도 공유합니다.

컨테이너가 이렇게 격리된 방식으로 실행될 수 있는 것은 컨테이너 플랫폼(예: Docker)에서 격리를 적용하는 데 사용되는 몇 가지 핵심 Linux 기능에서 비롯됩니다. Kernel 네임스페이스와 c그룹은 독립적인 컨테이너가 모두 동일한 Linux 호스트를 공유할 수 있도록 지원합니다.

 

격리되었지만 여전히 취약한 상태

컨테이너는 높은 수준의 격리를 제공하므로 위협이 한 애플리케이션에서 다른 애플리케이션으로 쉽게 전파될 수 없는 보호 수준을 제공한다는 것은 분명합니다.

그러나 컨테이너화된 워크로드에 내재된 리소스 공유로 인해 컨테이너는 여전히 취약하며, 실제로 조직이 주의해야 하는 새로운 취약성을 초래할 수 있습니다. 몇 가지 예를 살펴보겠습니다:

  • 이미지 보안. 신뢰할 수 있는 출처의 컨테이너 이미지만 실행하는 것이 중요합니다. 오염된 이미지와 패치되지 않은 이미지 모두 공격의 문을 열어줄 수 있습니다. 이미지 안전과 보안은 정말 중요합니다.
  • 컨테이너 플랫폼 보안. 다른 소프트웨어와 마찬가지로 컨테이너 플랫폼에도 보안 위험이 있을 수 있습니다. 예를 들어 runC 루트 액세스 원격 실행 취약점컨테이너 소프트웨어 공급업체에서 일반적으로 사용하는 runC 라이브러리에 내재된 취약성을 예로 들어보겠습니다.
  • 권한 상승 위험. 이론상으로는 애플리케이션이 컨테이너에서 유출되어서는 안 되지만, 컨테이너에서 사용 중인 사용자 권한에 매우 주의할 필요가 있습니다. 어떤 이유로든 컨테이너 앱에 루트 액세스 권한이 있는 경우 브레이크아웃으로 인해 공격자가 전체 시스템에 대한 루트 액세스 권한을 갖게 될 위험이 존재합니다. 앞서 설명한 runC 위험은 브레이크아웃 보안 위험의 전형적인 예입니다.

따라서 애플리케이션이 격리되는 동안 격리 메커니즘인 컨테이너는 자체적인 보안 위험을 초래하므로 기업은 이러한 보안 위험을 완화하는 방식으로 컨테이너화된 워크로드를 관리해야 합니다.

 

패치되지 않은 Kernel: 숨겨진 컨테이너 보안 위험?

컨테이너의 공유 구성 요소는 분명히 보안 위험으로 이어집니다. 그러나 컨테이너화된 애플리케이션의 가장 큰 보안 위험은 공유 OS Kernel입니다 . 호스트 Kernel로 인한 보안 위험은 기본적으로 눈에 잘 띄지 않는 곳에 숨어 있습니다.

호스트의 모든 컨테이너는 동일한 운영 체제 Kernel을 공유한다는 점을 기억하세요. 조직이 공유 OS Kernel로 인한 위험을 고려하지 않고 컨테이너화의 격리 및 보안 이점을 오해할 위험이 있습니다.

그러나 OS Kernel이 손상되면 컨테이너 내부의 애플리케이션도 손상될 수 있습니다. 그리고 OS Kernel은 모든 형태와 규모의 보안 침해로 이어진 오랜 역사를 가지고 있습니다.

그렇기 때문에 컨테이너화된 워크로드를 보호하는 데 있어 Kernel 보안이 매우 중요합니다. 컨테이너화된 워크로드를 위한 안전한 Kernel을 확보하기 위해 할 수 있는 몇 가지 방법이 있습니다. 최신 Kernel 보안 위험을 인지하고, Linux Kernel에 컨테이너 워크로드에 필요한 서비스만 포함되도록 하는 것입니다.

물론 Kernel 패치도 잊지 마세요.

 

Kernel 패치 관련 문제

Linux Kernel은 지속적으로 패치됩니다. 취약점이 발견되면 커뮤니티는 이러한 취약점에 대응하기 위해 Linux Kernel의 코드를 조정하고 패치를 릴리스합니다. 패치가 적용되지 않은 시스템은 위험하지만 패치가 적용된 시스템은 그렇지 않습니다.

패치는 컨테이너 보안을 크게 강화하는 간단한 보안 조치이므로 당연한 일입니다. 하지만 지속적으로 패치를 적용하는 것은 매우 어려울 수 있습니다:

  • 패치는 시간이 많이 걸립니다. 릴리스되는 Linux Kernel 패치의 양을 고려할 때 많은 조직에서 패치 적용에 어려움을 겪을 수 있으며, 특히 수천 대의 머신을 보유한 대규모 기술 자산의 경우 더욱 그렇습니다.
  • 일관된 패치는 비용이 많이 듭니다. 패치를 자동화하지 않으면 패치를 배포하는 데 최고의 기술팀도 리소스를 소모할 수 있습니다. 패치는 비용이 많이 드는 프로세스가 되어 비용 절감 및 비용 절감을 위한 쉬운 대상이 됩니다.
  • 패치는 중단을 초래합니다. Kernel 패치를 적용하려면 서버를 다시 시작해야 하는 경우가 많습니다. 많은 워크로드에서 재시작은 매우 큰 중단을 초래합니다. 컨테이너를 재시작하는 것은 매우 빠를 수 있지만 전체 호스트를 재시작하면 눈에 띄는 서비스 중단이 발생할 수 있습니다. 그 결과 패치가 지연되는 경우가 많습니다.

컨테이너화된 워크로드의 가장 큰 보안 위험 중 하나는 사실 일관성 있게 관리하기가 매우 어렵다는 점입니다.

 

KernelCare 라이브 패치 통합

패치 자동화는 컨테이너화된 워크로드에서 Kernel 취약성의 위험을 성공적으로 줄이기 위한 첫 번째 단계입니다. 또 다른 중요한 단계는 서버를 재시작하지 않고도 OS Kernel을 업데이트할 수 있는 라이브 Kernel 패치입니다. KernelCare 라이브 패치는 이 두 가지를 모두 제공합니다.

컨테이너화된 워크로드를 관리하는 기업은 KernelCare를 사용하여 컨테이너 호스트의 Kernel이 일관되게 패치되고 중단 없이 패치되도록 할 수 있습니다. 설치 방법은 간단합니다. 평소와 같은 방식으로 KernelCare를 설치하기만 하면 됩니다.

컨테이너 호스트에 패치를 적용하기 위해 KernelCare를 사용하면 결과적으로 컨테이너에서 사용 중인 Kernel에 대한 완전 자동 패치를 사용할 수 있습니다. 컨테이너는 호스트의 Kernel을 공유하기 때문에 컨테이너 호스트에 KernelCare를 한 번만 설치하면 해당 호스트의 모든 컨테이너에 Kernel 업데이트가 적용됩니다.

요컨대, KernelCare는 컨테이너화와 관련된 가장 큰 보안 위험 중 하나를 처리할 수 있는 효율적이고 실용적인 방법입니다.

 

컨테이너 Kernel 보안을 위한 기타 팁

이 글을 마무리하기 전에 컨테이너 호스트의 Kernel을 안전하게 유지할 때 고려해야 할 몇 가지 다른 사항에 대해 알아보겠습니다. 네, 패치는 매우 중요하지만 다음 사항도 고려해야 하는데, 대부분은 서버 보안을 위한 좋은 습관일 뿐입니다:

  • 루트 사용자를 제거합니다. 루트 사용자를 제한하면 격리에서 벗어난 컨테이너가 전체 서버에 대한 루트 액세스 권한을 자동으로 얻지 못하도록 할 수 있습니다.
  • 실행하는 Kernel 모듈을 제한하세요. 서버를 설정할 때 Kernel 모듈을 추가하여 서버를 확장할 수 있습니다. 보안을 극대화하려면 컨테이너화된 환경에 필요한 최소한의 Kernel 모듈만 설치하는 것이 좋지만, 역할과 권한 전반에 걸쳐 보안을 강화하는 중요한 모듈은 반드시 유지해야 합니다.
  • 컨테이너 보안 도구를 활용하세요. 컨테이너 구성을 검사하고 모범 사례와 비교하기 위해 특별히 개발된 도구가 있습니다. 한 가지 예로, 구성에서 수십 가지 지점을 검사하고 모범 사례 규칙에 따라 평가하는 docker-bench-security가 있습니다.

항상 그렇듯이 포괄적인 보안을 위해서는 신중한 서버 구성과 지속적이고 능동적인 서버 관리가 필요합니다.

 

결론

컨테이너화는 인프라 비용을 절감하고, 애플리케이션 롤아웃 프로세스를 가속화하며, 전례 없는 유연성과 확장성을 도입하여 엔터프라이즈 애플리케이션 워크로드를 혁신하고 있습니다.

그러나 컨테이너 내에서 애플리케이션을 실행하면 즉시 눈에 띄지 않을 수 있는 고유한 보안 위험도 발생합니다. Kernel 보안과 패치는 매우 주의 깊게 다루어야 하는 중요한 영역 중 하나입니다.

KernelCare는 컨테이너화된 워크로드를 지원하는 Kernel을 자동으로 업데이트하고, 시스템 재시작과 관련된 중단 및 다운타임 없이 이를 수행할 수 있도록 지원합니다.

Kernel 재부팅, 시스템 다운타임 또는 예정된 유지 보수 기간 없이 취약성 패치를 자동화하고 싶으신가요?

TuxCare로 라이브 패치에 대해 알아보기

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기