컨테이너와 쿠버네티스(K8s)가 점점 대중화됨에 따라 IT 환경이 빠르게 변하고 있습니다. 우리는 불과 7년 만에 가상 머신에서 컨테이너로, 다시 컨테이너 오케스트레이션 플랫폼(최초의 Docker 릴리스는 2013년 출시)으로 옮겨 갔습니다. 일부 스타트업은 이러한 새 리소스를 활용할 방법을 아직 연구 중이고, 그보다 먼저 자리 잡은 기업에서는 레거시 시스템을 보다 효율적인 인프라로 마이그레이션할 방법을 모색 중입니다.

컨테이너와 쿠버네티스의 빠른 도입은 이것이 얼마나 혁신적인 기술이었는지를 보여 주지만, 동시에 새로운 보안 문제를 일으키기도 했습니다. 컨테이너화와 쿠버네티스는 이렇게 인기가 높았던 반면 많은 조직이 적절한 보안 조치를 갖추지 못했기 때문에 공격자들의 완벽한 표적이 되었습니다.

K8s 클러스터는 마스터 노드(및 복제본)에서 관리하는 시스템의 집합입니다. 수천에 달하는 컴퓨터와 서비스가 이 클러스터에 포함될 수 있으며, 따라서 주요 공격 벡터가 될 수 있습니다. 그러므로 반드시 엄격한 보안 관행을 도입해야 합니다.

클러스터 보안

쿠버네티스 클러스터에는 움직이는 부분이 많이 있기 때문에 반드시 적절한 보안 조치를 취해야 합니다. 물론 클러스터의 보안은 단일 프로세스로 실현할 수 없습니다. 전체 클러스터의 보안을 보장하려면 다양한 모범 사례와 함께 유능한 보안 팀이 필요합니다.

지금부터 다양한 쿠버네티스 공격 벡터를 알아보고 K8s 클러스터의 보안을 유지하기 위한 권장 사항을 소개하겠습니다.

쿠버네티스 및 해당 노드를 최신 상태로 유지

K8s는 지속적으로 업데이트되는 오픈 소스 시스템입니다. 여기에 사용되는 GitHub 리포지토리는 이 플랫폼에서 가장 활발한 리포지토리 중 하나이며, 따라서 새로운 기능, 개선 사항 및 보안 업데이트가 계속해서 도입됩니다.

4개월마다 쿠버네티스 주 버전이 새로 공개됩니다. 각각의 새 버전에는 새로운 서비스 개선 기능이 포함되어 있지만, 새로운 보안 문제나 버그도 있을 수 있습니다. 특히 자주 업데이트되는 소프트웨어는 모두 취약합니다.

그러나 보안 침해는 이전 버전에서도 발견될 수 있습니다. 따라서 쿠버네티스 팀이 이전 버전의 보안 업데이트를 어떻게 수행하고 있는지를 반드시 파악해야 합니다. Linux 배포 또는 기타 플랫폼과 달리 쿠버네티스에는 LTS 버전이 없습니다. 오히려 쿠버네티스 시스템은 보안 문제를 가장 최근에 출시된 세 가지 주요 버전에 백포트하려고 시도합니다.

따라서 클러스터를 세 가지 최신 주 버전 중 하나로 유지하고, 보안 패치를 지속적으로 적용하고, 최소 12개월마다 최신 주 버전 업데이트를 계획해야 합니다.

쿠버네티스는 기본 구성 요소 외에 클러스터에 할당된 워크로드를 실행하는 노드도 처리합니다. 이러한 노드는 운영 체제를 실행 중인 물리적 머신 또는 가상 머신일 수 있습니다. 각 노드는 잠재적 공격 벡터이며, 보안 문제를 해결하기 위해 업데이트가 필요합니다. 따라서 공격 표면을 줄이려면 이 노드를 최대한 깨끗하게 유지해야 합니다.

사용자 액세스 제한

RBAC(역할 기반 액세스 제어)는 클러스터 액세스를 허용할 사용자와 액세스 방식을 제어하는 가장 좋은 방법 중 하나입니다. 세분화된 권한 집합을 통해 각 사용자의 권한을 정의할 수 있습니다. 규칙은 항상 추가되므로 모든 권한을 명시적으로 설정해야 합니다. RBAC에서는 Pod(가장 작은 K8s 컴퓨팅 단위)부터 네임스페이스까지 각 쿠버네티스 개체에 대한 액세스 권한(보기, 읽기 또는 쓰기)을 제한할 수 있습니다.

OpenID 연결 토큰을 사용하여 RBAC를 다른 디렉터리 서비스에 연결할 수도 있습니다. 이렇게 하면 사용자 및 그룹 관리를 중앙 집중식으로 정의하고 조직 내에서 좀 더 광범위하게 사용할 수 있습니다.

