Kubernetes 최신 보안 트렌드 5가지

Technical Writer

2024년 8월 14일 · 약 12분

이 글은 2024년 지금 주목해야 할 Kubernetes 보안 트렌드 5가지를 정리했습니다. 올해로 Kubernetes가 나온 지 10주년이 됐는데요. Kubernetes는 이제 모든 규모의 기업이 사용하는 컨테이너 오케스트레이션의 표준으로 자리매김했습니다. 오늘날 많은 기업이 컨테이너화된 애플리케이션과 Kubernetes를 통한 오케스트레이션을 도입하는데요. 이로써 컨테이너와 Kubernetes 보안을 강화해야 할 필요성도 커졌습니다.

IT 환경이 시시각각 변화하면서 컨테이너와 Kubernetes의 보안 환경은 급변하는데요. 특히 새로운 보안 위협과 취약점이 나타나면서 컨테이너와 Kubernetes 보안 트렌드는 꾸준히 진화하고 있습니다. 이에 글로벌 IT 기업과 연구·컨설팅 기업, DevOps 교육 기관은 2024년 Kubernetes 보안 트렌드를 여럿 제시했는데요. 이 글은 이중 3가지 트렌드와 글로벌 오픈 소스 솔루션 기업 Red Hat이 발표한 ‘The state of Kubernetes security report’ 가운데 2가지 트렌드를 골라 총 5가지 Kubernetes 보안 트렌드를 다뤘습니다.

모든 앱 라이프사이클에서 발생하는 보안 인시던트, 제로 트러스트 보안 모델 확산, Kubernetes를 위한 변경 불가능한 인프라 주목, 오픈 소스 도구를 사용한 Kubernetes 보안 관리, 컴플라이언스 자동화 중요성 증가가 그 내용인데요. 지금부터 각 트렌드의 구체적인 현황과 등장 배경, 유의 사항을 알아보겠습니다.

1. 보안 인시던트, 모든 앱 라이프사이클서 발생

Red Hat 설문조사 응답자들이 지난 12개월 동안 경험한 컨테이너 또는 Kubernetes 보안 인시던트, 문제. 출처=Red Hat

컨테이너 또는 Kubernetes 보안 인시던트가 애플리케이션 라이프사이클의 모든 단계에 일어나고 있습니다. 올해 6월 발표한 Red Hat 설문조사*에 따르면, 응답자들의 조직은 지난 12개월 동안 컨테이너 또는 Kubernetes 보안 인시던트로 다음 문제를 경험했는데요. 런타임 중 보안 인시던트(45%), 해결해야 할 주요 취약점 - 빌드·배포 단계 문제(44%), 컨테이너 또는 Kubernetes 환경의 잘못된 구성 탐지(40%), 감사 실패(26%) 순이었습니다. 10개 조직 중 9개(89%)는 같은 기간에 컨테이너 또는 Kubernetes 보안 인시던트가 최소 1건 이상 있었고요.

이러한 문제가 발생한 이유는 컨테이너 기반 Kubernetes 환경 보안의 복잡성 때문입니다. Red Hat에 따르면, Kubernetes는 클러스터 전반의 보안을 강화하기 위해 네트워크 정책과 역할 기반 액세스 제어(RBAC)와 같은 메커니즘을 제공하는데요. 일부 기능은 기본적으로 너무 허용되거나 비활성화됐고요. 이는 충분한 보호를 보장하기 위해 추가 구성이 필요하죠. 아울러 SELinux와 같은 보안 제어는 애플리케이션 보안을 강화하는데요. 그러나 이는 운영 환경에 맞춤화하고, 통합하기가 어려울 수 있습니다. 이러한 어려움은 애플리케이션 라이프사이클의 여러 단계에서 보안 인시던트, 취약점, 잘못된 구성 문제로 나타나죠.

컨테이너와 Kubernetes 보안을 강화하려면, 애플리케이션 라이프사이클 전반에 보안을 향상해야 하는데요. Red Hat은 “모든 애플리케이션 라이프사이클 단계에 걸쳐 보안에 집중하면 잠재 취약점을 조기에 확인하고 완화할 수 있다”며 “데이터 침해, 사이버 공격, 사용자 신뢰 저하 위험을 낮출 수 있다”고 설명합니다. 구체적으로 다음 방안을 실행할 수 있는데요. 먼저, 보안 플랫폼 내 구성 검사에 DevSecOps 모범 관행과 내부 제어를 통합하고요. 컨테이너와 Kubernetes 플랫폼을 사용해 Kubernetes 구성 보안 평가를 자동화합니다. 보안 통합과 자동화에는 자동화 테스트, 지속적 모니터링, 코드 리뷰와 같은 DevSecOps 프로세스를 활용할 수 있고요.

