Account 로그인
Kubernetes illustration
바로 가기

쿠버네티스 보안을 처리하는 방법

URL 복사

쿠버네티스 보안을 처리하려면 빌드 단계에서 알려진 보안 취약점을 수정하고, 빌드/배포 단계에서 구성 오류를 해결하고, 런타임 시 위협에 대응해야 합니다. 쿠버네티스 및 컨테이너 보안에 관한 최신 현황 리포트를 위해 수집된 응답에 따르면 컨테이너와 관련한 심각한 수준의 보안 문제 중 24%가 사전에 해결할 수 있었던 취약점으로 인한 것이며, 구성 오류가 원인인 경우는 70%에 육박하고, 런타임 보안 인시던트는 27%인 것으로 드러났습니다.

쿠버네티스의 분산된 특성

쿠버네티스오픈소스 컨테이너 오케스트레이션 플랫폼으로, 클러스터로 일괄 처리되는 수백(또는 수천)개의 Linux® 컨테이너를 관리하며 컨테이너화된 마이크로서비스를 연결하는 애플리케이션 프로그래밍 인터페이스(API)에 크게 의존합니다. 분산형 특성으로 인해 어떤 컨테이너취약점이나 구성 오류가 있을 수 있는지, 조직에 큰 리스크가 될 만한 컨테이너는 무엇인지 빠르게 조사하기가 쉽지 않습니다.

이에 대한 해결 방법은 각 컨테이너에서 크리티컬한 시스템 수준 이벤트를 캡처할 수 있는 포괄적인 컨테이너 배포 보기를 개발하는 것입니다.

이미지와 레지스트리의 오용

컨테이너 이미지(베이스 이미지라고도 함)는 새로운 컨테이너를 만들 때 사용되는 변경 불가능한 템플릿입니다. 이러한 템플릿에서 새로 복사된 컨테이너 이미지는 목적에 따라 수정할 수 있습니다.

이 경우 해결 방법은 이미지가 구축되는 방식과 이미지 레지스트리에 저장되는 방식을 결정하는 정책을 설정하는 것입니다. 베이스 이미지는 정기적으로 테스트, 승인, 스캔을 거쳐야 합니다. 또한 쿠버네티스 환경에서 컨테이너를 시작하기 위해서는 허용된 이미지 레지스트리의 이미지만 사용해야 합니다.

제약 없는 컨테이너 통신

제대로 기능하기 위해서는 컨테이너와 포드가 배포 내에서 서로 통신해야 하며, 내부 및 외부 엔드포인트끼리도 통신해야 합니다. 이로 인해 컨테이너에 보안 침해가 발생하는 경우, 해커는 해당 컨테이너가 다른 컨테이너 및 포드와 통신 가능한 범위까지 이동할 수 있게 됩니다. 정책을 수동으로 구성하는 것이 복잡하기 때문에, 계속해서 확장되는 컨테이너 환경에서 네트워크 세그멘테이션을 구현하는 것은 매우 어렵습니다.

이 경우 해결 방법은 네임스페이스, 배포, 포드 사이의 트래픽 이동을 추적하고, 실제 허용되는 트래픽의 양을 정하는 것입니다.

기본 컨테이너 네트워크 정책

기본적으로 쿠버네티스 배포는 쿠버네티스 애플리케이션의 최소 단위인 포드에는 네트워크 정책을 적용하지 않습니다. 이러한 네트워크 정책은 방화벽 룰처럼 작용하며 포드의 통신 방식을 제어합니다. 네트워크 정책이 없다면 포드는 서로 자유롭게 통신할 수 있습니다. 

이 경우 해결 방법은 포드 통신을 정의된 자산으로만 제한하는 네트워크 정책을 정의하고, 암호를 환경 변수로 전달하는 것이 아니라 컨테이너 내 읽기 전용 볼륨으로 마운트하는 것입니다.

컨테이너와 쿠버네티스 컴플라이언스

쿠버네티스가 지원하는 클라우드 네이티브 환경은 다른 IT 환경과 마찬가지로 보안 모범 사례, 업계 표준, 벤치마크, 내부 조직 정책을 준수하고 컴플라이언스를 증명해야 합니다. 이러한 이유로 쿠버네티스 환경이 원래 기존 애플리케이션 아키텍처를 위해 작성된 제어 기능을 충족하도록 컴플라이언스 전략을 조정해야 하는 경우도 있습니다.

이 경우 해결 방법은 컴플라이언스 준수를 모니터링하고 감사를 자동화하는 것입니다.

런타임

