Kubernetes illustration
바로 가기

쿠버네티스 네이티브 보안의 장점

URL 복사

컨테이너 보안에 대한 2가지 주요 접근 방식은 컨테이너 중심과 쿠버네티스 네이티브입니다. 

컨테이너 중심 플랫폼은 컨테이너 수준에서 작동하며, 컨테이너 이미지와 컨테이너 런타임의 보안에 중점을 둡니다. 이러한 툴은 예를 들어 인라인 프록시 또는 shim과 같이 컨테이너간 커뮤니케이션을 제어하기 위한 기술을 사용해 컨테이너 수준 자체에서 제어를 제공합니다.

쿠버네티스 네이티브 보안은 쿠버네티스 레이어에서 작동하며 쿠버네티스에서 컨텍스트를 끌어내고 쿠버네티스에서 실행할 정책을 쿠버네티스로 푸시합니다.

쿠버네티스 기반 보안은 쿠버네티스와의 긴밀한 통합에 의존해 컨텍스트를 가져오고, 쿠버네티스의 네이티브 제어를 활용합니다. 이러한 아키텍처는 풍부한 컨텍스트와 인사이트를 제공하고, 쿠버네티스별 위협을 감지하는 2가지 주요 방식으로 보안을 강화합니다.

쿠버네티스 네이티브 보안

클라우드 네이티브 기술은 새로운 보안 과제를 만들어내기도 하지만, 기존 보안 전략을 강화할 수 있게 해주기도 합니다.

쿠버네티스 네이티브 보안은 컨테이너화된 애플리케이션을 관리하는 시스템과 연계될 때 가장 효율적으로 구현된다는 원칙을 기반으로 하고 있습니다. 

보안 플랫폼이 쿠버네티스 네이티브로 간주되려면 다음과 같은 특성을 보여야 합니다.

  • 쿠버네티스 API 서버와 직접 통합해 쿠버네티스 워크로드와 인프라에 대한 직접적인 가시성 확보
  • 쿠버네티스 소프트웨어 자체의 취약점 평가
  • 배포, 네임스페이스, 서비스, 포드 등 쿠버네티스 오브젝트 모델 내 리소스를 기반으로 정책 관리를 포함한 보안 기능 제공
  • 쿠버네티스별 아티팩트(예: 워크로드 매니페스트)와 구성의 선언적 데이터 분석
  • 더 우수한 자동화, 확장성, 안정성을 위해 가능할 때마다 적용을 처리할 빌트인 쿠버네티스 보안 기능 사용
  • 클라우드 네이티브 툴체인의 일반적인 툴을 위한 통합과 지원을 포함한 쿠버네티스 애플리케이션으로 배포 및 실행

쿠버네티스 네이티브 보안을 통해 컨테이너뿐 아니라 쿠버네티스 배포의 구성까지 파악할 수 있습니다. 

워크로드가 격리되어 있는지, 격리되어 있다면 어떻게 격리되어 있는지 파악하는 것도 중요합니다. 쿠버네티스는 기본적으로 네임스페이스 안팎에 존재하는 배포 간 통신을 허용합니다. 네트워크 정책 설정을 심층적으로 파악해, 가급적이면 YAML 파일 텍스트로 표시하기 것보다는 시각적 형식으로 어떤 워크로드가 격리되어 있지 않은지를 강조해서 보여줍니다.

전반적인 보안 상태를 이해하려면 역할 권한, 암호에 액세스, 허용되는 네트워크 트래픽, 컨트롤 플레인 구성 요소의 설정과 같은 쿠버네티스 구성이 잠겨 있는지, 모범 사례를 따르고 있는지, 애플리케이션을 구동하는 데 필요한 최소한의 권한으로 범위가 지정되어 있는지 확인해야 합니다.

다른 컴퓨팅 리소스와 마찬가지로, 많은 조직이 클라우드에서 쿠버네티스를 구동하고 있으며 클라우드에서 쿠버네티스를 구동하는 방법에는 다양한 옵션이 있습니다.

  • 자체 관리형 쿠버네티스
  • 쿠버네티스 상용 배포판
  • 관리형 쿠버네티스 서비스

어떤 모델을 선택하든, 클라우드 공급업체와 함께 배포의 보안을 유지할 책임을 "공유"해야 합니다. 일반적인 책임 공유 모델은 쿠버네티스, 특히 관리형 쿠버네티스 서비스에 적용되지만 보안 책임 소재가 어디인지가 애매하게 느껴질 수도 있습니다.