*Red Hat은 미국, 영국, APAC 지역 DevOps, 엔지니어링, 보안 전문가 600명을 대상으로 2023년 12월, 2024년 1월에 설문조사를 실시함.

2. 제로 트러스트 보안 모델 확산

출처=픽사베이

제로 트러스트 보안 모델이 컨테이너와 Kubernetes 보안에 계속 채택되고 있습니다. 이 모델은 ‘사용자 또는 디바이스 위치와 관계없이 네트워크나 리소스에 액세스하려는 모든 시도를 검증해야 한다’고 가정하죠. 미국 연구·컨설팅 기업인 Verified Market Reports에 따르면, 제로 트러스트 아키텍처에서는 어떤 엔티티도 본질적으로 신뢰할 수 없고요. 이는 네트워크 내외부 모든 사람에게 검증받아야 합니다. 제로 트러스트 보안 모델은 미국 연방 정부가 주목할 정도로 중요한 개념인데요. 미국 국가안보국은 Kubernetes의 제로 트러스트 보안 모범 관행을 설명한 ‘Kubernetes 강화 가이드’를 발표하기도 했습니다.

Kubernetes 환경에 제로 트러스트 보안 모델이 중요한 이유는 다음과 같은데요. DevOps 컨설턴트인 Jean-Jerome Levy에 따르면, Kubernetes는 분산되고 동적인 환경에서 애플리케이션 배포와 관리를 용이하게 하죠. 그러나 Kubernetes의 개방적이고 복잡한 특성 때문에 클러스터는 다양한 잠재 공격에 취약할 수 있습니다. 제로 트러스트 보안 모델을 도입하면 클러스터 보안을 강화할 수 있는데요. Verified Market Reports에서는 “이 모델을 구현하면 모든 상호작용이 검증돼 컨테이너화된 환경 안에서 무단 액세스, 위협의 측면 이동 위험을 완화할 수 있다”고 설명하죠. 이 모델은 마이크로서비스가 네트워크를 통해 통신하는 컨테이너화된 애플리케이션에 적합합니다.

Kubernetes를 위한 제로 트러스트 보안 모델을 구현할 때 유의 사항이 있습니다. 미국 소프트웨어 기업 NGINX의 시니어 수석 소프트웨어 엔지니어 출신인 Matthew Yacobucci는 다음 규칙을 제언하는데요. 첫째, Kubernetes에 복잡성을 추가하지 않고요. 둘째, 개발자와 최종 사용자에게 최소한의 오버헤드를 추가합니다. 셋째, 데이터와 컨트롤 플레인에 적용하고요. 넷째, Ingress Controller와 서비스 메시를 사용합니다. 다섯째, Ingress Controller와 서비스 메시를 통합하고요. 여섯째, 인증서의 올바른 처리를 자동화합니다.

3. Kubernetes 위한 변경 불가능한 인프라 주목

출처=픽사베이

변경 불가능한 인프라(Immutable Infrastructure)가 Kubernetes 보안 분야에서 꾸준히 주목받고 있습니다. 이는 서버와 구성 요소를 관리하는 혁신적인 접근 방식으로, 클라우드 서비스와 DevOps에서도 관심을 받죠. Verified Market Reports에 따르면, 변경 불가능한 인프라 모델에서는 구성 요소가 배포되면 이는 라이프사이클 동안 변경되지 않고요. 이로써 공격 표면을 최소화하고, Kubernetes 클러스터를 더 쉽게 관리하고 보호할 수 있죠. 오늘날 조직에서는 변경 불가능한 인프라의 생성과 배포를 용이하게 해 Configuration drift와 무단 변경 위험을 줄이는 도구와 관행을 많이 채택합니다.

변경 불가능한 인프라는 다음 장점 때문에 이목을 끕니다. 테크니컬 카피라이터인 Nahla Davies는 “변경 불가능한 인프라는 서버의 무결성이 유지되기에 롤백 절차를 간소화하고, 트러블슈팅도 최소화한다”라고 설명하고요. 아울러 이는 서버 전반에 걸쳐 균일한 구성으로 테스트도 간소화하고, 배포 후 상태가 변경되지 않아 복잡성도 줄입니다. 따라서 DevOps와 클라우드 컴퓨팅과 같이 상호 의존적 요소가 많은 환경에 이상적이죠. Configuration drift도 거의 제거하고요. 또 변경 불가능한 인프라를 사용하면 머신러닝으로 이상 징후를 확인해 지원 요청이 많이 감소하고, 보안도 강화할 수 있습니다.

