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

컨테이너 보안에 대한 주요 접근 방식으로는 컨테이너 중심과 쿠버네티스 네이티브 등 두 가지가 있습니다. 

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

쿠버네티스 네이티브 보안은 쿠버네티스 계층에서 작동하며, 쿠버네티스에서 컨텍스트를 도출해 쿠버네티스가 시행할 정책을 쿠버네티스로 푸시합니다.

쿠버네티스 네이티브 보안은 쿠버네티스와의 긴밀한 통합을 통해 컨텍스트를 가져오고 쿠버네티스의 네이티브 제어를 활용합니다. 이러한 아키텍처는 풍부한 컨텍스트와 인사이트를 제공하고 쿠버네티스 관련 위협을 감지하는 두 가지 주요 방식으로 보안을 개선합니다.

쿠버네티스 네이티브 보안은 컨테이너화된 애플리케이션을 관리하는 시스템에 맞게 조정될 때 보안이 가장 효과적으로 구현된다는 원칙에 기반합니다. 

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

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

쿠버네티스 네이티브 보안은 컨테이너뿐만 아니라 쿠버네티스 배포의 구성에 대한 가시성을 제공합니다. 

워크로드의 격리 방법 또는 여부를 이해하는 것도 중요합니다. 기본적으로 쿠버네티스는 네임스페이스 안과 밖에서 모든 배포들 간의 통신을 허용합니다. YAML 파일의 텍스트를 읽는 것보다 시각적 형식으로 네트워크 정책 설정을 심층적으로 파악하면 어떤 워크로드가 격리되지 않았는지 명확하게 확인할 수 있습니다.

전체적인 보안 상태를 파악하려면 역할 권한, 암호 액세스, 허용된 네트워크 트래픽, 컨트롤 플레인 구성 요소의 설정 등과 같은 쿠버네티스 구성이 사용 제한되고 모범 사례를 따르며 애플리케이션 실행에 필요한 최소한의 권한으로 범위가 제한되어야 합니다.

빌드에서 배포와 실행까지 컨테이너를 보호하는 방법 알아보기

다른 컴퓨팅 리소스의 경우와 마찬가지로 많은 조직이 쿠버네티스를 클라우드에서 실행합니다. 쿠버네티스를 클라우드에서 실행하는 방법에는 여러 옵션이 있습니다.

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

어떤 모델을 선택하든 조직과 클라우드 공급업체는 배포를 보호하는 책임을 '공유'합니다. 일반적인 책임 공유 모델은 쿠버네티스, 특히 관리형 쿠버네티스 서비스를 통해 적용되지만 보안 책임 측면에서 그 경계가 어디인지 혼란스럽게 느껴질 때가 있습니다.

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

서비스에는 일반적으로 컨트롤 플레인 설정이 포함되어 해당 노드의 중복성을 활성화합니다. 여기에는 클라우드 공급업체 인프라의 일부가 다운될 경우 서비스 장애를 방지하기 위해 노드를 여러 지역에서 실행하는 것이 종종 포함됩니다.

일반적으로 클라우드 공급업체는 다음을 수행합니다.

• 쿠버네티스를 최신 상태로 유지합니다.
• 컨트롤 플레인을 패치 적용 상태로 유지합니다.
• 노드 OS의 패치를 적용할 수 있습니다. OS에 따라 다를 수 있습니다.
• 종종 컨테이너에 최적화된 노드용 OS 이미지를 제공합니다.
• 취약점 스캐너를 기본 제공하는 경우가 있지만 조직이 직접 정책(예: 권한 컨트롤러를 사용하여 스캐닝 결과에 따라 허용/거부)을 만들어야 합니다.

고객은 항상 다음과 같은 보안 측면을 포함하여 쿠버네티스 워크로드를 보호할 책임이 있습니다.

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

SPIFFE와 SPIRE란?

쿠버네티스 네이티브 보안 플랫폼의 주요 장점은 다음과 같습니다. 

보안 강화 

쿠버네티스 네이티브 보안은 쿠버네티스의 선언적 데이터와 연계하여 더욱 풍부한 인사이트를 제공해 쿠버네티스는 물론, 컨테이너에서 취약점을 발견합니다. 

