[Study][Amazon EKS] EKS Security - kube-bench

EKS Security

EKS의 경우 AWS에서는 보안에 대한 책임을 AWS와 고객의 공동 책임이라고 설명한다.
자체 관리형 노드와 AWS Fargate를 사용하는 Amazon EKS에 대한 AWS 공동 책임 모델을 보면 모두 Master Node에 대한 책임은 AWS에서 담당하는 것을 볼 수 있다.

출처 : https://aws.github.io/aws-eks-best-practices/security/docs/#understanding-the-shared-responsibility-model

일반적인 Kubernetes에 비해 보안적 부담이 덜한 셈이지만 어떤 부분이 취약한지, 보안을 강화하기 위한 기준이 어떤 것인지 사용자 입장에서는 어려울 수 있다.

스터디에서는 Kubernetes 인증과 인가, 권한 부분에 대한 실습을 통해 기술적인 공부를 진행했기에,
블로그에서는 EKS 보안의 기준과 EKS 보안을 강화하는데 좀 더 간편한 방법 또는 도구가 있는지에 대해 공부해보고 정리해보았다.

https://www.redhat.com/ko/topics/containers/intro-kubernetes-security

쿠버네티스 보안 소개

RedHat 공식 사이트에서 Kubernetes 보안에 대한 큰 분류와 안내를 제공하고 있는데,
해당 사이트에서 CIS(Center for Internet Security) BenchMark에 대한 정보를 확인할 수 있었다.

 

CIS(Center for Internet Security)란?

CIS는 2000년에 설립된 비영리 단체로, 사이버 보안 전문가 커뮤니티를 지원하고 사이버 보안을 개선하기 위한 노력을 돕는 것을 목표로 합니다. CIS는 IT 시스템, 소프트웨어, 네트워크 및 클라우드 인프라를 안전하게 구성하기 위한 베스트 프랙티스를 제공하는 CIS 벤치마크를 개발하고 유지 관리합니다. CIS는 또한 사이버 보안 교육, 연구 및 인증 프로그램을 제공합니다.

 

AWS에서도 Security Hub를 통해서 CIS 벤치마크와 연계된 서비스를 제공하고 있다.

AWS Security Hub는 14개의 AWS 서비스에 걸쳐 43개의 컨트롤과 32개의 Payment Card Industry Data Security Standard(PCI DSS) 요구 사항으로 구성된 CIS AWS Foundations Benchmark 표준을 지원합니다. 활성화되는 즉시, AWS Security Hub가 각 컨트롤 및 컨트롤과 연결된 각 관련 리소스에 대해 지속적인 자동 보안 검사를 실행하기 시작합니다.

출처 : https://aws.amazon.com/ko/what-is/cis-benchmarks/

 

CIS Benchmark 목록

https://www.cisecurity.org/cis-benchmarks 사이트에서 간단한 이메일과 양식을 작성하면 이메일로 CIS Benchmark PDF 문서를 받을 수 있는 아래의 링크를 제공해준다.

• CIS Benchmark PDFs : https://downloads.cisecurity.org/

해당 사이트에서 다양한 분야의 IT에 대한 보안 표준을 확인할 수 있으며, Kubernetes에서 EKS 뿐만 아니라 AKS, GKE에 대한 표준도 제공하고 있었다.

 

가장 최신의 문서를 읽어보면 AWS Fargate는 Node에 대한 관리를 하지 않으므로 해당 표준 지침의 대상이 아니라고 설명한다.

 

해당 문서를 포함해서 몇가지 문서를 더 읽어봤는데 CIS 벤치마크는 프로필 정의를 통해서 보안 레벨을 구분하고 있었다.

• 레벨 1 프로필
  IT 시스템을 구성하기 위한 기본 보안 권장 사항입니다. 이러한 권장 사항은 따르기 쉽고 비즈니스 기능이나 가동 시간에 영향을 미치지 않습니다. 이 권장 사항은 IT 시스템의 진입점 수를 줄여 사이버 보안 위험을 최소화합니다.
• 레벨 2 프로필
  레벨 2 프로필 구성 권장 사항은 보안이 최우선인 매우 민감한 데이터에 가장 적합합니다. 이 권장 사항을 구현하려면 최소한의 운영 중단으로 포괄적인 보안을 실현하기 위한 실무 전문 지식과 사전 계획이 필요합니다. 레벨 2 프로필 권장 사항을 구현하면 규정 준수 실현에도 도움이 됩니다.
  
  
• STIG 프로필
  Security Technical Implementation Guide(STIG)는 Defense Information Systems Agency(DISA)가 제시하는 일련의 구성 기준입니다. 이 보안 표준은 미 국방부에서 게시하고 유지 관리합니다. STIG는 미국 정부의 요건을 충족할 수 있도록 특별히 작성되었습니다. 

