본문 바로가기
엑셈 경쟁력/전문가 기술기고

클라우드 A to Z | Kubernetes 보안 위험

by EXEM 2021. 12. 22.

 

컨테이너 오케스트레이션인 쿠버네티스가 이제는 명실상부 Global Standard가 되어가고 있습니다. 쿠버네티스는 수없이 많은 컨테이너를 편리하게 배포하고 부하에 따라 스케일을 조절해주며, 리소스에 여유가 있는 노드에 컨테이너가 뜰 수 있도록 스케줄링을 관리해주기 때문에 컨테이너 기반으로 애플리케이션을 배포하는 기업들은 사용하지 않을 수가 없는데요. 많은 장점이 있고 많이 사용하는 만큼, 보안 위험 측면에서는 많은 기업에서 신경 쓰지 못하고 있는 실정입니다.

 

2021714일에 RedHat에서 조사한 해외의 500명 이상의 DevOps, 엔지니어링 및 보안 전문가를 대상으로 한 설문 조사에 따르면 응답자의 55%는 보안 문제로 인해 애플리케이션의 배포가 느려지거나, 지연된 경험이 있으며 응답자의 94%는 지난 12개월 동안 쿠버네티스 환경에서의 최소 1회의 보안 사고를 경험했다고 응답했습니다.

 

Q. 지난 12개월 동안 컨테이너 및 쿠버네티스와 관련된 어떤 보안 사고 및 문제를 경험했습니까?

출처: Kubernetes adoption, security and market trends report 2021 (Redhat)

 

쿠버네티스 보안을 고려하지 않고 서비스를 운영할 경우, 보안 이슈 발생 시 오히려 애플리케이션의 코드 수정, 배포 방식 수정 등의 이유로 배포 민첩성에 큰 영향을 미치기 때문에 이를 방지하려면, 개발 단계에서 보안을 구축하고 빌드 단계에서 가능한 많은 보안 문제를 해결해야 배포 민첩성에 영향을 주지 않습니다.

 

 

Kubernetes 보안

쿠버네티스의 보안은 Cloud, Cluster, Container, Code로 이루어진 Cloud 기본 보안의 4C를 기반으로 합니다.

Cloud

기업의 데이터 센터와 사용하고 있는 IaaS 서비스 등 기본적으로 쿠버네티스가 설치되는 물리적 인프라 보안 영역에서 보안 모범 사례를 준수해야 합니다. 쿠버네티스는 결국 운영체제 위에 설치되는 소프트웨어이기 때문에 기본적으로 악의적인 사용자가 접근할 수 없는 물리적 보안이 지켜지고, 네트워크 등으로 익명 사용자가 접근할 수 없도록 최소한의 Port만 열어두고, 방화벽 등의 인프라 보안이 지켜지는 서버에서 서비스할 수 있도록 해야 합니다.

Cluster

쿠버네티스 Cluster 보안에는 쿠버네티스 API와 같은 설정이 가능한 구성 요소와 Cluster에 속한 모든 애플리케이션 보안이 포함됩니다. 쿠버네티스 API와 같이 설정이 가능한 구성 요소들의 가장 취약한 설정은 기본값(Default Value)입니다. 운영 현황에 맞게 설정이 필요하며, 사용자에 따른 최소한의 권한을 사용하도록 계정별 Role 정의와 접근제어가 필요합니다.

Container

컨테이너 설계의 보안 측면에서 가장 중요한 것은 필요한 라이브러리만 사용해서, 불필요한 코드 및 라이브러리가 컨테이너에 포함되지 않도록 설계해야 하며, 컨테이너 사용자에게 불필요한 권한이 부여되지 않도록 관리해야 합니다. 불필요한 권한이 부여된 경우 악의적이지 않더라도 실수로 서비스 장애 등의 이슈를 야기할 수 있습니다.

Code

Code는 쿠버네티스 환경과 쿠버네티스 환경에 배포된 모든 애플리케이션에 대한 주요 Attack Surface(공격 표면)를 말합니다. 사용하지 않는 Port나 테스트용 API 등 불필요하게 외부에 노출하는 경우 악의적인 사용자나 해커에게 공격을 시도할 수 있는 포인트가 될 수 있습니다.

 

이미지 출처 : threat stack, 3 Things to Know About Kubernetes Security

 

 

Kubernetes 보안 사례, 애플리케이션 Life Cycle 측면

애플리케이션의 Life Cycle Build, Deploy, Runtime으로 나눌 수 있습니다. 각 파트 별 보안 사례를 소개합니다.

Build