운영 효율성 향상 

인프라 관리와 보안에 동일한 프레임워크를 사용하여 쿠버네티스 러닝 커브를 단축하며, 쿠버네티스 컨텍스트를 통해 더욱 신속하게 위협을 감지하고 리스크 평가의 우선순위를 지정할 수 있습니다.

운영 리스크 감소 

쿠버네티스의 네이티브 제어 기능을 활용함으로써 쿠버네티스의 속도와 확장성에 맞는 보안을 확보할 수 있습니다. 쿠버네티스에 정책이 포함되어 있으므로 외부 제어와 오케스트레이터 간 충돌이 없습니다.

쿠버네티스 네이티브 보안은 일관되지 않은 구성, 조정 부족, 사용자 오류 등에서 비롯되는 운영 문제를 줄이는 데 도움이 됩니다.

대부분 사용자의 쿠버네티스 러닝 커브를 고려해 볼 때 사용자 또는 서비스 계정에 전체 클러스터 관리 권한을 제공하는 것과 같이 쿠버네티스 역할 기반 액세스 제어(RBAC)를 사용하여 향상된 권한을 부여하거나 배포를 통해 불필요한 암호까지 가져와 쿠버네티스 암호를 노출하는 등의 실수를 저지르기 쉽습니다.

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

보안 제어를 쿠버네티스에 직접 임베드하면 별도의 제어 소프트웨어를 사용하여 장애 발생 시 페일 오픈(fail open)해 활성화된 보안이 없는 상태에서 모든 트래픽이 허용되거나 페일 클로즈(fail closed)해 모든 애플리케이션 트래픽이 중단되는 위험도 제거됩니다.

쿠버네티스 오케스트레이터를 통해 정책 제어를 시행하면 보안이 쿠버네티스 자체의 모든 확장성은 물론, 쿠버네티스에 포함된 정책 시행 옵션의 범위를 즉시 확보하게 됩니다. 

반대로 시행을 위해 인라인 프록시 또는 심을 사용하면 단일 장애 지점, 확장성 문제, 성능 제한 등이 발생합니다.

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

또한 Container Network Interface(CNI)를 준수하는 네트워크 플러그인과 같은 추가적인 표준화된 툴을 쿠버네티스 네이티브 보안 플랫폼과 함께 사용하고 필요한 경우 그러한 추가적인 툴을 변경할 수 있습니다.

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

모두가 공통된 진실 공급원을 기반으로 작업하고 동일한 인프라를 사용하는 바로 그 통합 접근 방식은 쿠버네티스 네이티브 보안 플랫폼을 배포할 때 보안에도 확장될 수 있습니다. 

이러한 접근 방식은 러닝 커브를 단축하고 분석과 문제 해결 시간을 앞당겨 시간과 비용을 절약합니다.

DevOps 팀과 보안 팀이 서로 다른 툴을 사용하면 구성 방식에서 충돌이 발생하기 쉽습니다. 

DevOps 팀의 경우 2개의 노드 간 트래픽을 허용하는 쿠버네티스 네트워크 정책을 지정할 수 있고 보안 팀은 해당 트래픽을 차단하는 별도의 제어 소프트웨어를 통해 제어를 도입할 수 있습니다.

쿠버네티스의 설정을 살펴보면 DevOps 팀은 애플리케이션이 트래픽 흐름에 따라 작동해야 한다는 것을 알 수 있습니다. 그런데 별도의 제어 소프트웨어에서 실행하는 제어를 볼 수 없으므로 애플리케이션의 장애 원인을 쉽게 파악할 수 없습니다.

DevOps 팀과 보안 팀이 동일한 구조를 사용해 컨테이너화된 애플리케이션을 빌드 및 제공하고 보호하면 익혀야 할 인터페이스, 툴, 모델이 줄어듭니다. 

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

쿠버네티스 네이티브 보안은 쿠버네티스를 보안 정책의 진실 공급원으로 취급하며, 보안 팀, 운영 팀, DevOps 팀, 사이트 신뢰성 엔지니어링(SRE) 팀 등 모두가 동일한 진실 공급원을 기반으로 작업할 수 있습니다. 