액세스 권한은 쿠버네티스에만 국한되지 않습니다. 예를 들어, 사용자가 문제를 식별하기 위해 클러스터 노드에 액세스해야 하는 경우가 있습니다. 이 경우 임시 사용자를 만들고 문제가 해결되면 삭제하는 것이 좋습니다.

컨테이너 모범 사례

가장 주목할 만한 컨테이너 기술인 Docker는 계층으로 구성됩니다. 가장 안쪽 계층이 가장 기본적인 구조이고, 바깥쪽은 특정 계층입니다. 따라서 모든 Docker 이미지는 일종의 배포 또는 언어 지원으로 시작되며, 각각의 새 계층에서 이전 기능을 추가하거나 수정하면서 마지막 계층까지 이어집니다. 그러므로 애플리케이션 가동에 필요한 모든 것이 컨테이너에 들어 있어야 합니다.

이러한 계층(이미지라고도 함)은 Docker Hub에서 공개적으로 제공되거나 별도의 이미지 레지스트리에서 비공개로 제공됩니다. 이미지는 두 가지 형식으로 표현할 수 있습니다. 하나는 이름과 레이블(예: node:latest)이고, 다른 하나는 변경 불가능한 SHA 식별자(예: 작성 시점에 동일한 이미지의 식별자는 sha256:d64072a554283e64e1bfeb1bb457b7b293b6cd5bb61504afaa3bdd5da2a7bc4b) 입니다.

레이블과 연결된 이미지는 리포지토리 소유자가 언제든지 변경할 수 있습니다. 따라서 최신 태그는 사용 가능한 최신 버전을 나타내며, 또한 새 이미지를 만들거나 태그가 있는 이미지를 실행할 때 내부 계층이 예고 없이 갑자기 변경될 수 있음을 의미합니다.

물론 이 전략에는 몇 가지 문제가 있습니다. (1) 상위 계층이 업데이트되면서 충돌이 추가로 발생하는 경우 쿠버네티스 인스턴스에서 실행 중인 항목을 제어할 수 없습니다. (2) 이미지를 고의로 수정하여 보안 침해를 유도할 수 있습니다.

첫 번째 문제를 방지하려면 최신 태그를 사용하지 말고 보다 구체적인 버전의 태그(예: node:14.5.0)를 선택하세요. 두 번째 문제를 방지하려면 공식 이미지를 선택하거나, 이미지를 비공개 리포지토리에 복제하거나, SHA 값을 사용하세요.

또 다른 방식은 사용된 이미지를 취약성 감지 도구로 지속적으로 스캔하는 것입니다. 지속적 통합 파이프라인과 함께 실행되는 이러한 도구로 이미지 리포지토리를 모니터링하여 이전에 감지되지 않은 문제를 식별할 수 있습니다.

새 이미지를 만들 때는 이미지당 서비스 하나만 포함해야 한다는 점에 유의하세요. 해당 애플리케이션에 필요한 종속성만 포함하고 다른 것은 포함하지 않도록 전체 이미지를 빌드해야 합니다. 그러면 공격 표면이 서비스에 필수적인 구성 요소로 국한됩니다. 이미지당 애플리케이션이 한 개면 새 버전으로 업데이트하고 오케스트레이터에서 리소스를 할당하기가 더 쉽습니다.

네트워크 보안

이전 섹션에서는 공격 표면을 줄이는 방법을 집중적으로 다루었는데, 이는 네트워킹에도 동일하게 적용됩니다. 쿠버네티스는 클러스터 내부에 가상 네트워크가 있습니다. 이 가상 네트워크에서는 Pod 간 액세스를 제한하거나 외부 액세스를 제한하여 허용되는 서비스에만 접근하도록 할 수 있습니다. 소규모 클러스터에서는 이러한 기본 솔루션이 잘 작동합니다.

그러나 서로 다른 팀에서 개발한 여러 서비스가 포함된 대규모 클러스터는 훨씬 더 복잡하며, 중앙 집중적인 관리가 불가능할 수 있습니다. 이 경우 현재 사용할 수 있는 가장 좋은 방법은 서비스 메시입니다. 서비스 메시는 서비스와 서비스가 서로 안전하게 통신할 수 있도록 네트워크 암호화 계층을 만듭니다. 이 메시는 대개 각 Pod에 붙어 있는 사이드카 에이전트로 작동하면서 서비스 간의 통신을 담당합니다. 서비스 메시는 보안만을 위한 것이 아니라 서비스 검색, 모니터링/추적/로깅도 지원하며, 회로 차단 패턴을 적용하는 등 서비스 중단을 방지하기도 합니다.

리소스 할당량 설정

애플리케이션은 항상 업데이트되며 보안 침해의 위험은 상존하므로 위와 같은 조치만으로는 클러스터 보안을 보장하기 어렵습니다.

