쿠버네티스는 어떻게 작동하는가?
쿠버네티스는 컨테이너의 배포, 업데이트 및 모니터링을 자동화하는 조정 툴입니다. 쿠버네티스는 Red Hat OpenShift, Docker EE, Rancher, IBM Cloud, AWS EKS, Azure, SUSE CaaS, Google Cloud 등 대부분의 주요 컨테이너 관리와 클라우드 플렛폼에서 지원됩니다.
쿠버네티스가 어떻게 작동하는지 이해하기 위해서는 먼저 아래의 개념을 알아야 합니다.
• 포드(Pod) : 쿠버네티스에서의 배치와 주소 지정의 단위로, 자체 IP 주소를 가지며 하나 이상의 컨테이너(일반적으로 1개)를 포함할 수 있습니다.
• 서비스(Service) : 기본 포드에 대한 프록시 역할을 하며 복제된 포드 사이에서 요청을 로드밸런싱할 수 있습니다. 서비스는 외부 IP 또는 노드 포트를 정의하여 하나 이상의 포드에 액세스할 수 있는 외부 액세스 엔드포인트를 제공할 수 있습니다.
• 워커 노드(Worker Node) : 미니언이라고도 불리며 일반적으로 응용 프로그램 컨테이너 및 에이전트나 프록시 등의 기타 쿠버네티스 컴포넌트를 실행합니다.
• 마스터 노드(Master Node) : 쿠버네티스 워커 노드 클러스터 및 노드상의 포드 전개를 관리하는 서버로 물리적 시스템이나 가상 시스템입니다.
쿠버네티스 클러스터 관리에 사용되는 주요 컴포넌트에는 API 서버, Kubelet 등이 있습니다. 쿠버네티스는 브라우저 기반 관리 콘솔인 쿠버네티스 Dashboard도 지원합니다. 이러한 컴포넌트는 공격 대상이 될 수도 있습니다.
쿠버네티스 역할 기반 액세스 제어
쿠버네티스 역할 기반 액세스 제어(Role-Based Access Control, RBAC)는 시스템 리소스의 세밀한 관리를 제공합니다. RBAC는 애플리케이션 워크로드와 쿠버네티스 시스템 리소스에 대한 액세스를 관리할 수 있습니다. OpenShift와 같은 관리 툴은 추가적인 제어기능을 사용할 수 있지만, 기본적으로 쿠버네티스의 자체 보안 제어 기능을 사용합니다. API 서버나 애플리케이션 워크로드와 같은 쿠버네티스 구성 요소에 대한 무단 액세스를 방지하기 위해 액세스 제어를 적절하게 구성하는 것이 중요합니다.
쿠버네티스 네트워킹
쿠버네티스의 주요 네트워킹 개념은 모든 포드에 자체 라우팅 가능한 IP 주소가 할당된다는 것입니다. 쿠버네티스(실제로는 쿠버네티스의 네트워크 플러그인)는 호스트 간의 모든 요청을 내부적으로 적당한 포드에 라우팅합니다. 쿠버네티스 포드에 대한 외부로부터의 액세스는 쿠버네티스가 적절한 포드로 라우팅하는 서비스, 로드 밸런서 또는 입력 컨트롤러를 통해 가능합니다.
쿠버네티스는 iptables를 사용하여 포드 간(그리고 노드 간) 네트워크 연결을 제어하고 많은 네트워킹 및 포트 포워딩 규칙을 처리합니다. 이렇게 하면 클라이언트는 쿠버네티스 서비스에 접속하기 위해 IP 주소를 추적할 필요가 없습니다. 또, 각 포드에는 고유의 IP 주소가 있어 컨테이너가 네이티브 포트로 수신할 수 있기 때문에 포트 맵핑은 큰 폭으로 심플화(대부분 제거)됩니다. 이러한 오버레이 네트워킹이 모두 쿠버네티스에 의해 동적으로 처리되기 때문에 네트워크 트래픽을 모니터링하는 것은 매우 어려우며 보안은 더더욱 어렵습니다.
컨테이너 배포 보안의 중요성
쿠버네티스와 같은 컨테이너와 툴을 사용하여 기업은 애플리케이션 배포의 많은 부분을 자동화할 수 있으며, 이는 많은 비즈니스상의 이점을 제공합니다. 그러나 이러한 새로운 전략은 기존의 시스템 운용 환경과 마찬가지로 해커 및 내부자 공격에 취약합니다. 랜섬웨어, 암호화페 채굴 악성코드, 데이터 도난 및 서비스운영 방해와 같은 공격들은 프라이빗 클라우드와 퍼블릭 클라우드의 새로운 컨테이너 기반 가상화 환경에서도 계속될 것입니다.
이러한 상황을 악화시키는 것은 기업의 소중한 자산을 탈취하기 위해 쿠버네티스나 퍼블릭 클라우드의 관리 컨테이너 서비스와 같은 새로운 툴과 테크놀로지 자체가 공격자들이 통과하는 게이트웨이로서 공격을 받게 된다는 것입니다. 최근에 일어난 쿠버네티스 중간자 취약성 그리고 테슬라 시스템에 대한 취약성 공격은 향후 수개월, 수년에 걸쳐 급증할 것으로 예상되는 많은 컨테이너 기술 기반을 타겟으로하는 잠재적 공격의 시작에 불과합니다.
극적으로 동적인 컨테이너의 특성으로 인해 다음과 같은 보안 문제가 발생할 수도 있습니다.
• CI/CD 파이프라인에서 시작된 취약성 – 오픈 소스 구성요소의 과도한 사용과 계속되는 중대한 취약성 문제의 발견은 빌드 단계, 레지스트리 및 프로덕션에서의 컨테이너 이미지에 영향을 미칩니다.
• 서버간 트래픽의 폭발적 증가 – 전통적인 애플리케이션은 방화벽과 호스트 보안 툴로 보호가 가능하지만, 컨테이너는 서버간 트래픽이나 인터넷 트래픽을 동적으로 증가시킬 수 있어 공격에 대한 감시가 어려울 수 있습니다.
• 공격받을 수 있는 범위의 증가 – 각 컨테이너는 서로 다른 공격 범위와 각각의 다른 취약성을 가질 수 있습니다. 쿠버네티스와 Docker와 같은 컨테이너 오케스트레이션 툴에 대한 추가적인 공격 범위도 고려해야 합니다.
• 변화를 따라잡기 위한 보안의 자동화 – 오래된 보안 모델과 툴들은 지속적으로 변화하는 컨테이너 환경을 따라갈 수 없습니다. 쿠버네티스의 자동화된 특성으로 인해 컨테이너와 포드가 몇 분 또는 몇 초 만에 나타났다 사라질 수 있습니다. 새로운 네트워크 접속을 포함할 수 있는 어플리케이션의 작동방식은 강화된 보안 정책에 즉시 반영되어야 합니다. 컨테이너의 보안을 확보하기 위해서는 차세대 자동 보안 툴이 필요하며, 파이프라인 초기에 보안 정책을 선언하고 코드로서 관리해야 합니다.
컨테이너가 제한된 기능과 특수 인터페이스를 가지고 있기 때문에 기본적으로 기존 애플리케이션보다 더 안전하다는 주장 있지만, 이는 사이버 범죄자와 해커들이 취약성이 없으며 가능한 모든 위협 벡터에 대해 잠긴 코드와 인프라에 대해 오래된 기술을 사용하여 공격을 할 경우에만 해당됩니다. 물론 해커의 이와 같은 공격을 하지는 않겠지만, 이러한 공격에 대한 실시간 모니터링이 필요합니다. 시간이 경과하고 경험이 쌓여감에 따라, 공격자의 정교함은 항상 새로운 인프라의 대응에도 불구하고 그보다 더 앞서 나가게 됩니다. 공격자들은 컨테이너를 공격하는 새로운 방법을 끊임없이 개발하고 있습니다.
쿠버네티스의 취약성과 공격 벡터
포드에서 실행되고 있는 쿠버네티스 컨테이너에 대한 공격은 네트워크를 통해 외부에서 발생하거나 내부자에 의해서도 발생할 수 있는데, 내부자에는 피싱 공격의 피해자도 포함되며 이때는 내부자의 시스템이 공격의 도관이 됩니다. 다음은 몇 가지 예입니다.
[그림 1] 쿠버네티스 공격
① 컨테이너의 손상 – 애플리케이션 설정 오류 또는 취약성에 의해 공격자는 컨테이너에 들어가 네트워크, 프로세스 제어 또는 파일 시스템의 취약점 탐색을 시작합니다.
② 포드 간의 무단 연결 – 손상된 컨테이너는 시스템을 탐색하거나 공격을 감행하기 위해 동일한 호스트 또는 다른 호스트에서 실행 중인 다른 포드와 연결을 시도할 수 있습니다. 비록 Layer 3 네트워크 제어에서는 화이트리스트 포드의 IP 주소를 어느 정도 보호할 수 있지만 신뢰할 수 있는IP 주소에 대한 공격은 Layer 7 네트워크 필터링으로만 적발할 수 있습니다.
③ 포드에서 데이터 유출 – 데이터 탈취는 명령과 제어 서버에 연결된 포드에서의 리버스 쉘과 민감한 데이터를 숨기기위한 네트워크 터널링과 같은 기술의 조합을 사용하여 이루어집니다.
④ 손상된 컨테이너가 악성 프로세스를 실행 – 컨테이너는 일반적으로 제한된 프로세스 세트를 실행하지만, 손상된 컨테이너는 암호 마이닝과 같은 악성 프로그램이나 네트워크 포트 검색과 같은 의심스러운 프로세스를 시작하거나, 혹은 이전에 볼 수 없었던 바이너리(프로세스 악용)를 주입할 수 있습니다.
⑤ 컨테이너 파일 시스템의 손상 – 공격자는 취약한 라이브러리/패키지 버전을 설치하여 컨테이너를 공격할 수 있습니다. 민감한 파일들도 또한 변경할 수 있는데, 일단 파일 변경이 가능해지면, 공격자는 루트 권한 탈취 등을 시도할 수 있습니다.
⑥ 손상된 워커 노드 – 운용 중인 컨테이너와 마찬가지로 호스트 자체도 손상될 수 있습니다. 일례로, Dirty Cow 리눅스 커널 취약성으로 인해 사용자가 루트 권한을 갖게 되는 일도 발생했었습니다.
킬체인 공격
공격자는 가장 피해가 큰 공격인 킬 체인 혹은 일련의 악의적 행동들을 통해 공격의 목표를 달성합니다. 이러한 이벤트는 몇 초 이내에 빠르게 발생하거나 며칠, 몇 주 또는 몇 달에 걸쳐 발생할 수 있습니다. 킬 체인에서 이벤트를 탐지하려면 서로 다른 리소스가 사용되므로 여러 계층의 보안 모니터링이 필요합니다. 프로덕션 환경에서 탐지의 가능성을 최대한 높이기 위해 감시해야 할 가장 중요한 벡터는 다음과 같습니다.
[그림 2] 킬 체인
• 네트워크 검사 – 공격자는 일반적으로 네트워크 연결을 통해 침입하여 네트워크를 통해 공격 범위를 넓혀갑니다. 네트워크는 공격을 감지할 수 있는 첫 번째 기회와, 공격자의 움직임을 탐지할 수 있는 기회, 그리고 데이터 탈취 활동을 포착할 수 있는 마지막 기회를 제공합니다.
• 컨테이너 – 각 컨테이너의 프로세스 및 syscall 활동을 모니터링하여 의심스러운 프로세스가 시작되었는지 또는 권한을 상승시키고 컨테이너에서 빠져나오려는 시도가 있었는지 여부를 확인하여 응용프로그램 또는 시스템 탈취를 탐지할 수 있습니다. 파일 무결성 모니터링 및 액세스 제한은 파일, 패키지 또는 라이브러리를 수정하려는 시도도 탐지할 수 있습니다.
• 호스트 모니터링 – 전통적인 호스트(엔드포인트) 보안도 커널 또는 시스템 리소스에 대한 공격을 탐지하는데 유용합니다. 단, 적절한 보안 능력을 확보하려면 호스트 보안 툴이 쿠버네티스 및 컨테이너를 인식할 수 있어야 합니다. 예를 들어 새 호스트는 쿠버네티스 클러스터에 동적으로 진입할 수 있으며 쿠버네티스가 관리하는 보안 설정 및 툴을 유지할 수 있어야 합니다.
위의 위협 벡터와 더불어, 공격자는 쿠버네티스 API 서버나 콘솔 등의 배포 툴을 손상시켜 시크릿에 액세스하거나 실행 중인 포드를 제어할 수 있습니다.
쿠버네티스 인프라 자체에 대한 공격
응용 프로그램을 비활성화 혹은 중단시키거나 시크릿, 리소스 또는 컨테이너에 대한 액세스를 얻기 위해 해커는 API 서버나 Kubelets 같은 쿠버네티스 리소스를 손상시킬 수도 있습니다. 예를 들면, 테슬라 해킹 사건에서는 보호되지 않은 쿠버네티스 콘솔을 이용하여 기반 인프라에 액세스하고 암호화 마이닝 소프트웨어를 실행했습니다.
API 서버 토큰을 탈취/해킹하거나 ID가 도난당하여 해커가 인증된 사용자를 가장하여 데이터베이스에 액세스할 수 있게 된 경우, 해커는 악성 컨테이너를 배포하거나 중요한 응용 프로그램을 중지시킬 수 있습니다.
오케스트레이션 툴 자체를 공격함으로써 해커는 실행 중인 응용 프로그램을 중단시키고 컨테이너를 실행하는 데 사용되는 기본 리소스를 제어할 수 있습니다. 쿠버네티스에는 etcd 또는 서비스 토큰에 대한 액세스와 같은 몇 가지 공개된 권한 상승 메커니즘이 있으며, 이를 통해 해커가 손상된 컨테이너에서 클러스터 관리자 권한을 얻을 수 있습니다.
이렇게 쿠버네티스의 중간자 취약성과 같은 보안 문제는 보안 전문가들이 우려하는 비교적 새로운 악성 보안 문제이며, 앞으로 더 새로운 보안 문제들이 생겨날 것입니다. 시스템의 취약성으로 인해 공격자는 외부 IP나 자주 사용되지 않는 옵션을 가진 쿠버네티스 기본 서비스 정의를 악용하여 중간자 공격을 시작할 수도 있습니다.
쿠버네티스 런타임 컨테이너 보안
프로덕션 운영 환경에서 컨테이너가 실행되면 컨테이너를 보호하기 위한 세 가지 중요한 보안 벡터는 네트워크 필터링, 컨테이너 검사 그리고 호스트 보안입니다.
네트워크 검사와 보안
컨테이너 방화벽은 기존 네트워크 보안 기술을 새로운 클라우드 네이티브 쿠버네티스 환경에 적용하는 새로운 유형의 네트워크 보안 제품입니다. 방화벽으로 컨테이너 네트워크를 보호하는 몇 가지 방법들은 다음과 같습니다.
• IP 주소 및 포트를 기반으로 하는 Layer 3/4 필터링 – 이 방법은 쿠버네티스 네트워크 정책이 규칙을 동적으로 업데이트하여 배포가 변경되고 확장될 때 이를 보호하도록 합니다. 단순한 네트워크 분할 규칙은 비즈니스 크리티컬 컨테이너 배포에 필요한 강력한 모니터링, 로깅 및 위협 탐지 기능을 제공하도록 설계되지 않았지만 승인되지 않은 연결로부터 어느 정도 보호할 수 있습니다.
• WAF(Web Application Firewall) 공격 탐지 – 웹 애플리케이션 방화벽의 기능과 유사하게 일반적인 공격을 탐지하는 방법을 사용하여 웹 대면 컨테이너(일반적으로 HTTP 또는 HTTPS 기반 애플리케이션)를 보호할 수 있습니다. 그러나 이는 HTTP를 통한 외부 공격에 대해서만 보호할 수 있으며, 내부 트래픽에 대한 멀티 프로토콜 필터링이 없습니다.
• Layer 7 컨테이너 방화벽 – 포드 사이의 트래픽에 대한 Layer 7 필터링 및 심층 패킷 검사가 포함된 컨테이너 방화벽은 네트워크 애플리케이션 프로토콜을 사용하여 컨테이너를 보호합니다. 컨테이너 방화벽은 또한 쿠버네티스와 같은 오케스트레이션 툴들과 통합되며, 자동화된 정책 작성을 위해 행동 학습을 활용합니다. 애플리케이션 프로토콜 화이트리스트와 DDoS, DNS 및 SQL 주입과 같은 일반적인 네트워크 기반 애플리케이션 공격에 대한 기본 제공 탐지 기능을 통한 보호가 이루어집니다. 또한 컨테이너 방화벽은 컨테이너 프로세스 모니터링 및 호스트 보안을 모니터링되는 위협 벡터에 통합할 수도 있습니다.
심층 패킷 검사(Deep Packet Inspection, DPI) 기술은 컨테이너 방화벽에서 심층 네트워크 보안을 위해 필수적입니다. 일반적으로 공격에는 예측 가능한 공격 벡터가 사용됩니다. 즉, 잘못된 형식의 헤더를 가진 악성 HTTP 요청을 보내거나, XML(Extensible Markup Language) 개체 내에 실행 가능한 쉘 명령을 포함하는 것입니다. Layer 7 DPI 기반 검사는 이러한 방법을 찾고 인식할 수 있습니다. 이러한 기술을 사용하는 컨테이너 방화벽은 각 포드 연결을 통과하도록 허용할지 또는 차단되어야 할 공격인지 여부를 결정할 수 있습니다.
컨테이너의 동적 특성과 쿠버네티스 네트워킹 모델을 고려할 때, 기존 툴들을 네트워크 가시성, 포렌식 및 분석에 사용할 수 없습니다. 애플리케이션 디버깅을 위한 패킷 캡처나 보안 이벤트 조사와 같은 간단했던 작업들은 이제 더 이상 간단하지 않습니다. 네트워크 보안, 검사 및 포렌식 작업을 수행하려면 새로운 쿠버네티스와 컨테이너를 인식하는 툴들이 필요합니다.
컨테이너 검사
사이버 공격은 자주 권한 상승과 악의적인 프로세스를 활용하여 공격을 시작하거나 확산시킵니다. Linux 커널(예: Dirty Cow), 패키지, 라이브러리 또는 응용 프로그램 자체의 취약성 공격은 컨테이너 내에서 의심스러운 활동을 발생시킬 수 있습니다. 컨테이너 프로세스 및 파일 시스템 활동을 검사하고 의심스러운 동작을 탐지하는 것은 컨테이너 보안의 중요한 요소입니다. 포트 검색 및 리버스 쉘 또는 권한 상승과 같은 의심스러운 프로세스가 모두 탐지되어야 합니다. 내장된 탐지프로세스와 이전 활동을 기반으로 비정상적인 프로세스를 식별할 수 있는 기본 행동 학습 프로세스의 조합이 필요합니다. 컨테이너형 응용프로그램을 마이크로서비스 원칙을 염두에 두고 설계할 경우, 컨테이너의 각 응용프로그램은 제한된 기능 집합을 가지고 있으며 컨테이너는 필요한 패키지와 라이브러리만으로 구축되므로 의심스러운 프로세스와 파일 시스템 활동을 훨씬 쉽고 정확하게 탐지할 수 있습니다.
호스트 보안
컨테이너가 실행되는 호스트(예: 쿠버네티스 워커 노드)가 손상되면 여러 가지 유형의 부정적인 결과가 발생할 수 있습니다. 여기에는 다음이 포함됩니다.
• 루트로 권한 상승
• 보안 애플리케이션 또는 인프라 액세스에 사용되는 시크릿 도난
• 클러스터 관리자 권한 변경
• 호스트 리소스 손상 또는 하이잭킹(예: 암호화 마이닝 소프트웨어)
• API 서버 또는 Docker 데몬과 같은 중요한 오케스트레이션 툴 인프라의 종료
• 컨테이너 검사에 대해 이전 섹션에서 논의된 의심스러운 프로세스의 시작
컨테이너와 마찬가지로 호스트 시스템에서 이러한 의심스러운 활동을 모니터링해야 합니다. 컨테이너는 호스트와 같은 운영 체제 및 애플리케이션을 실행할 수 있으므로 컨테이너 프로세스 및 파일 시스템 작업을 모니터링하려면 호스트를 모니터링하는 것과 동일한 보안 기능이 필요합니다. 네트워크 검사, 컨테이너 검사 및 호스트 보안을 함께 사용하면 여러 벡터에서 킬 체인을 탐지할 수 있습니다.
쿠버네티스 시스템과 리소스 보안
쿠버네티스와 같은 오케스트레이션 툴과 그 위에 구축된 관리 플랫폼은 보호되지 않으면 공격에 취약해질 수 있습니다. 컨테이너 배포가 이전에는 존재하지 않았던 잠재적인 새로운 공격 표면을 노출되면 해커의 침입에 취약해지게 됩니다. Tesla 해킹과 Kublet 공격은 새로운 기술에 대한 지속적인 공격과 패치의 사이클이 될 것으로 예상되는 첫 번째 사례 중 하나입니다. 쿠버네티스와 관리 플랫폼을 공격으로부터 보호하려면 시스템 리소스에 대한 RBAC를 적절하게 구성하는 것이 중요합니다. 다음은 적절한 액세스 제어를 위해 검토하고 구성할 영역입니다.
• API 서버 보호 – API 서버에 대한 RBAC를 구성하거나 수동으로 방화벽 규칙을 만들어 무단 액세스를 방지합니다.
• kubelet 권한 제한 – Kubelets을 위해 RBAC를 구성하고 인증서 로테이션을 관리하여 Kubelet을 보호합니다.
• 모든 외부 포트에 대한 인증 – 외부에서 액세스할 수 있는 모든 포트를 검토하고 불필요한 포트를 제거합니다. 필요한 외부 포트에 대한 인증을 실시합니다. 인증되지 않은 서비스의 경우 화이트리스트 소스에 대한 액세스를 제한합니다.
• 콘솔 액세스를 제한하거나 제거 – 강력한 암호 또는 이중 인증으로 사용자 로그인이 적절하게 구성되지 않은 경우 콘솔/프록시 액세스를 허용하지 않습니다.
일반적으로 모든 역할 기반 액세스 제어는 신중하게 검토되어야 합니다. 예를 들어, 클러스터 관리자 역할이 할당된 서비스 계정은 검토되어야 하고 반드시 필요한 계정에게만 주어져야 합니다. 워커 노드를 잠그기 위해 쿠버네티스 배포 인프라를 강력한 호스트 보안과 결합하면 공격으로부터 보호할 수 있습니다. 또한 모니터링 툴을 사용하여 인프라 서비스에 대한 액세스를 추적하여 무단 연결 시도 및 잠재적인 공격을 탐지하는 것이 권장됩니다.
Tesla Kubernetes 콘솔 공격의 예를 보면, 일단 워커 노드에 대한 액세스가 손상되면서 해커들이 암호화 마이닝 소프트웨어를 제어하기 위해 중국으로의 외부 연결을 만들었습니다. 컨테이너, 호스트, 네트워크 및 시스템 리소스에 대한 실시간 정책 기반 모니터링을 했다면 의심스러운 프로세스와 무단 외부 연결을 탐지할 수 있었을 것입니다.
쿠버네티스 환경을 위한 감사 및 컴플라이언스
컨테이너 기술과 쿠버네티스와 같은 툴의 급속한 발전으로 기업은 컨테이너 환경을 지속적으로 업데이트, 업그레이드 및 마이그레이션할 것입니다. 쿠버네티스 환경을 위해 설계된 일련의 보안 테스트를 실행하면 시스템 변경 시마다 보안이 저하되지 않도록 할 수 있습니다. 이렇게 함으로서 공격의 위험에 대해 인프라의 보안 상태를 평가할 수 있습니다. 더 많은 기업이 컨테이너로 마이그레이션함에 따라 인프라, 툴 및 배치의 변경으로 PCI와 같은 컴플라이언스 표준에 대한 재인증이 필요할 수도 있습니다.
다행히도 쿠버네티스용 CIS 벤치마크 및 Docker 벤치 테스트를 통해 쿠버네티스 및 Docker 환경에 대한 포괄적인 보안 상태를 점검할 수 있습니다. 이러한 테스트를 정기적으로 실행하고 예상 결과를 확인하는 작업을 자동화해야 합니다.
벤치마크 테스트가 가능한 영역들
• 호스트 보안
• 쿠버네티스 보안
• Docker 데몬 보안
• 컨테이너 보안
• RBAC의 올바른 구성
• 미사용 및 전송 중인 데이터 보안
또한 이미지 검사에는 이미지 보안과 관련된 CIS 벤치마크 테스트가 포함되어야 합니다. 추가 이미지 컴플라이언스 테스트를 통해 내장된 시크릿 및 파일 액세스(setuid/setgid) 위반이 있는지 이미지를 검사할 수 있습니다. 레지스트리와 프로덕션에서 이미지 및 컨테이너에 대한 취약성 검사는 알려진 공격을 방지하고 컴플라이언스를 달성하기 위한 핵심 구성 요소이기도 합니다. 빌드 프로세스와 CI/CD 파이프라인에 검사 프로세스를 통합하여 프로덕션으로 이동하는 모든 이미지가 검사되었는지 확인할 수 있습니다. 프로덕션에서 실행 중인 컨테이너와 호스트는 정기적으로 취약성 검사를 해야 합니다.
쿠버네티스 보안 자동화
개발팀이 컨테이너와 쿠버네티스를 사용하여 애플리케이션 구축을 자동화하기 위해 서두르고 있는 상황에서 보안 자동화는 매우 중요합니다. 보안팀이 애플리케이션, 인프라 또는 새로운 클라우드의 배포나 업데이트를 중단하거나 지연시킬 수 있는 시대는 지났습니다. 보안 자동화는 컨테이너를 실행을 위한 보안 인프라 및 플랫폼을 구성하는 것부터 시작하여 자동화된 런타임 보안까지 포함합니다. 반복 가능한 보안 구성을 가진 보안 인프라는 코드 개념 및 Terraform과 같은 툴로 사용함으로써 구현될 수 있습니다. 대부분의 런타임 보안이 행동 학습과 보안을 코드로 구현하기 위한 사용자 지정 리소스 정의(Custom Resource Definition, CRD)와 쿠버네티스 통합의 조합으로 자동화될 수 있습니다. 초기 수동 설정 또는 사용자 지정이 필요할 수 있지만 프로덕션이 가동되고 쿠버네티스가 포드 관리를 시작하면 보안은 배포와 함께 자동화, 조정 및 확장될 것입니다.
쿠버네티스 컨테이너 방화벽을 컨테이너 검사 및 호스트 보안과 결합함으로써, 치명적인 공격을 실행하려는 킬 체인에서의 활동을 탐지하고 방지할 수 있습니다. 컨테이너 기반 애플리케이션의 선언적 특성과 쿠버네티스와 같은 툴을 위한 광범위한 통합 환경으로 인해 하이퍼 다이내믹 컨테이너 환경에서도 고급 보안 제어를 적용할 수 있습니다. 쿠버네티스와 통합하고 행동 학습 및 다중 벡터 보안 기능을 채택함으로써, 파이프라인 전반에 걸쳐 보안 자동화가 가능하게 되었으며, 보안 자동화는 이제 비즈니스 크리티컬 쿠버네티스 배포를 위해 꼭 필요한 요구사항이 되었습니다.
이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기 : https://www.itworld.co.kr/techlibrary/275311
▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.
