|
|
5주차 시간에는 모임장님께서 쿠버네티스 보안을 주제로 학습 내용을 공유해 주셨다. 이번 블로그 글에서는 쿠버네티스 보안에 대해 스터디한 내용을 공유하고자 한다.
Kubernetes 4C Layer
쿠버네티스 공식문서에 따르면 쿠버네티스 보안은 4계층(클라우드/ 클러스터 / 컨테이너 / 코드)으로 구성되며, 각 계층에 대해 보안 관점이 필요하다고 한다.
https://kubernetes.io/docs/concepts/security/overview/
- Cloud, Infra : 클라우드 계층에서는 쿠버네티스 클러스터가 실행되는 기반 인프라에 초점을 맞춘다. 이 계층에서는 가상 머신, 네트워크, 스토리지 및 기타 자원에 대한 보안을 강화하고, 클라우드 제공 업체의 보안 도구 및 기능을 활용하는 것으로 초점이 맞춰져 있다. 인프라 보호 대상과 클라우드 제공 업체(AWS) 의 제공 보안은 다음의 표를 참고하자.
보호 대상 AWS EKS에서의 보안 기능 API 서버에 대한 네트워크 액세스 클러스터 구축시 액세스 지점에 대해 Elastic Load Balancer를 구성한다. 이를 통해 API 서버에 대한 액세스를 VPC 내부로 제한하거나 인터넷 게이트웨이를 통해 인터넷에서도 접근이 가능하도록 설정할 수 있다. 또한, AWS Identity and Access Management (IAM)을 사용하여 사용자와 역할에 대한 접근 제어를 구성할 수 있다. 노드에 대한 네트워크 액세스 VPC 서비스를 이용하여 노드에 대한 액세스를 VPC 내부로 제한하거나 인터넷 게이트웨이를 통해 인터넷에서도 접근이 가능하도록 설정할 수 있다. 또한 보안 그룹을 통해 IP 주소 범위에 대한 인바운드 및 아운바운드 트래픽을 제어할 수 있다. 클라우드 제공 업체 API 에 대한 쿠버네티스 액세스 IAM 권한의 접근 키를 다룬다. 접근 키가 탈취되면 해당 리소스에 대한 제어가 탈취된다. 공식 문서에서는 최소 권한 원칙을 액세스 권한을 부여할 것을 권고한다. etcd에 대한 액세스 etcd 데이터베이스가 EKS 완전 관리형 컨트롤 플레인 내부에 숨겨져 있으며, 사용자는 etcd에 직접 액세스할 수 없다. etcd 암호화 기본적으로 EKS 클러스터를 생성할 때, etcd 데이터를 암호화하는 옵션을 선택할 수 있다. 이렇게 설정하면, 클러스터의 etcd 데이터는 AWS Key Management Service (KMS)에서 제공하는 고객 관리형 키 (CMK)를 사용하여 암호화되어 기밀성이 보장된다. - Cluster: 클러스터 계층에서는 쿠버네티스 클러스터 자체의 보안에 중점을 둔다. 클러스터 상의 중요한 서비스 A와 보안이 취약한 서비스 B에 대해 격리를 위한 계층이라고 보면 된다. 쿠버네티스에서는 격리에 방법으로 다양한 방법을 제안한다. 대표적으로 RBAC 인증, 네트워크 정책, 파드 보안 표준, 인그래스용 TLS 등이 있다.
항목 설명 RBAC 인증 역할(Role) 및 클러스터 역할(ClusterRole)을 사용하여 쿠버네티스 사용자와 서비스 계정에 권한을 부여하는 Role-Based Access Control 방식이다. 이를 통해 세분화된 권한 제어로 클러스터의 보안을 강화할 수 있다. 네트워크 정책 쿠버네티스 네트워크 정책은 특정 파드, 네임스페이스, 또는 IP 범위와 같은 소스로부터 들어오거나 나가는 트래픽을 허용하거나 차단하는 규칙을 정의한다. 이를 통해 네트워크 보안을 강화하고, 민감한 데이터를 처리하는 파드에 대한 접근을 제한할 수 있다. 파드 보안 표준 파드 보안 표준은 컨테이너와 파드가 안전하게 실행되도록 하는데 도움이 되는 일련의 보안 지침 및 구성이다. 예를 들어, 보안 컨텍스트(Security Context), 네트워크 폴리시, 리소스 제한, 파드 안티-어피니티 등을 사용하여 파드의 보안을 강화할 수 있다. 인그래스용 TLS 쿠버네티스 인그래스를 사용하여 클러스터 외부에서 내부 서비스로의 요청을 중앙 집중식으로 관리할 때, TLS(Transport Layer Security)를 사용하여 클라이언트와 서버 간 통신을 암호화하여 데이터를 보호할 수 있다. 인증서와 개인 키를 제공하고 호스트 이름과 인증서의 일치 여부를 확인해야 한다. - Container: 컨테이너 계층에서는 실행되는 워크로드에 직접적으로 영향을 주는 컨테이너에 초점을 맞춘다. 이 계층에서는 컨테이너 이미지 보안, 리소스 격리, 시크릿 관리 및 네트워크 정책을 포함된다. 여기에서는 보안 컨텍스트, 네트워크 폴리시, 컨테이너 런타임의 보안 기능(이미지 스캔) 등을 사용하여 컨테이너의 보안을 강화한다.
항목 설명 보안 컨텍스트 (Security Context) 쿠버네티스에서 컨테이너 또는 파드에 적용되는 보안 설정을 정의하는데 사용된다. 보안 컨텍스트를 사용하여 컨테이너의 파일 시스템에 대한 액세스 권한, 프로세스 ID, 사용자 ID, 그룹 ID 등을 제어할 수 있다. 이를 통해 컨테이너와 파드가 안전하게 실행되도록 할 수 있으며, 호스트 시스템과 다른 컨테이너로부터 분리되어 보안을 강화할 수 있다. 컨테이너 런타임의 보안 기능 컨테이너 런타임(예: Docker, containerd, CRI-O 등)은 컨테이너를 실행하고 관리하는데 사용되는 소프트웨어이다. 컨테이너 런타임은 다양한 보안 기능을 제공하여 컨테이너의 보안을 강화할 수 있다. 예를 들어, 컨테이너 런타임은 네임스페이스를 사용하여 컨테이너 프로세스를 격리할 수 있으며, cgroups을 사용하여 리소스 사용량을 제한하고, seccomp, AppArmor, SELinux와 같은 보안 프로파일을 적용하여 컨테이너의 시스템 호출을 제한할 수 있다. - Code: 코드 계층에서는 애플리케이션의 소스 코드 및 구성에 초점을 맞춘다. 이 계층에서는 애플리케이션의 취약점 및 보안 결함을 찾고 수정하여 워크로드의 보안을 향상시켜야 한다. 방법으로는 TLS 액세스, 통신 포트 제한, 종속성 보안, 정적 및 동적 소스 코드 분석, 의존성 스캔 및 안전한 코딩 기법 등이 있다.
항목 설명 통신 포트 제한 통신 포트 제한은 서버, 컨테이너, 애플리케이션 등이 사용하는 네트워크 포트를 제한하여 보안을 강화하는 방법이다. 불필요한 포트를 차단하고, 필요한 포트에 대해서만 허용하면 악의적인 공격자가 시스템에 액세스하는 것을 방지할 수 있다. 종속성 보안 종속성 보안은 애플리케이션에서 사용하는 외부 라이브러리 및 패키지에 대한 보안을 관리하는 방법이다. 취약한 종속성을 사용하면 시스템이 공격에 노출될 수 있다. 따라서, 종속성을 최신 상태로 유지하고, 보안 취약점이 발견될 경우 적절한 조치를 취하는 것이 중요하다. 정적 및 동적 소스 코드 분석 정적 소스 코드 분석은 코드를 실행하지 않고 소스 코드를 검사하여 보안 취약점을 찾는 방법이다. 동적 소스 코드 분석은 애플리케이션을 실행하면서 코드를 분석하여 보안 취약점을 찾는 방법이다. 이러한 분석 방법들을 사용하여 애플리케이션 코드의 보안 취약점을 발견하고 수정할 수 있다. 의존성 스캔 및 안전한 코딩 기법 의존성 스캔은 애플리케이션의 종속성에 대한 보안 취약점을 찾기 위한 도구를 사용하는 것이다. 안전한 코딩 기법은 개발자가 코드를 작성할 때 고려해야 하는 보안 지침 및 원칙이다. 이러한 기법을 사용하면 애플리케이션의 보안을 강화하고, 취약점을 줄일 수 있다.
보안적으로 신경써야할 요소가 많다. 위의 설명한 보안 기능들을 전부 다루면 좋겠지만 내용이 방대하다. 이번 블로그 글에서는 보안 툴인 kubescape를 이용하여 앞서 4C에서 Cluster, Container, Code 계층의 보안 검증 과정을 다뤄보겠다.
Kubescape
쿠버네티스 클러스터 보안 설정을 평가하고 검증하는 오픈 소스이다. NSA와 MITRE의 Kubernetes Hardening Guidance를 기반으로 작동하며 웹 대시보드를 통해 검증 및 취약점 점검을 할 수 있다. 또한, 도커 레지스트리, 이미지 취약점 스캔이 가능하다. 23년 4월 기준으로 업데이트가 계속 진행 중이며 공식 문서 또한 정리가 잘 되어 있다.
그렇지만 제한적인 요소도 존재한다. 클러스터를 ARMO 웹 대시보드로 연결해야한다는 점으로 온프레미스에서 도입시 고려해야 한다. 또한 프리티어 기준 워크 노드가 10개로 제한된다.
보안 기능을 전부 사용하려면 Operator 설치가 동반된다. 아키텍처는 다음과 같이 구성된다.
https://github.com/kubescape/helm-charts/blob/master/charts/kubescape-cloud-operator/README.md
- Master Gateway: ARMO 백엔드에서 실행 중인 마스터 게이트웨이이며 사용자가 등록한 모든 게이트웨이에 메시지를 브로드캐스트하여 모든 클러스터 게이트웨이에 런타임 작업을 전달한다.
- In-cluster Gateway: 클러스터 내에서 다른 구성 요소와 통신하기 위해 마스터 게이트웨이와 연결되며, 웹소켓(Websocket)을 사용하여 등록된다. 브로드캐스트 메세지를 전달받아 다른 컴포넌트에 전달한다.
- Operator : 트리거 엔진으로 게이트웨이에서 잔달받은 작업을 실행하거나 스케줄링하는 역할을 담당한다.
- Kubevuln : 컨테이너 이미지 취약점을 스캔하는 컴포넌트이다. 취약점 스캔은 grype을 통해 진행한다.
- Kubescape : 클러스터 내부 검증을 스캔하는 컴포넌트이다.
- Kollector : kubernetes API Server와 통신하여 클러스터 정보와 변경 정보를 확인하며 정보를 백엔드 CloudEndpoint로 전달한다.
설치
배포 환경 : kops 클러스터 (k8s 1.24), AWS Ubuntu 인스턴스
먼저 https://cloud.armosec.io/ 회원가입이 필요하다. 회원가입 이후 회원 ID 값에 맞게 helm 설치 명령어가 나온다. 복사하여 클러스터에 설치하자.
설치 이후 Verfiy installation 버튼을 누르면 아래와 같이 연결이 안된다고 나오나 kops 클러스터에서 설치했을 때의 버그같다.
아래와 같이 로그 확인 및 대시보드를 확인하면 정상적으로 등록이 되어 있다.
|
|
기능 확인
대시보드를 접속하면 왼쪽의 메뉴를 통해서 보안 검증이 가능하다.
- Compliance : 쿠버네티스 준수 정책 검증
- Vulnerabilities : 컨테이너 파드 취약점 점검
- RBAC Visualizer : RBAC 시각화
- Repository Scanning : 레파지토리 스캐닝
- Registry Scanning : 도커 레지스트리 스캐닝
Compliance
쿠버네티스 모범 사례를 체계화하여 수백 개의 항목들을 통해 클러스터 검증시켜주는 기능이다. 검증 항목은 MITRA 와 NSA 에서 제시하는 보안 가이드라인이며 웹 대시보드에서 프레임워크별 제어가 가능하다.
또한, 보안이 필요한 항목에는 fix버튼을 통해 구성적으로 확인이 가능하다.
아래는 필자 클러스터 환경에서 high 레벨 항목이며 몇 가지 항목 원인은 다음과 같다.
- C-0057(Privileged container) : 호스트 시스템의 모든 기능을 포함하는 컨테이너가 있어서 발생한 항목이다. 파드 구성 중
spec.container.securityContext.privileged == true일 때 발생한다. 필자의 경우 볼륨 관리 파드(ebs-csi-node) 에서 발생했다. - C-0045(Writable hostPath mount) : 쓰기 가능한 hostPath 볼륨으로 컨테이너를 생성했을 때 발생하는 알람이다. 설명에서는 이를 통해 호스트 볼륨의 정보를 얻을 수 있다 한다. 파드 구성 중
mount.readOnly == false이 됐을 때 발생한다. - C-0015 (kubernetes secret list) : 쿠버네티스 사용자가 시크릿에 대해 접근이 가능할 때 발생하는 알람이다.
- C-0041(HostNetwork access) : 호스트 네트워크에 연결할 경우 발생하는 알람이다. 필자의 경우 external-dns 파드에서 발생했다.
항목을 살펴보니 대부분 add-on 파드들에 대해 발생한 경고이다. 이러한 경우 ignore 로 알람 무시가 가능하다.
각 모범 사례 기준이 엄격하고 서드 파티 레벨의 애플리케이션의 구성 정보 확인시 검증 과정에서 유용하게 사용할 수 있을 것 같다.
Vulnerabilities
취약점 점검으로 배포 컨테이너들에 대해 취약점 점검을 진행한다. 취약점 점검은 grype 엔진을 통해 진행되며 CVE(Common Vulnerabilities and Exposures, 미국 NSA, CISA에서 제공하는 보안 가이드라인) 식별자로 검사가 진행된다.
위와 마찬가지로 필자의 클러스터에서 CRITICAL한 레벨의 취약점을 살펴보겠다.
-
GHSA-r48q-9g5r-8q2h(CVE-2022-1996) : emicklei/go-restful의 버전 3.8.0 이전에서 발견된 취약점이다. 사용자가 제어할 수 있는 키를 통해 권한을 우회할 수 있는 보안 문제가 있다고 한다. 한 가지 의문은 kubescape 내 파드인 kollector 에서 발생하는 것인데, 깃허브 이슈와 커밋에도 없는 사항이라 깃허브 이슈로 등록했다.
-
그 외에도 metrics-server, coredns 파드에서도 발생했으며 관련 깃 이슈를 공유한다. 대부분 해당 패키지 버전 업데이트로 피드백하며 업데이트하는 것 같다.
RBAC Visualizer
쿠버네티스 role 에 부여된 오브젝트 접근 제어 권한에 대해 시각화 기능을 제공해준다. 운영적으로 매력적인 기능이다. 아래 그림처럼 쿠버네티스 ServiceAccount 별로 접근 제어 목록을 한 눈에 확인할 수 있어 불필요한 권한 및 접근 제어에 대해 검증이 가능할 것 같다.
Repository scanning
코드 관리 저장소인 깃허브, 깃랩 등의 레파지토리에 스캐닝 검사를 시켜준다.
레파지토리 등록은 공식문서를 참고하자. 필자는 mac 환경에서 진행했다.
깃허브 토큰을 환경 변수로 등록하고, kubescape CLI 를 통해 취약점 검사 및 웹 대시보드로 정보를 전달한다.
|
|
- Location 은 저장소 URL 이다.
kubescape CLI 를 통해 검사하면 웹 대시보드에서 확인이 가능하다. 아래 화면은 필자의 깃허브 레파지토리를 등록해서 검사하였다.
레파지토리의 코드와 헬름 차트의 value 값들에도 취약점 검사가 진행된다.
필자의 레파지토리의 경우 C-0009(Resource limits) 항목이 많아 확인해보니 resource limit 설정 문제였다. 테스트 환경에서 진행함으로 리소스 제한을 풀었지만 운영 환경에서 도입시 파드 구성 환경에 따라 설정해야겠다.
Registry Scanning
이미지 레파지토리에도 검사가 가능하다. 하버에서도 이미지 취약점 점검이 가능하는 것으로 알고 있는데 차이점을 확인해보겠다. 기능 확인을 위해 하버를 클러스터에 설치하여 스캐닝 기능을 테스트하였다. 등록시 스캐닝 주기와 태그 개수를 설정할 수 있다.
시간별로 이미지 레파지토리에 취약 점검이 가능하다. 마찬가지로 grype 엔진을 통해 이미지 취약점 점검을 진행한다.
INTEGRATIONS
kubescape 툴은 Code, CI / CD 에도 활용이 가능하다.
https://github.com/kubescape/kubescape
공식문서를 확인하니 jenkins, gitlab CI / CD 에서도 job 스케쥴링으로 취약점 점검이 가능하다. CI / CD 파이프라인 구축 이후 고려해보도록 하자.
3rd party 애플리케이션 연동을 통해 알람 구성도 쉽게 가능하다. 슬랙에서도 알람 설정이 쉽게 가능한데, 스캐닝과 점검 레벨에 따라 알람 설정이 가능하다.
마치며
이번 블로그 글에서는 쿠버네티스 보안 계층과 보안 툴인 kubescape를 살펴보았다. 개인적으로 쿠버네티스의 보안 생태계를 경험하여 역량 향상에 도움이 되었다. 필자가 생각하기에 kubescape 툴은 미국 가이드라인의 사례나 취약점 점검과 grype 엔진을 통합해서 평가해주는 operator 툴 느낌이 강했다. 비즈니스 모델에 따라 달라지겠지만 비슷한 operator 툴을 대안으로 찾으면 좋을 것 같다.