관리형 쿠버네티스 서비스를 사용하는 경우 클라우드 공급업체는 클러스터를 제어하는 쿠버네티스 요소를 포함하는 쿠버네티스 컨트롤 플레인과 해당 클러스터의 상태 및 구성에 대한 데이터를 관리합니다.

서비스에는 일반적으로 컨트롤 플레인을 설정하고 해당 노드의 이중화를 활성화하는 작업이 포함되며, 클라우드 공급업체의 인프라 일부가 중단된다고 해서 운영이 중단되지 않도록 노드를 각기 다른 지역에서 실행하는 경우도 많습니다.

일반적으로 클라우드 공급업체의 책임은 다음과 같습니다.

  • 쿠버네티스를 최신 상태로 유지
  • 컨트롤 플레인에 최신 패치 적용
  • 노드 OS의 패치 제공(OS별로 상이한 경우가 많음)
  • 종종 노드에 대해 컨테이너 최적화 OS 이미지 제공
  • 가끔 취약점 스캐너도 포함하지만, 스캔 결과에 따라 허용/거부를 결정하는 권한 컨트롤러를 사용하는 등의 정책을 사용자가 직접 생성해야 함

고객에게는 항상 다음과 같은 보안 측면을 비롯해 쿠버네티스 워크로드의 보안을 유지할 책임이 있습니다.

  • 컨테이너 이미지: 소스, 콘텐츠, 취약점
  • 배포: 네트워크 서비스, 스토리지, 권한
  • 구성 관리: 역할, 그룹, 역할 바인딩, 서비스 계정
  • 애플리케이션: 암호 관리, 라벨, 주석
  • 네트워크 세그멘테이션: 클러스터의 네트워크 정책
  • 런타임: 위협 감지 및 인시던트 대응

쿠버네티스 네이티브 보안 플랫폼에는 여러 가지 핵심 장점이 있습니다. 

보호 성능 강화 

쿠버네티스 네이티브 보안은 쿠버네티스의 선언적 데이터를 연결해 쿠버네티스는 물론 컨테이너의 취약점을 발견함으로써 보다 풍부한 인사이트를 제공합니다. 

운영 효율성 향상 

인프라 관리와 보안에 동일한 프레임워크를 사용하여 쿠버네티스에 익숙해지는 데 걸리는 시간을 줄이고, 쿠버네티스 컨텍스트로 더 빠르게 위협을 감지하고 중요도가 높은 리스크를 평가합니다.

운영 리스크 감소 

쿠버네티스의 기본 제어를 활용하면 쿠버네티스의 속도와 확장성을 갖춘 보안을 구현할 수 있습니다. 쿠버네티스에 정책이 포함되어 있다는 것은 외부 제어와 오케스트레이터 사이에 충돌이 없음을 의미합니다.

쿠버네티스 네이티브 보안은 일관성 없는 구성, 조정 부족, 사용자 오류로 인한 운영 문제를 줄이는 데 도움이 됩니다.

대부분의 사용자가 쿠버네티스에 익숙해지는 시간을 감안할 때, 쿠버네티스 역할 기반 액세스 제어(RBAC)를 사용해 더 높은 권한을 부여하는 것과 같은 실수를 하기 쉽습니다. 예를 들어 사용자 또는 서비스 계정에 완전한 클러스터 관리 권한을 부여한다거나, 필요한 경우가 아닌데도 배포에서 암호를 끌어오도록 허용해 쿠버네티스 암호를 불필요하게 노출하는 등의 사례가 있습니다.

쿠버네티스 네이티브 보안 플랫폼은 이러한 구성 오류를 지속적으로 자동 식별합니다.

쿠버네티스에 직접 보안 제어를 포함하면 장애 발생 시 보안을 적용하지 않고 모든 트래픽을 허용하는 페일 오픈(fail open) 또는 모든 애플리케이션 트래픽을 차단하고 중단하는 페일 클로즈(fail close) 상태를 유지하는 별도의 제어 소프트웨어로 인한 리스크도 사라집니다.

쿠버네티스 오케스트레이터가 정책 제어를 실행하도록 하면 보안에 쿠버네티스 자체의 확장성과 이를 포함하는 정책 실행 옵션 범위가 즉시 추가될 수 있습니다. 

반면에 인라인 프록시 또는 Shim을 사용하여 실행하면 단일 장애 지점, 확장성 문제, 성능 제한과 같은 문제가 발생합니다.