변경 불가능한 인프라를 성공적으로 운영하려면 다음 사항을 유념해야 합니다. 미국 소프트웨어 기업 Codefresh의 제언인데요. 첫째, 모든 걸 버전화합니다. 인프라 코드, 애플리케이션 코드, 데이터가 여기에 포함되죠. 둘째, 데이터를 애플리케이션, 인프라와 분리해 보관합니다. 애플리케이션과 인프라는 변경 불가능해야 하고, 배포된 뒤 변경돼선 안 되는데요. 데이터는 시간이 지나면 변경되기 때문이죠. 셋째, 강력한 액세스 제어를 구현합니다. 인프라가 코드로 정의돼 버전 제어 시스템에 저장될 때, 액세스 권한이 있는 사용자를 제어해야 합니다. 넷째, 롤백을 계획해야 합니다. 신중하게 계획하고 테스트해도 일이 잘못될 수 있는데요. 필요하다면 이전 상태로 빠르게 되돌아갈 수 있어야 합니다.

4. 오픈 소스 도구로 Kubernetes 보안 관리

Red Hat 설문조사 응답자들이 Kubernetes 보안 위해 사용하는 오픈 소스 도구. 출처=Red Hat

오늘날 오픈 소스 도구는 Kubernetes 보안 관리에 지속적으로 쓰입니다. 특히 Open Policy Agent, Kube-bench, KubeLinter가 인기 있는 오픈 소스 Kubernetes 보안 도구인데요. Red Hat 설문조사에 따르면, 응답자들의 조직이 가장 많이 사용하는 관련 도구는 Open Policy Agent(35%), Kube-bench(31%), KubeLinter(31%), Kube-hunter(28%), Falco(20%), Kyverno(15%), StackRox(13%), Clair(12%), Terrascan(12%), Checkov(10%) 순이었습니다. 이들 조직은 Kubernetes 환경에서 평균 2.1개 보안 관련 오픈 소스 도구를 사용하죠.

조직이 이러한 도구를 쓰는 이유는 클라우드 네이티브 애플리케이션 보호에 도움이 되는 고급 기술을 활용하고, 오픈 소스 도구로 얻을 수 있는 가시성, 투명성을 누리기 위함으로 분석됩니다. 각 오픈 소스 도구는 다음 기능을 지원하는데요. Open Policy Agent를 활용하면 정책 관리를 간소화할 수 있고요. Kube-bench는 CIS Kubernetes Benchmark와 비교해 Kubernetes 배포 보안을 확인하는 데 도움이 되죠. KubeLinter를 사용하면 애플리케이션의 모범 관행 준수 여부를 확인할 수 있고요. Kube-hunter는 Kubernetes 클러스터와 클라우드 네이티브 환경의 보안 문제를 파악하도록 지원합니다.

그러나 Kubernetes 보안을 위해 오픈 소스 도구를 사용하면 어려움도 있습니다. 설문조사 기업 Global Surveyz 조사와 오픈 소스 Kubernetes 보안 플랫폼 Kubescape 개발사인 ARMO 보고서에서는 다른 DevOps 도구와 통합, Kubernetes 관리와 설정을 그 예로 제시했는데요. 이는 오픈 소스 특성상 지원과 안내가 제한적인 영향도 있죠. 따라서 오픈 소스 Kubernetes 보안 도구가 발전하려면, 기존 DevOps 기술 스택과 더 잘 통합되고, 지속적인 초기 관리 설정이 더 쉬워져야 한다는 의견도 나옵니다.

*Open Policy Agent: 클라우드 네이티브 스택 전반의 통합 정책을 위한 툴셋이자 프레임워크

**KubeLinter: Kubernetes YAML 파일과 Helm 차트를 위한 정적 분석 도구

***Kube-hunter: 보안 테스트와 스캐닝 도구

5. 컴플라이언스 자동화 중요성 증가

출처=픽사베이

컴플라이언스 자동화가 컨테이너와 Kubernetes 보안 분야에서 갈수록 중요해지고 있습니다. 이는 정책 시행, 감사 프로세스, 컴플라이언스 보고서 생성 등을 자동화하는 방식으로 이뤄지는데요. Verified Market Reports에 따르면, 데이터 보호와 프라이버시 규제 요건이 점점 더 엄격해지면서 컴플라이언스 자동화가 컨테이너, Kubernetes 보안의 중대한 트렌드가 되고 있습니다. 오늘날 조직은 GDPR, HIPAA, PCI DSS와 같은 규정을 준수해야 하는데요. 이는 적절한 데이터 처리, 액세스 제어, 감사를 요구합니다.