쿠버네티스는 변경할 수 없는 인프라입니다. 컨테이너 런타임 중 패치 적용은 불가능하며, 패치를 적용하려면 실행 중인 컨테이너를 제거하고 다시 구축해야 합니다. 손상된 컨테이너는 암호 화폐 채굴 및 포트 스캐닝과 같은 악성 프로세스를 실행할 수 있습니다.

이 경우 해결 방법은 보안 침해가 발생했거나 실행 중인 컨테이너를 제거하고, 손상되지 않은 컨테이너 이미지를 다시 빌드한 다음 재실행하는 것입니다.

강력한 베이스 이미지를 생성하고 취약점 스캐닝 프로세스를 도입하는 등 빌드 단계부터 쿠버네티스 보안을 시작합니다.

  • 최소한의 베이스 이미지 사용. 알 수 없는 취약점을 포함하고 있을 가능성이 있으므로 운영 체제(OS) 패키지 관리자 또는 셸이 있는 이미지를 사용하는 것은 피하거나, 나중에 패키지 관리자를 제거해야 합니다.

  • 불필요한 구성 요소를 추가하지 않음. 기본적으로 일반 툴을 이미지 안에 포함하면 보안 리스크가 발생합니다.

  • 최신 상태의 이미지만 사용. 구성 요소 버전을 업데이트합니다.

  • 이미지 스캐너 사용. 레이어별로 분류된 이미지 내 취약점을 식별합니다.

  • CI/CD 파이프라인에 보안 통합.지속적 통합 빌드에 실패하는 보안의 반복 가능한 패싯(facet)을 자동화하고 심각하지만 수정 가능한 취약점에 대한 알림을 생성합니다.

  • 영구적인 취약점에 라벨 지정. 수정할 수 없거나, 크리티컬이 아니거나, 지금 당장 수정할 필요가 없는 알려진 취약점을 허용 목록에 추가합니다. 

  • 심층 방어 구현. 취약한 이미지를 감지하고 업데이트하기 위해 정책 검사와 문제 해결 워크플로우를 표준화합니다.

워크로드가 배포되기 전 쿠버네티스 인프라 보안을 구성합니다. 이러한 작업은 배포 대상(이미지, 구성 요소, 포드), 배포 위치(클러스터, 네임스페이스, 노드), 배포 방식(권한, 통신 정책, 적용된 보안), 액세스 가능한 항목(암호, 볼륨), 컴플라이언스 표준 등 배포 프로세스를 최대한 파악하는 것에서 시작합니다.

  • 네임스페이스 사용. 워크로드를 네임스페이스로 분리하면 공격을 억제하고, 승인된 사용자의 실수 또는 안전하지 않은 작업으로 인한 영향을 제한할 수 있습니다.

  • 네트워크 정책 사용. 쿠버네티스는 기본적으로 포드 사이 통신을 허용하지만, 네트워크 세그멘테이션 정책으로 이러한 기본값을 무시할 수 있습니다.

  • 암호에 대한 권한 제한. 배포에 필요한 암호만 마운트합니다.

  • 컨테이너 권한 평가. 컨테이너가 그 기능을 수행하는 데 필요한 기능, 역할, 권한만 제공합니다. 

  • 이미지 출처 평가. 알려진 레지스트리의 이미지만 사용합니다.

  • 배포 스캔. 스캔 결과에 따라 정책을 실행합니다. 

  • 라벨과 주석 사용. 배포에 컨테이너화된 애플리케이션을 담당하는 팀의 연락처 정보를 기재한 라벨 또는 주석을 달아 분류를 간소화합니다.

  • 역할 기반 액세스 제어(RBAC) 활성화. RBAC는 클러스터의 쿠버네티스 API 서버에 액세스하기 위한 사용자와 서비스 계정 권한 부여를 제어합니다.