리소스 할당량을 설정하여 중단 시 쿠버네티스가 정해진 제약 조건까지만 지원하도록 하는 것도 중요한 방법입니다. 제약 조건을 잘 설계하면 리소스 고갈로 인해 모든 클러스터 서비스를 사용할 수 없게 되는 사태를 방지할 수 있습니다.

또한 월말에 엄청난 클라우드 청구서가 쌓이지 않게 할 수도 있습니다.

모니터링 및 로깅

중단 상태를 발견하고 원인을 정확히 찾아내려면 반드시 클러스터에서 Pod까지 전체적으로 모니터링해야 합니다. 비정상적인 행동을 감지하는 것이 가장 중요합니다. 네트워크 트래픽이 증가했거나 노드의 CPU가 평소와 다르게 작동하는 경우, 추가 조사를 통해 문제를 가려내야 합니다. CPU, 메모리, 네트워킹 같은 지표는 모니터링을 통해 알아보고, 비정상적인 패턴을 감지하거나 문제의 원인을 신속하게 식별하는 데 도움이 되는 추가(이력) 정보는 로깅에서 얻을 수 있습니다.

Prometheus와 Graphana를 결합하면 효과적인 쿠버네티스 모니터링 도구가 됩니다. Prometheus는 고성능 시계열 데이터베이스이고, Graphana는 Prometheus 데이터를 쉽게 읽고 볼 수 있는 그래픽 대시보드입니다.

애플리케이션, 노드 및 쿠버네티스 자체를 거의 실시간으로 중앙에서 로깅하는 ElasticSearch 역시 유용하고 인기 있는 도구 중 하나입니다.

보안 측면에서 비교한 클라우드와 온프레미스

쿠버네티스는 온프레미스에 설치할 수도 있고, 클라우드 관리 서비스를 사용할 수도 있습니다. 온프레미스 시나리오에서는 모든 구성(새 컴퓨터 가동, 네트워킹 설정 및 애플리케이션 보안)을 수동으로 배포해야 합니다. Google GKE, AWS EKS 또는 Azure AKS와 같은 클라우드 관리형 서비스를 사용하면 K8s를 최소한의 구성으로 설치할 수 있으며, 클라우드 공급업체의 다른 서비스와도 호환됩니다.

보안 측면에서 볼 때, 온프레미스 솔루션에는 훨씬 더 많은 주의를 기울여야 합니다. 앞서 설명했듯이 모든 새 업데이트를 시스템에서 다운로드하여 구성해야 하고, 노드도 업데이트해야 합니다. 따라서 온프레미스 쿠버네티스는 숙련된 팀이 배포하는 것이 좋습니다.

반면 클라우드 관리 서비스를 사용하면 쿠버네티스가 이미 설치되어 있고 클라우드 공급업체가 모든 노드를 최신 보안 기능으로 업데이트해 주기 때문에 일이 훨씬 간단해집니다. 클러스터 기준으로 보면, 대부분의 클라우드 공급업체에서는 K8s 버전 모음 중 원하는 버전을 사용자가 직접 선택할 수 있고 이를 새 버전으로 업데이트할 수도 있습니다. 따라서 훨씬 간단하지만 유연성은 다소 떨어집니다.

최종 참고 사항

업데이트가 계속되고 새로운 도구도 끊임없이 출시되기 때문에 최신 상태를 유지하고 취약점을 계속해서 파악하기가 어려울 수 있습니다. 보안 침해는 피할 수 없습니다. 쿠버네티스는 단순한 도구가 아니므로 문제가 훨씬 더 큽니다. 쿠버네티스는 다른 도구, 컴퓨터 및 네트워크를 관리하는 도구의 모음이므로 보안이 필수입니다.

그러나 움직이는 부분이 너무 많기 때문에 쿠버네티스의 보안 유지는 결코 쉽지 않습니다. 다음 지침을 반드시 준수해야 합니다.

K8s에서 실행되는 애플리케이션의 보안 문제를 스캔합니다.
액세스를 제한 및 제어합니다.
모든 것이 최신 보안 업데이트로 패치되었는지 확인하고, 지속적으로 클러스터를 모니터링하면서 중단 사태를 즉시 해결하고 손상을 완화합니다.

온프레미스 배포에서는 실제 하드웨어를 관리해야 하고, 자동화를 만들어야 하며, 업데이트할 소프트웨어도 더 많기 때문에 상황이 훨씬 더 어렵습니다. 그러나 여기 설명된 모범 사례에 따라 주요 보안 이점을 활용하면 쿠버네티스 환경을 안전하게 실행할 수 있습니다.

SentinelOne 플랫폼은 물리적 머신과 가상 머신, Docker, 자체 관리형 쿠버네티스 및 AWS EKS 등 클라우드 서비스 공급업체에서 관리하는 쿠버네티스를 지원합니다. 자세히 알아보려면 지금 무료 데모를 요청하세요.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

쿠버네티스 보안 과제, 위험 및 공격 벡터