예를 들어 쿠버네티스를 사용하면 네트워크 정책을 적용해 트래픽을 분할하고, 권한 컨트롤러를 사용해 쿠버네티스 API 서버로 이동하는 요청에 정책을 적용하고, 민감한 자격 증명을 저장하기 위해 암호를 사용하고, 역할 기반 액세스 제어(RBAC)를 적용해 특정 사용자 및 서비스 계정에 특정 기능을 승인할 수 있습니다.

또한 컨테이너 네트워크 인터페이스(CNI)를 준수하는 네트워크 플러그인을 비롯해 추가로 표준화된 툴을 쿠버네티스 네이티브 보안 플랫폼과 함께 사용하고, 필요에 따라 이러한 추가 툴을 변경할 수도 있습니다.

쿠버네티스는 인프라 서비스의 프로비저닝과 운영을 위한 단일 통합 플랫폼을 제공하여 애플리케이션 개발과 운영 팀 전반의 워크플로우를 간소화하고 통합합니다. 

누구나 공통 정보 소스(SOT)에서 작업하고 동일한 인프라를 사용하는 그러한 통합 접근 방식은 쿠버네티스 네이티브 보안 플랫폼을 배포하는 경우 보안으로 확장할 수도 있습니다. 

이러한 접근 방식은 사용에 익숙해지는 데 걸리는 시간을 줄여 주어, 더 빠르게 분석하고 문제를 해결할 수 있으므로 시간과 비용이 절약됩니다.

DevOps와 보안 팀이 각기 다른 툴을 사용하는 경우 구성 방식에서 충돌이 발생하기 쉽습니다. 

예를 들어 DevOps 팀은 두 노드 사이의 트래픽을 허용하는 쿠버네티스 네트워크 정책을 지정하고, 보안 팀은 해당 트래픽을 차단하는 별도의 제어 소프트웨어를 통해 제어하는 경우가 있습니다.

DevOps 팀은 쿠버네티스의 설정을 확인해 해당 애플리케이션이 트래픽 흐름과 함께 작동해야 한다는 점을 알 수 있습니다. 하지만 별도의 제어 소프트웨어에서 수행하는 제어는 확인할 수 없기 때문에 애플리케이션에 장애가 발생하는 이유를 파악하지 못합니다.

DevOps와 보안 팀이 컨테이너화된 애플리케이션을 구축하고 제공하며 보안을 유지하는 데 같은 구문을 사용하면 두 팀이 알아야 할 인터페이스, 툴, 모델이 줄어듭니다. 

DevOps 팀은 쿠버네티스 매니페스트 파일을 사용해 지정된 애플리케이션에서 필요로 하는 리소스를 정의합니다. 동일한 자산을 사용해 보안 컨텍스트를 수집하고 정책을 적용하면 복잡성이 줄어들어 보안 성과가 개선됩니다. 

쿠버네티스 네이티브 보안은 쿠버네티스를 보안 정책의 정보 소스(SOT)로 취급하며 보안, 운영, DevOps, 사이트 신뢰성 엔지니어링(SRE) 팀까지 모두가 해당 소스에서 작업하게 됩니다. 

뿐만 아니라, 보안 문제가 이러한 팀이 매일 사용하는 쿠버네티스 오브젝트와 리소스로 직접 매핑되어 운영을 더욱 간소화합니다.

보안 정책에 쿠버네티스 네이티브를 적용해 별도의 보안 소프트웨어를 구현하는 데 따른 운영 리스크를 방지하세요.

컨테이너는 인시던트를 다양하게 분산시키고, 처리해야 할 대용량 데이터를 생산하며, 일시적이라 기존 인시던트 대응을 쓸모없게 만들기 때문에 클라우드 네이티브 애플리케이션의 여러 가지 측면에서 보안을 복잡하게 만듭니다.

쿠버네티스 네이티브 보안을 사용하면 컨테이너에 대한 위협을 더 정확히 감지하고, 환경에 보안을 효과적으로 적용하는 데 필요한 시간과 노력을 절감할 수 있습니다.

쿠버네티스 컨텍스트 사용의 기대 효과는 명확합니다. 결과적으로 쿠버네티스 네이티브 보안은 이상 징후를 더욱 상세히 파악할 수 있기 때문에 사용자는 포드 폐기와 같은 실행 옵션을 더욱 자신 있게 적용할 수 있습니다.

쿠버네티스 컨텍스트를 사용하면 오탐과 알림으로 인한 피로도 줄어듭니다.