또한 보안 문제가 이러한 팀들이 매일 사용하는 쿠버네티스 객체 및 리소스에 직접 매핑되므로 운영이 더욱 간소화됩니다.

보안 정책에 쿠버네티스 네이티브 시행을 적용하여 별도의 보안 소프트웨어를 구현하는 데서 발생하는 운영 리스크를 방지하세요.

컨테이너는 클라우드 네이티브 애플리케이션의 보안을 여러 측면에서 복잡하게 만듭니다. 인시던트가 매우 광범위하게 발생할 수 있고, 컨테이너는 처리해야 할 대량의 데이터를 생산하며, 컨테이너는 일회성이어서 기존의 인시던트 대응 방식이 더 이상 쓸모없게 된다는 사실이 그 예입니다.

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

쿠버네티스 컨텍스트에서는 예상되는 동작이 분명합니다. 그 결과 쿠버네티스 네이티브 보안을 통해 이상 징후를 고도로 정밀하게 식별할 수 있고, 포드 종료와 같은 시행 옵션을 더 자신 있게 적용할 수 있습니다.

동시에 쿠버네티스 컨텍스트 사용은 오탐과 경고 피로를 줄여줍니다.

또한 쿠버네티스 네이티브 보안을 사용하면 리스크 기반의 보안 태스크 접근 방식을 사용할 수 있습니다. 

배포에는 수많은 정책 위반 사항이 포함될 가능성이 높습니다. 그런데 어디서부터 시작해야 할까요? 다시 말씀드리지만 쿠버네티스 컨텍스트를 활용하는 것이 도움이 됩니다. 

클러스터가 개발 단계인지 또는 프로덕션 단계인지 여부, 클러스터가 인터넷에 노출됐는지 여부, 애플리케이션의 중요도, 의심되는 프로세스가 현재 애플리케이션에서 실행되고 있는지 여부 등 쿠버네티스 메타데이터의 다양한 측면을 결합하면 지금 당장 팀의 주의가 필요한 부분이 무엇인지 알 수 있습니다. 

쿠버네티스 관련 취약점, 특히 쿠버네티스 API 서버를 위험에 노출시키는 취약점을 감지하는 것은 특히 문제의 예방, 식별, 해결에 매우 중요합니다. 쿠버네티스 네이티브 보안 툴링은 이러한 취약점을 자동으로 식별할 수 있습니다.

쿠버네티스 API 서버와의 통합은 쿠버네티스에서 실행되는 컨테이너와 배포, 데몬 세트, 서비스, 포드, 기타 리소스 등과 같은 쿠버네티스 리소스에 대한 보안 모니터링을 제공합니다.

쿠버네티스 배포의 매우 개방적인 특성으로 인해 또 다른 위협 벡터가 도입될 수 있습니다. 쿠버네티스는 무엇보다도 인프라 운영을 위한 플랫폼이므로 운영 편의성을 추구하기 때문에 모든 구성 요소가 기본적으로 항상 안전한 것은 아닙니다. 

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

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

쿠버네티스 네이티브 보안은 높은 이식성과 재사용을 지원합니다. 쿠버네티스가 실행되는 모든 곳에서 실행되는 표준화된 단일 접근 방식을 따르면 정책이 모든 환경에서 일관되게 적용됩니다. 

쿠버네티스 네이티브 보안 사용자는 클러스터의 모든 호스트에서 시스템 수준의 제어를 구성할 필요 없이 배포에 포함된 모든 포드에 적용해야 하는 단일 구성(예: 네트워크 정책)을 지정할 수 있습니다. 

정책을 CI/CD 시스템과 쿠버네티스 권한 컨트롤러 프레임워크에 연결함으로써 조직은 소프트웨어 개발 라이프사이클의 초기에 제어 정책을 더욱 쉽게 적용하여 런타임 시 노출을 방지할 수 있습니다. 

그리고 쿠버네티스 구조(예: 권한 컨트롤러)를 활용하면 보안이 쿠버네티스 툴체인에 긴밀하게 연결됩니다.

엔터프라이즈급 쿠버네티스 체험하기