2.4. CIS 벤치마크
어떨 때 보는가
- 보안 점검 결과를 보고해야 할 때
- 클러스터 설정이 보안 기준에 맞는지 확인할 때
- 감사 대응 자료가 필요할 때
CIS 란 무엇인가
CIS(Center for Internet Security)는 미국의 비영리 단체로, 시스템을 안전하게 설정하는 기준을 만들어 공개합니다. 운영체제, 데이터베이스, 클라우드 서비스 등 100여 종의 기준이 있고 Kubernetes 도 그중 하나입니다.
이 기준은 특정 제품 회사가 만든 것이 아니라 여러 조직의 보안 전문가가 함께 합의한 것 이라, 많은 나라의 보안 감사에서 근거로 인정됩니다.
CIS 벤치마크란
Kubernetes 용 CIS 기준을 CIS Kubernetes Benchmark 라고 합니다. 항목마다 세 가지가 적혀 있습니다.
| 구성 | 내용 |
|---|---|
| 무엇을 확인하는가 | 예: "API 서버가 익명 접근을 허용하지 않는지" |
| 왜 그래야 하는가 | 익명 접근을 허용하면 인증 없이 클러스터를 조작할 수 있습니다 |
| 어떻게 고치는가 | 설정 파일의 어느 항목을 무엇으로 바꾸는지 |
COP 는 이 기준에 맞는지 자동으로 점검 하고 결과를 화면에 보여 줍니다. 사람이 항목을 하나씩 확인할 필요가 없습니다.
왜 필요한가
Kubernetes 는 기본 설정이 편의 위주 입니다. 처음 설치했을 때 잘 돌아가게 하려고 여러 제약이 풀려 있습니다. 운영 환경에서는 이 제약을 다시 적용해야 합니다.
문제는 다시 적용해야 할 항목이 100개가 넘고, 어디를 어떻게 바꿔야 하는지 알기 어렵다는 것입니다. CIS 벤치마크는 그 목록과 방법을 제공합니다.
| 이 화면이 없으면 | 있으면 |
|---|---|
| 무엇을 점검해야 할지 모릅니다 | 항목이 정해져 있습니다 |
| 노드마다 직접 접속해 파일을 봐야 합니다 | 화면에서 한 번에 봅니다 |
| 감사 대응 자료를 손으로 만듭니다 | 결과를 그대로 씁니다 |
COP 는 설치할 때 이미 적용합니다
직접 설정을 바꿀 일은 없습니다. OPENMARU COP 은 설치 과정에서 CIS 프로파일을 켠 상태로 클러스터를 만들고, 벤치마크 항목에서 실패가 나지 않도록 미리 조치합니다.
| 구성 항목 | 적용 내용 |
|---|---|
| CIS 프로파일 | 클러스터를 CIS 기준 설정으로 기동합니다. 커널 값, 파일 권한, 구성요소 설정이 함께 조정됩니다 |
| 파드 보안 | Pod Security Admission 이 적용되어 과한 권한을 요구하는 파드가 거부됩니다 |
| 감사 로그 | 감사 정책을 설정해 API 서버 호출 기록을 남깁니다 |
| 서비스 어카운트 | 설치 시점에 있던 네임스페이스의 기본 계정에서 토큰 자동 마운트를 끕니다 (아래 주의) |
파드 보안이 실제로 걸립니다. 권한을 넘게 요구하는 파드는 만들어지지 않고 오류가 납니다. 직접 만든 파드가 거부되면 이 설정 때문일 수 있습니다(3.1 장).
그래서 이 화면의 결과는 처음부터 대부분 통과 상태 입니다. 확인해야 할 것은 통과 여부보다 시간이 지나면서 달라진 것이 없는지 입니다.
| 다시 확인해야 하는 때 | 이유 |
|---|---|
| 노드를 추가한 뒤 | 새 노드에 프로파일이 적용됐는지 |
| 네임스페이스를 새로 만든 뒤 | 아래 주의 참고 |
| 설정을 손으로 바꾼 뒤 | 조치가 풀렸을 수 있습니다 |
| 클러스터를 업그레이드한 뒤 | 기본값이 바뀌었을 수 있습니다 |
| 정기 감사 전 | 보고 자료로 씁니다 |
새로 만든 네임스페이스도 자동으로 처리됩니다
서비스 어카운트 토큰 자동 마운트 차단은 새 로 만드는 네임스페이스에도 적용됩니다. 따로 하실 일이 없습니다.
| 언제 만든 네임스페이스 | 어떻게 처리되나 |
|---|---|
| 설치할 때 만들어진 것 | 설치 과정에서 처리됩니다 |
| 제품이 나중에 만드는 것 | 만드는 즉시 처리됩니다. 파드가 올라오기 전이라 토큰이 붙지 않습니다 |
| 직접 만드신 것 | 10분 안에 자동으로 처리됩니다 |
기다리지 않고 바로 적용하려면 지금 한 번 실행하십시오.
kubectl create job --from=cronjob/sa-hardening sa-hardening-now -n openmaru-kube-bench
무엇이 처리됐는지는 로그로 확인합니다.
kubectl logs -n openmaru-kube-bench -l job-name --tail=20
이미 실행 중이던 파드는 다시 띄워야 합니다
토큰을 넣을지 말지는 파드가 만들어질 때 정해집니다. 그래서 네임스페이스를 만들고 파드를 먼저 띄운 뒤라면, 그 파드는 다시 뜨기 전까지 토큰을 그대로 들고 있습니다.
제품이 임의로 재시작하지는 않습니다. 운영 중인 워크로드를 예고 없이 내리면 안 되기 때문입니다. 대신 해당 네임스페이스를 로그로 알려 드립니다.
[sa-hardening] 주의: my-app 에 default ServiceAccount 를 쓰는 파드가 3개 있습니다.
[sa-hardening] 이미 마운트된 토큰은 파드를 다시 띄워야 빠집니다:
[sa-hardening] kubectl rollout restart deployment,daemonset,statefulset -n my-app
정비 시간에 안내된 명령을 실행하시면 됩니다.
애플리케이션이 API 서버에 접근해야 한다면
기본 계정을 쓰지 마시고 전용 서비스 어카운트를 만들어 필요한 권한만 주십시오. 기본 계정에 권한을 붙이면 그 네임스페이스의 모든 파드가 같은 권한을 갖게 됩니다.
파드 쪽에서 개별로 끄는 방법도 있습니다. 네임스페이스 설정과 무관하게 그 파드에는 토큰이 들어가지 않습니다.
spec:
automountServiceAccountToken: false
무엇을 점검하지 않는가
점검 대상은 클러스터 설정입니다. 다음은 이 화면에서 다루지 않습니다.
| 대상 | 어디에서 |
|---|---|
| 컨테이너 이미지의 취약점 | 이미지 저장소(Harbor)의 스캔 기능 |
| 애플리케이션 코드의 취약점 | 별도 코드 분석 도구 |
| 접근 권한 설정이 적절한지 | 사람이 판단합니다 (7.1 장) |
| 네트워크 정책이 충분한지 | 사람이 판단합니다 (5.1 장) |
CIS 벤치마크를 모두 통과해도 애플리케이션이 안전하다는 뜻은 아닙니다. 클러스터라는 기반이 기준에 맞다는 뜻입니다.
점검 대상 네 가지
| 대상 | 점검 내용 | 어디에서 도는가 |
|---|---|---|
| Control Plane | API 서버·스케줄러·컨트롤러 매니저의 실행 옵션과 파일 권한 | 관리 노드 |
| etcd | 클러스터 데이터 저장소의 접근 제어와 암호화 | 관리 노드 |
| Worker Node | kubelet 설정, 인증서 파일 권한 | 작업 노드 |
| Policies | 접근 권한(RBAC), 네트워크 정책, 파드 보안 설정 | 클러스터 전체 |
etcd 항목이 특히 중요합니다. etcd 에는 클러스터의 모든 정보가 들어 있고 Secret 도 여기에 저장됩니다. 접근 제어가 뚫리면 클러스터 전체가 뚫린 것과 같습니다.
점검 결과 확인
클러스터 > CIS 벤치마크 로 들어갑니다.
대상별로 통과·실패 개수가 나오고, 항목을 누르면 자세한 내용이 보입니다.
노드가 여러 대면 노드별로 결과가 나옵니다. 같은 항목이 어떤 노드에서는 통과하고 어떤 노드에서는 실패하면 그 노드만 설정이 다른 것이므로 먼저 확인하십시오.
항목 상태 읽기
| 상태 | 뜻 | 해야 할 일 |
|---|---|---|
| PASS | 기준을 만족합니다 | 없음 |
| FAIL | 기준에 맞지 않습니다 | 조치를 검토합니다 |
| WARN | 자동으로 판단할 수 없습니다 | 사람이 직접 확인합니다 |
| INFO | 참고 항목 | 없음 |
WARN 을 넘기지 마십시오. 점검 도구가 판단할 수 없다는 뜻이지 안전하다는 뜻이 아닙니다.
WARN 이 나오는 이유는 대개 이렇습니다.
- 조직 정책에 따라 답이 달라지는 항목 (예: "감사 로그를 몇 일 보관해야 하는가")
- 도구가 읽을 수 없는 위치에 설정이 있는 경우
- 판단에 외부 정보가 필요한 항목
항목 하나를 읽는 법
항목을 누르면 이런 내용이 나옵니다.
| 요소 | 예 | 쓰임 |
|---|---|---|
| 번호 | 1.2.7 | 보고서에 그대로 씁니다 |
| 제목 | "API 서버의 익명 인증 비활성화" | 무엇을 점검했는지 |
| 결과 | FAIL | |
| 조치 방법 | 설정 파일의 어느 값을 어떻게 바꾸는지 | 운영 담당자에게 전달 |
번호는 CIS 기준의 고유 번호입니다. 감사 보고서나 기술 지원 문의에는 번호를 그대로 쓰십시오. 설명을 옮겨 적으면 어느 항목인지 헷갈립니다.
FAIL 을 다루는 법
FAIL 항목은 대부분 클러스터 설정 파일을 고쳐야 합니다. 이 작업은 노드에 접속해야 하므로 운영 담당자가 수행합니다.
전달할 때는 이 세 가지를 함께 주십시오.
- 항목 번호 (예:
1.2.7) - 항목 제목
- 화면에 나온 조치 방법
설정을 바꾸면 해당 구성요소가 다시 시작됩니다. 관리 노드 설정은 클러스터 API 가 잠시 멈출 수 있으므로 점검 시간을 정해 진행하십시오. 이미 떠 있는 파드는 계속 동작합니다.
모두 통과할 필요는 없다
모든 항목을 PASS 로 만드는 것이 목표가 아닙니다.
운영 환경에서 쓸 수 없는 설정이 있습니다. 예를 들어 어떤 항목은 특정 기능을 아예 끄라고 권하는데, 그 기능이 서비스에 필요하면 끌 수 없습니다.
| 판단 기준 | 설명 |
|---|---|
| 조직의 보안 정책 | 정책이 요구하는 항목부터 |
| 위험도 | 외부 노출·권한 상승과 관련된 항목 우선 |
| 운영 영향 | 서비스가 멈추는 변경은 신중하게 |
대상 항목을 정하고, 제외한 항목은 왜 제외했는지 기록해 두십시오. 감사에서는 통과율보다 판단 근거를 봅니다. "이 항목은 A 기능이 필요해 적용하지 않았고, 대신 B 로 위험을 낮췄다" 는 설명이 있으면 됩니다.
보고서 내려받기
화면에서 항목을 하나씩 펼쳐 보는 것으로는 감사 자료가 되지 않습니다. 결과 전체를 파일로 남겨야 제출하고 보관할 수 있습니다.
화면 오른쪽 위 CIS 벤치마크 보고서 를 누릅니다.
보고서에 담기는 것
내려받기 전에 화면에서 내용을 먼저 확인합니다. 순서대로 다음이 들어 있습니다.
| 구성 | 내용 |
|---|---|
| 머리말 | 생성일시, 클러스터 이름, 벤치마크 프로파일, 전체 노드 수와 성공·실패 노드 수 |
| 상태 설명 | PASS·FAIL·WARN·INFO 각각의 뜻 |
| 요약 | 관리(Master) 노드와 워커(Worker) 노드로 나눈 노드별 상태 개수 표 |
| 관리 노드 점검 결과 | 1·2·3·5 절 항목을 노드별로 표시 |
| 워커 노드 점검 결과 | 4 절 항목을 노드별로 표시 |
| 조치 방법 | 통과하지 못한 항목의 조치 방법 모음 |
| 수집 실패 노드 | 결과를 가져오지 못한 노드가 있을 때만 표시 |
요약 표는 노드를 열로 놓습니다. 같은 항목이 어떤 노드에서만 실패하는지 표 한 장에서 바로 보입니다. 화면에서 노드를 하나씩 펼쳐 세는 것보다 빠릅니다.
보고서 언어는 콘솔 언어를 따릅니다. 한국어로 쓰고 있으면 한국어 보고서가, 영어면 영어 보고서가 나옵니다. 제출 대상에 맞춰 언어를 먼저 바꾼 뒤 내려받으십시오(9.4 장).
형식 세 가지
보고서 창 오른쪽 위 세 버튼으로 내려받습니다. 형식마다 쓰임이 다릅니다.
| 버튼 | 파일 | 어디에 쓰는가 |
|---|---|---|
| JSON | kube-bench-results.json | 점검 결과 원본. 다른 도구에 넣거나 이전 결과와 자동으로 비교할 때 |
| Markdown | kube-bench-results.md | 문서에 붙여 넣거나 형상 관리에 넣어 이력을 남길 때 |
| HTML | kube-bench-report-<날짜시각>.html | 그대로 열어 보거나 인쇄·PDF 로 만들어 제출할 때 |
제출용은 HTML 이 편합니다. 표 서식이 그대로 들어간 파일 하나로 나오고, 별도 프로그램 없이 웹 브라우저로 열립니다. 브라우저의 인쇄 기능으로 PDF 를 만들면 그대로 감사 자료가 됩니다. HTML 파일 이름에는 내려받은 시각이 들어가므로 여러 번 받아도 서로 덮어쓰지 않습니다.
이력을 남길 목적이면 JSON 을 함께 보관하십시오. HTML 과 Markdown 은 사람이 읽는 형식이라 두 시점을 기계로 비교하기 어렵습니다. JSON 은 항목 번호와 상태가 그대로 들어 있어 지난 점검과 무엇이 달라졌는지 자동으로 뽑을 수 있습니다.
파일을 다룰 때 주의할 것
보고서에는 클러스터 구성 정보가 들어 있습니다. 노드 이름, 설정 파일 경로, 통과하지 못한 항목과 그 조치 방법이 그대로 담깁니다. 통과하지 못한 항목 목록은 공격자에게 유용한 정보입니다. 외부에 전달할 때는 받는 사람과 전달 경로를 확인하고, 사내 문서 보관 규칙에 따라 관리하십시오.
언제 내려받는가
| 시점 | 이유 |
|---|---|
| 점검을 실행한 직후 | 결과는 다시 실행하면 덮어써집니다 |
| 설정을 고치기 전 | 고치기 전 상태를 남겨 두어야 무엇이 달라졌는지 알 수 있습니다 |
| 감사 제출 전 | 제출 시점의 결과여야 합니다 |
| 노드 추가·업그레이드 뒤 | 이전 보고서와 비교해 새로 생긴 항목을 찾습니다 |
점검 주기
다음 시점에 다시 확인하십시오.
| 시점 | 이유 |
|---|---|
| 클러스터를 처음 구축한 뒤 | 기본 설정이 남아 있습니다 |
| 노드를 추가한 뒤 | 새 노드만 설정이 다를 수 있습니다 |
| 클러스터를 업그레이드한 뒤 | 기본값이 바뀌었을 수 있습니다 |
| 정기 감사 전 | 보고 자료로 씁니다 |
결과를 시점별로 남겨 두면 무엇이 언제 바뀌었는지 알 수 있습니다. 클러스터 진단으로 함께 수집해 두는 방법도 있습니다(2.3 장).