빌드 및 배포 중 사전 예방적인 보안 접근 방식을 적용하면 런타임 시 보안 인시던트가 발생할 확률을 낮출 수 있지만, 런타임 위협을 식별하고 이에 대응하려면 지속적으로 프로세스 활동과 네트워크 통신을 모니터링해야 합니다.

  • 상황별 정보 사용. 의심스러운 활동을 감지하기 위해 쿠버네티스의 빌드와 배포 시간 정보를 사용해 런타임 도중 관찰된 활동과 예상된 활동을 평가합니다.

  • 실행 중인 배포 스캔. 실행 중인 배포를 모니터링하여 컨테이너 이미지에서 최근에 발견된 취약점과 동일한 취약점이 있는지 확인합니다.

  • 기본 제어 기능 사용. 포드의 기능을 제한하기 위한 보안 컨텍스트를 구성합니다.

  • 네트워크 트래픽 모니터링. 실시간 네트워크 트래픽을 관찰하고 비교하여, 쿠버네티스 네트워크 정책이 예기치 않은 통신을 식별하기 위해 어떤 대상을 허용하는지 확인합니다.

  • 허용 목록 사용. 애플리케이션의 일반적인 런타임 과정에서 실행되는 프로세스를 식별해 허용 목록을 생성합니다.

  • 비슷한 방식으로 배포된 포드에서 런타임 활동 비교. 큰 차이점이 있는 복제본은 조사가 필요합니다.

  • 의심스러운 포드를 0으로 조정. 쿠버네티스 네이티브 제어를 사용해 의심스러운 포드를 0으로 자동 조정하거나, 인스턴스를 제거 또는 재시작해 보안 침해를 방지합니다.

보안은 이미지와 워크로드 이상으로 확장됩니다. 보안은 클러스터, 노드, 컨테이너 엔진은 물론 클라우드까지, 전체 쿠버네티스 인프라에 적용되어야 하기 때문입니다.

  • 쿠버네티스 업데이트 적용. 쿠버네티스 배포판을 업데이트하면 보안 패치가 적용되고, 새로운 보안 툴이 설치됩니다.

  • 쿠버네티스 API 서버 구성. 인증되지 않았거나 익명인 액세스는 비활성화하고 Kubelet과 API 서버 간 연결에 TLS 암호화를 사용합니다.

  • etcd 보안 유지. etcd는 쿠버네티스가 데이터 액세스에 사용하는 키-값 저장소입니다. kubelet의 보안을 유지합니다. --anonymous-auth=false 플래그가 있는 Kubelet을 시작해 Kubelet에 대한 익명 액세스를 비활성화하고, NodeRestriction 권한 컨트롤러를 사용해 Kubelet이 액세스할 수 있는 항목을 제한합니다.

클라우드 보안

어떤 유형의 클라우드(퍼블릭 클라우드, 프라이빗 클라우드, 하이브리드 클라우드, 멀티클라우드)가 컨테이너를 호스팅하거나 쿠버네티스를 실행하는지와는 상관없이, 클라우드 사용자(클라우드 공급업체 제외)는 언제나 다음과 같은 쿠버네티스 워크로드의 보안을 책임져야 합니다,

  • 컨테이너 이미지: 소스, 콘텐츠, 취약점

  • 배포: 네트워크 서비스, 스토리지, 권한

  • 구성 관리: 역할, 그룹, 역할 바인딩, 서비스 계정

  • 애플리케이션: 암호 관리, 라벨, 주석

  • 네트워크 세그멘테이션: 쿠버네티스 클러스터의 네트워크 정책

  • 런타임: 위협 감지 및 인시던트 대응

컨테이너와 쿠버네티스를 사용하는 것이 취약점 감소라는 보안 목표에 영향을 주지는 않습니다.

  • 컨테이너 라이프사이클 초기에 보안 포함. 이러한 보안은 개발자와 DevOps 팀이 프로덕션 레디 상태의 애플리케이션을 자신 있게 빌드하고 구축할 수 있도록 지원합니다.

  • 쿠버네티스 네이티브 보안 제어 사용. 네이티브 제어는 보안 제어가 오케스트레이터와 충돌하는 일이 없도록 합니다. 

  • 쿠버네티스가 문제 해결 우선순위를 지정하도록 합니다.

추가 자료

문서

컨테이너와 VM 비교

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

문서

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

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

문서

Linux 컨테이너란?

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

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

제품

Red Hat OpenShift

자동화된 풀스택 오퍼레이션으로 하이브리드 클라우드, 멀티클라우드 및 엣지 배포를 관리하는 엔터프라이즈급 쿠버네티스 컨테이너 플랫폼입니다.

리소스

교육

무료 교육 과정

Running Containers with Red Hat Technical Overview

무료 교육 과정

Containers, Kubernetes and Red Hat OpenShift Technical Overview

무료 교육 과정

Developing Cloud-Native Applications with Microservices Architectures

Illustration - mail

유용한 콘텐츠 더 보기

Red Hat Shares 뉴스레터를 구독해 보세요(무료).

Red Hat logo LinkedInYouTubeFacebookTwitter

제품

구매 정보

커뮤니케이션

Red Hat 소개

Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.

Red Hat Shares 뉴스레터를 구독하세요

지금 신청하기

언어 선택

© 2022 Red Hat, Inc.