신뢰할 수 없는 RegistryImage를 사용하는 경우 의도하지 않게 악의적인 행위자의 액세스 권한을 부여할 수 있는 Malware나 백도어가 포함될 수 있습니다. 그리고, 컨테이너화된 애플리케이션에는 불필요한 패키지나 라이브러리, shell을 제거해야 합니다.

Deploy

가능한 최소한의 권한만 유지하며 작업할 수 있도록 해야 하며, Namespace를 이용해 Resource와 팀을 적절히 구분해 사용해야 합니다. 또한, RBAC(역할 기반 액세스 제어)이 적절하게 액세스를 제한하도록 구성되었는지 확인해야 합니다.

Runtime

쿠버네티스가 설치된 노드들에 접근할 수 있는 모든 인프라 요소는 Attack Surface(공격 표면) 될 수 있습니다. 공격으로 손상된 컨테이너는 공격의 원인을 찾아 수정하는 동안 신속하게 격리, 중지 및 정상적인 컨테이너로 교체해야 합니다.

 

이미지 출처 : Kubernetes 공식 홈페이지

 

 

Kubernetes 보안 사례, Security Check List

쿠버네티스의 보안을 위해서 다양한 IT 보안 컨설팅 기업들이 쿠버네티스에 해당하는 Security Check List를 만들고 있습니다. 국내 IT 보안기업의 클라우드 보안 가이드에서 중요도가 가장 높은 Check List 두 가지를 소개합니다.

 

1. Master Node - API Server 인증 제어

  • 항목 설명
    : API Server의 잘못된 인증 구현은 쿠버네티스 시스템의 모든 요소에 영향을 줄 수 있으므로 API Server의 외부 독립 서비스를 이용한 사용자 계정 관리, 설정을 통한 비인증 서비스 접근에 대한 차단, 안전한 방식의 인증 시스템 사용 등의 강력한 인증 방법을 사용하여, API Server 인증에 대해 엄격하게 제어되어야 합니다.
  • 진단 방법

- 비인증 접근 차단

/etc/kubernetes/manifests/kube-apiserver.yaml 파일 내 아래 파라미터 존재 및 적절한 인자 값 설정 여부 확인

--anonymous-auth
--insecure-allow-any-token
--insecure-bind-address
--insecure-port
--repair-malformed-updates
--service-account-lookup

 

- 취약한 인증 방식 사용

/etc/kubernetes/manifests/kube-apiserver.yaml 파일 내 아래 파라미터 존재 및 적절한 인자 값 설정 여부 확인

--basic-auth-file
--token-auth-file

 

2. Master Node – API Server 권한 제어

  • 항목 설명
    : 쿠버네티스 특성상 민감도 수준이 다른 컨테이너를 운영하는 다양한 사용자 또는 그룹이 접근하여 사용할 수 있습니다. 이때 필요한 권한 이상으로 사용자 또는 그룹에 부여될 경우 악의적인 사용자나 부주의한 사용자에 의해 쿠버네티스에서 관리하는 다른 컨테이너의 작업에 영향을 주거나 파괴할 수 있습니다.
  • 진단 방법

- 권한 검증 부재 

/etc/kubernetes/manifests/kube-apiserver.yaml 파일 내 아래 파라미터 존재 및 적절한 인자 값 설정 여부 확인

--authorization-mode

 

 

끝으로,

많은 기업에서 기존의 서비스를 컨테이너화하고 새로운 서비스를 설계할 때도 컨테이너 기반의 설계를 하고 있으며, 이를 관리하기 위해 대표 컨테이너 오케스트레이션인 쿠버네티스를 도입하고 있습니다. 하지만, 학습 난이도가 높아 보안까지는 크게 신경 쓰지 못하는 경우가 많이 있는 것 같습니다. 쿠버네티스 보안 측면에서 가장 중요한 것은 서비스에 필요한 최소한의 권한과 최소한의 코드(이미지 포함)를 이용해서 개발부터 배포, 운영하는 것이라고 보입니다.

 

이제는 개발 트렌드가 모놀리틱 구조가 아닌, MSA 구조로 변화했기 때문에 침해 사고가 발생했을 때, 침해 발생 서비스(침해 지점)를 찾아내기 힘든 상황입니다. 고가용성 서비스를 위해서 아키텍처도 중요하지만, 결국 보안 사고가 발생하면 정상적인 서비스가 어렵기 때문에 고가용성을 지키지 못하게 됩니다. 쿠버네티스 기반의 서비스를 구축하실 때 꼭 보안을 고려해서, 노력만큼 안전하고 유연한 서비스를 운영하시기 바랍니다.

 

 

 

 

📢
6개월간의 클라우드 A to Z 연재를 종료합니다.
그동안 성원해주신 여러분께 감사드리며, 새로운 기술 기고로 다시 찾아뵙겠습니다. 

 

 

 

 

 

댓글