컴플라이언스 자동화가 컨테이너와 Kubernetes 보안에 필요한 이유는 복합적입니다. Verified Market Reports에 따르면, 이는 동적인 컨테이너 환경에서 컴플라이언스를 유지하는 복잡한 작업을 간소화하죠. 그 결과, 컨테이너화된 애플리케이션이 규제 표준과 보안 모범 관행을 준수하는 데 도움이 됩니다. 미국 소프트웨어 기업 Rafay는 “수동 컴플라이언스 검사와 정책 시행은 동적인 클라우드 네이티브 환경에서 시간이 오래 걸리고, 오류가 발생하기 쉽다”라고 설명하는데요. 컴플라이언스 자동화는 이러한 문제를 해결하는 데 도움이 되죠.

Rafay에 따르면, Kubernetes 컴플라이언스와 정책 거버넌스는 다음 단계에 따라 자동화할 수 있습니다. 첫째, 컴플라이언스 요구사항을 확인하고요. 둘째, 조직 필요에 따라 적절한 자동화 도구를 선택합니다. 셋째, 선택한 도구를 사용해 컴플라이언스 요구사항을 코드로 변환하고요. 넷째, 정책을 CI/CD에 통합합니다. 다섯째, 선택한 도구로 지속적인 모니터링을 설정하고 구성과 정책 위반을 추적하고요. 여섯째, 자동화된 수정 프로세스를 구성해 위반 사항을 신속하게 바로잡습니다. 일곱째, 정기적으로 정책을 검토하고 업데이트하고요. 여덟째, 컴플라이언스 자동화 전략, 정책, 사용 도구, 절차 등 모든 걸 문서화합니다.

맺음말

지금까지 2024년 Kubernetes 보안 트렌드 현황과 등장 배경, 유의 사항을 살펴봤습니다. 이 글의 요점은 다음과 같은데요.

컨테이너 또는 Kubernetes 보안 인시던트는 애플리케이션 라이프사이클의 모든 단계에 발생하고 있습니다. Red Hat에 따르면, 조직은 런타임 중 보안 인시던트, 해결해야 할 주요 취약점(빌드·배포 단계 문제), 컨테이너 또는 Kubernetes 환경의 잘못된 구성 탐지, 감사 실패를 경험했고요. 10개 조직 중 9개는 컨테이너 또는 Kubernetes 보안 인시던트가 최소 1건 이상 있었습니다.
제로 트러스트 보안 모델이 컨테이너와 Kubernetes 보안에 계속 채택되고 있습니다. 이 모델은 ‘사용자 또는 디바이스 위치와 관계없이 네트워크나 리소스에 액세스하려는 모든 시도를 검증해야 한다’고 가정하죠. 제로 트러스트 보안 모델은 미국 연방 정부가 주목할 정도로 중요성을 인정받습니다. 이 모델을 구현하면 모든 상호작용이 검증돼 컨테이너화된 환경 안에서 무단 액세스, 위협의 측면 이동 위험을 완화할 수 있습니다.
변경 불가능한 인프라는 Kubernetes 보안 분야에서 꾸준히 주목받고 있습니다. 이 모델에서는 구성 요소가 배포되면 이는 라이프사이클 동안 변경되지 않고요. 이로써 공격 표면을 최소화하고, Kubernetes 클러스터를 더 쉽게 관리하고 보호할 수 있죠. 오늘날 조직에서는 변경 불가능한 인프라의 생성과 배포를 용이하게 해 Configuration drift와 무단 변경 위험을 줄이는 도구와 관행을 많이 채택합니다.
오픈 소스 도구는 Kubernetes 보안 관리에 지속적으로 쓰입니다. Open Policy Agent, Kube-bench, KubeLinter는 인기 있는 오픈 소스 Kubernetes 보안 도구인데요. Red Hat에 따르면, 조직은 Kubernetes 환경에서 평균 2.1개 보안 관련 오픈 소스 도구를 사용하죠. 이러한 도구는 클라우드 네이티브 애플리케이션 보호에 도움이 되는 고급 기술을 지원하고, 가시성과 투명성도 제공합니다.
컴플라이언스 자동화가 컨테이너와 Kubernetes 보안 분야에서 갈수록 중요해지고 있습니다. 이는 정책 시행, 감사 프로세스, 컴플라이언스 보고서 생성 등을 자동화하는데요. 데이터 보호와 프라이버시 규제 요건이 엄격해지면서 컴플라이언스 자동화의 필요성이 커졌습니다. 오늘날 조직은 GDPR, HIPAA, PCI DSS 규정을 준수해야 하죠. 컴플라이언스 자동화는 동적인 컨테이너 환경에서 컴플라이언스를 유지하는 복잡한 작업을 간소화하는데요. 이는 컨테이너화된 애플리케이션이 규제 표준과 보안 모범 관행을 지키는 데 도움이 됩니다.