STIG 프로필의 경우 미 국방부에 납품을 하거나 연관된 조직일 경우 준수해야하는 보안 지침이자 구성 표준으로 특별한 경우가 아니면 STIG까지 준수할 필요는 없어 보인다.
참고로 AWS에서도 STIG를 적용한 AMI를 별도로 제공한다. (https://aws.amazon.com/marketplace/pp/prodview-i3vkpa6e3rfk6)

 

(참고자료) STIG 란?

STIG(Security Technical Implementation Guide)는 미 국방성의 DISA(Defense Information Systems Agency)에서 생성한 구성 표준이다. DISA에서는 다음과 같은 범주로 알려진 3가지 수준의 규정 준수 위험을 정의한다.

• 범주 I - 최고 수준의 위험 가장 심각한 위험을 다루며 기밀성, 가용성 또는 무결성의 손실을 초래할 수 있는 모든 취약성을 포함
• 범주 II - 중간 위험
• 범주 III - 낮은 위험

 

EKS용 CIS 벤치마크 문서를 읽다가 내용이 너무 많아서 하나씩 찾아서 검증해보기가 어려웠는데,
이를 자동화해주는 kube-bench라는 도구를 찾았다.

 

Kube-Bench 도구란?

GO언어로 작성된 CIS Kubernetes Benchmark 항목 검사를 자동으로 수행해주는 도구이다.

https://github.com/aquasecurity/kube-bench

GitHub - aquasecurity/kube-bench: Checks whether Kubernetes is deployed according to security best practices as defined in the C

• kube-bench는 CIS Kubernetes Benchmark를 최대한 가깝게 구현한다고 한다.
• YAML로 제공되어 간단하게 설치 및 업데이트할 수 있다.
• 당연하지만 GKE, EKS, AKS 및 ACK와 같은 관리형 클러스터의 Master Node는 검사가 불가능하다.
• Kubernetes 버전 별로 CIS 벤치마크 버전이 다르다.
  https://github.com/aquasecurity/kube-bench/blob/main/docs/platforms.md#cis-kubernetes-benchmark-support

 

 

Kube-Bench 사용해보기

Kube-Bench 설치 및 구동

설치 및 구동 방법은 정말로 간단하다.
일반적인 Kubernetes 환경이라면 container로 docker run을 통해서 실행하는 방법과 yaml을 통해서 cluster에 Pod를 생성해서 실행할 수 있다.

EKS의 경우는 전용 YAML을 제공하니 해당 파일을 통해서 Pod를 생성하면된다.

• https://github.com/aquasecurity/kube-bench/blob/main/docs/running.md#running-cis-benchmark-in-an-eks-cluster

# git clone으로 yaml 파일 다운로드
(test_admin@myeks:default) [root@myeks-bastion ~]# git clone https://github.com/aquasecurity/kube-bench.git
Cloning into 'kube-bench'...
remote: Enumerating objects: 5338, done.
remote: Counting objects: 100% (163/163), done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 5338 (delta 91), reused 104 (delta 48), pack-reused 5175
Receiving objects: 100% (5338/5338), 9.19 MiB | 15.23 MiB/s, done.
Resolving deltas: 100% (3386/3386), done.

(test_admin@myeks:default) [root@myeks-bastion ~]# cd kube-bench/
(test_admin@myeks:default) [root@myeks-bastion kube-bench]# ls -rlt *eks*
-rw-r--r-- 1 root root 1273 Jun  4 01:08 job-eks.yaml
-rw-r--r-- 1 root root 1239 Jun  4 01:08 job-eks-stig.yaml
-rw-r--r-- 1 root root 2201 Jun  4 01:08 job-eks-asff.yaml


# eks-1.2.0을 eks-1.1.0으로 변경
# 현재 최신 CIS benchmark 버전은 eks-1.2.0이지만 이대로 적용하면 아래의 에러가 발생한다.
# 아마도 작성일 기준으로 약 2주전에 commit되면서 dockerhub 이미지가 제대로 반영이 안된 것 같다.
# https://github.com/aquasecurity/kube-bench/issues/1448
# 만약 1.2.0을 사용하고 싶으면 아래의 링크에서 가이드하는 대로 Docker image를 빌드해서 push 하고 사용하면 된다.
# https://github.com/aquasecurity/kube-bench/blob/main/docs/running.md#running-cis-benchmark-in-an-eks-cluster
(test_admin@myeks:default) [root@myeks-bastion kube-bench]# kubectl logs kube-bench-h2zfh

error validating targets: No targets configured for eks-1.2.0

(test_admin@myeks:default) [root@myeks-bastion kube-bench]# cat job-eks.yaml | grep eks-1
              "eks-1.2.0",
(test_admin@myeks:default) [root@myeks-bastion kube-bench]# sed -i 's/eks-1.2.0/eks-1.1.0/g' job-eks.yaml
(test_admin@myeks:default) [root@myeks-bastion kube-bench]# cat job-eks.yaml | grep eks-1
              "eks-1.1.0",


# job-eks.yaml 적용 후 Pod 확인
(test_admin@myeks:default) [root@myeks-bastion kube-bench]# kubectl apply -f job-eks.yaml 
job.batch/kube-bench created

 

Kube-Bench 보고서 조회

# 실행한 kube-bench Pod 이름 조회
(test_admin@myeks:default) [root@myeks-bastion kube-bench]# kubectl get pod
NAME               READY   STATUS      RESTARTS   AGE
kube-bench-g9826   0/1     Completed   0          7s


# 분석 결과 확인
# 실행 완료된 Pod의 이름으로 log를 조회하면 된다.
# kubectl logs `kubectl get pods -o=jsonpath='{.items[?(@.metadata.labels.job-name=="kube-bench")].metadata.name}'`
(test_admin@myeks:default) [root@myeks-bastion kube-bench]# kubectl logs kube-bench-g9826
[INFO] 3 Worker Node Security Configuration
[INFO] 3.1 Worker Node Configuration Files
[PASS] 3.1.1 Ensure that the kubeconfig file permissions are set to 644 or more restrictive (Manual)
...
[WARN] 3.3.1 Prefer using Container-Optimized OS when possible (Manual)

== Remediations node ==
3.2.9 If using a Kubelet config file, edit the file to set eventRecordQPS: to an appropriate level.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service on each worker node and
set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service

3.3.1 audit test did not run: No tests defined

== Summary node ==
14 checks PASS
0 checks FAIL
2 checks WARN
0 checks INFO

== Summary total ==
14 checks PASS
0 checks FAIL
2 checks WARN
0 checks INFO


# cron job 또는 주기적인 실행으로 보안 점검과 간단한 보고서 파일을 생성할 수 있다.
kubectl logs kube-bench-<value> > kube-bench-report.txt

결과는 PASS, FAIL, WARN, INFO 4개로 이루어지며 각 의미는 다음과 같다.

• PASS / FAIL : 점검이 성공적으로 수행되었으며, 보안 기준에 따라 통과, 실패를 의미한다.
• WARN : 테스트에 추가 확인이 필요함을 의미한다. 예를 들어 수동으로 실행해야하는 테스트 등을 알려준다.
• INFO : 별다른 조치가 필요하지 않는 단순 정보 출력이다.

WARN과 FAIL이 발생하면 Remediations 구간에서 어떤식으로 조치해야하는지 가이드를 안내해준다.

 

EKS kube-bench 종류

github 프로젝트에 보면 EKS에 대한 3가지 yaml을 제공한다.

• job-eks.yaml : 기본적인 CIS 1,2 레벨의 보안 기준에 대한 점검을 수행한다.
• job-eks-stig.yaml : STIG 기준에 맞춰 점검을 수행한다. 점검 결과도 STIG 항목 번호에 맞춰서 출력된다.
  - STIG 항목 참고 : https://www.stigviewer.com/stig/kubernetes/
• job-eks-asff.yaml : job-eks.yaml 검사에 추가로 AWS Security Hub에 보안 취약성 검사 결과를 전송한다.
  - AWS Security Hub : 보안 취약성 검사 결과를 수집하고, 분석하고, 보고하는 데 사용할 수 있는 서비스
  - Integrating kube-bench with AWS Security Hub : https://aquasecurity.github.io/kube-bench/dev/asff/

 

테스트 후기

굉장히 편리하고 무료라는 점이 좋았는데, 생각보다 취약점을 잘 찾아주지는 않는 것 같았다.
GuardDuty에서 제공하는 취약점 테스트 등을 수행해봤는데 CIS BenchMark에는 포함되지 않는건지 보고서에 나오지 않았다.
최신 버전으로 계속 업데이트되고 있고, STIG YAML의 경우는 굉장히 다양하게 취약점을 점검해주니 STIG 쪽으로 점검을 수행해보면 꽤 쓸만하다고 생각이 들었다.
(만약 EKS가 아닌 일반적인 Kubernetes라면 kube-bench를 충분히 활용해 볼 만하다고 생각한다.)

 

 

참고자료

• CIS 벤치마크란 무엇인가요? : https://aws.amazon.com/ko/what-is/cis-benchmarks/
• Checklist Kubernetes STIG - NCP : https://ncp.nist.gov/checklist/996
• CIS Kubernetes Benchmarks : https://www.cisecurity.org/benchmark/kubernetes
• Introducing The CIS Amazon EKS Benchmark : https://aws.amazon.com/ko/blogs/containers/introducing-cis-amazon-eks-benchmark/