또한, 쿠버네티스 네이티브 보안은 보안 태스크에 리스크 기반 접근 방식을 적용할 수 있게 해줍니다. 

배포에 여러 가지 정책 위반이 포함될 가능성이 크다면, 어디서부터 시작하는 것이 좋을까요? 이때도 쿠버네티스 컨텍스트가 도움이 됩니다. 

클러스터가 어떤 상태(개발 또는 프로덕션)에 있는지, 인터넷에 노출되어 있는지, 애플리케이션이 어느 정도로 중요한지, 의심스러운 프로세스가 실행 중인지 등 쿠버네티스 메타데이터의 다양한 측면을 결합하면 현재 팀이 어떤 부분에 집중해야 하는지 파악할 수 있습니다. 

특히 쿠버네티스 API 서버에 위협이 되는 쿠버네티스별 취약점을 감지하는 것은 방지, 식별, 해결에 매우 중요합니다. 쿠버네티스 네이티브 보안 툴링은 이러한 취약점을 자동으로 식별할 수 있습니다.

쿠버네티스 API 서버와 통합하면 쿠버네티스 클러스터에서 실행 중인 컨테이너는 물론 배포, 데몬 세트, 서비스, 포드, 기타 리소스와 같은 쿠버네티스 리소스에도 보안 모니터링이 제공됩니다.

쿠버네티스 배포의 광범위한 특성 때문에 또 다른 위협이 발생할 수도 있습니다. 쿠버네티스는 무엇보다도 인프라 운영 위한 플랫폼이므로, 좀 더 손쉽게 운영할 수 있도록 모든 구성 요소에 기본적으로 보안이 적용되어 있지는 않습니다. 

쿠버네티스 배포 보안을 위한 또 다른 필수적인 요소는 쿠버네티스 네트워크 정책을 적용해 통신을 제한하는 것입니다. 쿠버네티스 네이티브 보안 플랫폼은 자동으로 네트워크 활동의 기준을 설정하고, 애플리케이션을 서비스하는 데 어떤 통신 경로가 필요한지 파악하고, 올바른 YAML 파일을 생성해 네트워크 액세스 범위를 줄입니다.

이러한 쿠버네티스 네이티브 플랫폼의 자동 보안 설정을 통해 쿠버네티스 레이어에서 지속적으로 위협을 식별하고 차단할 수 있습니다.

 

쿠버네티스 네이티브 보안은 이식성과 재활용성 또한 탁월합니다. 쿠버네티스가 실행되는 모든 곳에서 표준화된 단일 접근 방식을 사용하면 해당 정책이 모든 환경에 일관되게 적용됩니다. 

쿠버네티스 네이티브 보안은 사용자가 클러스터의 모든 호스트에 대해 시스템 수준의 제어를 구성하는 것이 아닌, 네트워크 정책과 같이 배포의 모든 포드에 적용할 단일 구성을 지정하도록 합니다. 

조직은 정책을 CI/CD 시스템과 쿠버네티스 권한 컨트롤러 프레임워크에 연결해 소프트웨어 개발 라이프 사이클 초기에 손쉽게 제어 정책을 적용하고 런타임 시 위험에 노출될 가능성을 방지할 수 있습니다. 

또한, 권한 컨트롤러와 같은 쿠버네티스 구문을 활용하면 보안과 쿠버네티스 툴체인의 긴밀한 연결을 유지할 수도 있습니다.

추가 자료

문서

컨테이너와 VM 비교

Linux 컨테이너 및 VM(가상 머신)은 다양한 IT 요소를 결합해 시스템의 나머지 부분으로 부터 격리하는 패키징된 컴퓨팅 환경입니다.

문서

컨테이너 오케스트레이션이란?

컨테이너 오케스트레이션은 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화합니다.

문서

Linux 컨테이너란?

Linux 컨테이너는 시스템에서 격리된 프로세스로, 이러한 프로세스를 지원하는 데 필요한 모든 파일을 제공하는 고유한 이미지에서 실행됩니다.

컨테이너에 대한 자세한 내용

제품

선택한 인프라에서 애플리케이션 출시 테스트를 완료한 통합 서비스 세트를 포함하는 엔터프라이즈 애플리케이션 플랫폼입니다.

리소스

교육

무료 교육 과정

Running Containers with Red Hat Technical Overview

무료 교육 과정

Containers, Kubernetes and Red Hat OpenShift Technical Overview

무료 교육 과정

Developing Cloud-Native Applications with Microservices Architectures