Certified Kubernetes Security Specialist (CKS) #19 시험 팁과 시간 관리, 자주 틀리는 패턴

#1부터 #18까지 6개 도메인을 모두 정리했습니다. 이 글은 실기 시험에 들어가기 직전 한 번 더 읽고 갈 압축본입니다. 새로운 도메인은 없고, 2시간 실기를 어떻게 운영하는지와 시리즈 전체에서 보안 작업이 가장 자주 점수를 흘리는 함정만 모았습니다. 객관식이 아니라 실제 클러스터를 빈 터미널에서 더 안전하게 바꾸는 시험이라, 같은 지식이라도 운영이 합격과 불합격을 가릅니다.

2시간 운영 전략 #

작업 단위 운영 #

CKS는 약 15〜20개 작업을 2시간 안에 풀어야 합니다. 객관식처럼 문항당 균등하게 시간을 나누는 것이 아니라, 작업마다 배점이 화면에 표시되므로 그 배점이 곧 우선순위입니다. CKS의 특징은 작업마다 요구하는 도구가 다르다는 점입니다. 한 작업은 AppArmor를, 다음 작업은 Trivy를, 그다음은 Falco 규칙을 다루는 식이라, 손에 익지 않은 도구를 만나면 한 작업에서 통째로 막히기 쉽습니다.

시간 관리의 첫 번째 룰 #

한 작업에 과몰입하지 않습니다. 배점에 비해 시간이 오래 걸린다 싶으면 일단 가능한 데까지 만들어 두고 flag 후 넘어갑니다. 합격선은 67%이므로 어려운 한두 작업을 포기해도 됩니다. 처음 보는 도구 작업 하나를 붙들다가 손에 익은 NetworkPolicy,RBAC 작업 두세 개를 놓치는 것이 가장 흔한 실패입니다.

손에 익은 도구부터 #

CKS는 도구별 시험이라 작업마다 난이도 편차가 큽니다. 작업 목록을 처음부터 끝까지 한 번 훑으면서 배점 대비 난이도를 머릿속으로 표시합니다. NetworkPolicy default deny, RBAC 최소 권한, PSA label처럼 절차가 정해지고 손에 익은 작업을 먼저 처리해 점수를 빠르게 쌓습니다. AppArmor 프로파일 노드 로드, seccomp 경로 지정, Falco 규칙 작성처럼 손이 많이 가거나 노드 안에서 풀어야 하는 작업을 중간에 배치하는 운영이 합격선을 넘기는 길입니다.

셋업 재정리 #

#1에서 잡은 셋업을 시험 시작 직후 1분 안에 끝냅니다. CKS도 kubectl로 푸는 작업이 적지 않으므로, CKA,CKAD와 동일한 속도 셋업이 그대로 점수가 됩니다.

# kubectl을 k로
alias k=kubectl

# dry-run + YAML 출력을 do로
export do="--dry-run=client -o yaml"

# 즉시 삭제를 now로 (Pod를 빠르게 지우고 다시 만들 때)
export now="--force --grace-period=0"

# 자동완성 (k 까지 확장)
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

~/.vimrc에는 YAML 들여쓰기 사고를 막는 설정을 넣습니다. CKS는 seccomp,AppArmor 경로나 securityContext 필드처럼 한 칸만 어긋나도 적용이 안 되는 매니페스트를 자주 편집하므로 더 중요합니다.

set expandtab
set tabstop=2
set shiftwidth=2
set number

YAML 블록을 통째로 들여쓰기할 때는 비주얼 모드(V)로 줄을 선택한 뒤 >로 한 단계 들이고, .으로 반복합니다. 문서에서 securityContext나 PSA label 스니펫을 복사해 붙일 때는 자동 들여쓰기가 간섭하므로 붙여 넣기 직전 :set paste를 켭니다.

context 전환을 가장 먼저 한다 #

CKS도 CKA와 마찬가지로 클러스터가 여러 개이고, 각 작업은 지정된 클러스터에서 풀어야 채점됩니다. 작업 설명 맨 위에 제시되는 use-context 명령을 먼저 실행하지 않으면, 프로파일을 맞게 만들거나 정책을 옳게 적용해도 다른 클러스터에서 작업해 0점입니다.

# 작업마다 가장 먼저 실행
k config use-context <작업에서 지정한 컨텍스트>

# 지금 어느 클러스터인지 확인
k config current-context

CKS는 노드 안으로 들어가는 작업의 비중이 CKA보다 큽니다. AppArmor 프로파일 로드, seccomp 프로파일 파일 배치, kernel 파라미터 조정, Falco 설치,규칙 수정 같은 작업은 지정된 노드에 SSH로 들어간 뒤에 풀어야 합니다. control plane 노드에서 해야 할 작업을 워커 노드에서 하면 점수가 없습니다.

# 작업에서 제시하는 호스트명으로 접속
ssh node01

# 작업이 끝나면 반드시 빠져나와 원래 환경으로
exit

SSH로 노드에 들어간 채 다음 작업을 풀기 시작하는 실수가 흔합니다. 노드 작업이 끝나면 exit로 빠져나오는 것을 한 동작으로 묶어 두는 습관이 오답을 막습니다. 노드에 들어간 상태에서 kubectl 작업을 시작하면 엉뚱한 환경에 만들어집니다.

공식 문서를 빠르게 활용한다 #

CKS는 시험 중 kubernetes.io/docs뿐 아니라 Falco,Trivy,AppArmor,gVisor 같은 지정 도구의 공식 문서 열람이 허용됩니다. 보안 도구는 문법과 옵션이 길고 외우기 어려우므로, 문서 활용이 CKA보다 더 결정적입니다. 다만 운영에 두 가지 원칙이 있습니다.

• 문서 위치를 미리 익힌다. 시험장에서 처음 문서 구조를 파악하면 시간을 통째로 잃습니다. seccomp 프로파일 예시가 kubernetes.io의 어느 페이지에 있는지, Falco 규칙 문법이 falco.org 문서의 어디에 있는지, Trivy 심각도 옵션과 AppArmor 프로파일 문법이 각 문서 어디에 있는지를 평소에 손에 익혀 두겠습니다.
• 문서 시간도 시험 시간. 문서를 뒤지는 동안에도 타이머는 흐릅니다. NetworkPolicy,RBAC처럼 generator나 외운 패턴으로 즉시 만들 수 있는 작업은 문서를 열지 않고, 문서는 프로파일 문법이나 도구 옵션처럼 외우기 어려운 부분만 확인하는 용도로 씁니다.

문서에서 YAML 스니펫을 복사할 때는 들여쓰기가 따라오므로, 붙여 넣은 직후 :set paste로 자동 들여쓰기 간섭을 끄는 것이 안전합니다.

자주 틀리는 패턴 #

보안 실기에서 점수를 흘리는 단골 패턴입니다. 지식 부족보다 운영 실수와 도구별 절차 누락으로 잃는 점수가 더 많습니다.

1) context와 namespace 미전환 #

각 작업은 지정된 클러스터와 네임스페이스에서 풀어야 채점됩니다. 작업 설명에 제시되는 use-context 명령을 먼저 실행하지 않으면, 답을 맞게 만들어도 다른 클러스터에서 작업해 0점입니다. CKS는 클러스터가 여러 개라 이 실수가 특히 잦습니다.

k config use-context <작업에서 지정한 컨텍스트>
k config set-context --current --namespace=<작업 네임스페이스>

2) AppArmor 프로파일 노드 로드 누락 #

AppArmor 작업에서 가장 흔한 실점입니다. 프로파일을 매니페스트에 참조만 걸고 해당 노드에 프로파일을 로드하지 않으면 Pod가 뜨지 못하거나 강제가 적용되지 않습니다. 프로파일 파일을 노드에 배치한 뒤 apparmor_parser로 커널에 로드하고, Pod의 securityContext에서 그 프로파일을 참조해야 한 작업이 완성됩니다.

# 지정된 노드에서: 프로파일을 커널에 로드
ssh node01
sudo apparmor_parser -q /etc/apparmor.d/custom-profile
# 로드 상태 확인
sudo aa-status | grep custom-profile
exit

# Pod securityContext에서 로드된 프로파일 참조
securityContext:
  appArmorProfile:
    type: Localhost
    localhostProfile: custom-profile

3) seccomp 프로파일 경로 혼동 #

seccomp 프로파일은 kubelet의 seccomp 루트 디렉터리 기준 상대 경로로 지정합니다. 기본 루트는 /var/lib/kubelet/seccomp이며, 프로파일 파일을 이 디렉터리 아래에 두고 localhostProfile에는 그 루트 기준 상대 경로만 적습니다. 절대 경로를 적거나 파일을 엉뚱한 위치에 두면 Pod가 뜨지 못합니다.

# 프로파일을 kubelet seccomp 루트 아래에 배치
sudo mkdir -p /var/lib/kubelet/seccomp/profiles
sudo cp audit.json /var/lib/kubelet/seccomp/profiles/audit.json

# 루트(/var/lib/kubelet/seccomp) 기준 상대 경로만 기입
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/audit.json

4) PSA label 오타와 모드 혼동 #

Pod Security Admission은 네임스페이스 label로 제어합니다. label 키의 접두사(pod-security.kubernetes.io/), 모드(enforce,audit,warn), 레벨(privileged,baseline,restricted)을 정확히 적어야 합니다. 키를 한 글자라도 틀리면 admission이 동작하지 않고, enforce를 써야 할 자리에 warn만 걸면 위험한 Pod가 그대로 통과해 점수가 없습니다.

k label ns prod \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

5) etcd 암호화 후 재암호화 누락 #

etcd 저장 데이터 암호화는 EncryptionConfiguration을 만들고 apiserver에 --encryption-provider-config로 연결하는 것으로 끝이 아닙니다. 설정 적용은 그 이후에 쓰이는 Secret만 암호화하므로, 이미 평문으로 저장된 기존 Secret은 한 번 다시 써야 암호화됩니다. 이 재암호화 단계를 빠뜨리면 기존 Secret이 평문으로 남아 점수가 깎입니다.

# 설정 적용 후 기존 Secret을 전부 다시 써서 재암호화
k get secrets --all-namespaces -o json | k replace -f -

6) Trivy 심각도,종료 옵션 누락 #

이미지 스캔 작업에서 “HIGH와 CRITICAL 취약점이 있는 이미지를 찾아 삭제하라” 유형이 자주 나옵니다. --severity HIGH,CRITICAL로 심각도를 한정하지 않으면 결과가 너무 많아 판별이 어렵고, 자동 판정이 필요하면 --exit-code 1로 종료 코드를 활용합니다. 심각도 표기는 쉼표로 붙여 적고 공백을 넣지 않습니다.

# 지정 심각도만, 결과 간결하게
trivy image --severity HIGH,CRITICAL --quiet nginx:1.19

# 취약점이 있으면 종료 코드 1
trivy image --exit-code 1 --severity CRITICAL nginx:1.19

7) 정책 적용 네임스페이스 혼동 #

OPA/Gatekeeper,Kyverno 정책이나 NetworkPolicy는 어느 네임스페이스에 적용되는지가 핵심 조건입니다. NetworkPolicy는 만든 네임스페이스에만 적용되고, Kyverno 정책은 ClusterPolicy인지 네임스페이스 한정 Policy인지에 따라 범위가 다릅니다. 작업이 지정한 대상 범위와 정책의 적용 범위가 어긋나면 의도한 차단이 일어나지 않습니다.

# NetworkPolicy는 만든 네임스페이스 안에서만 동작
k get networkpolicy -n target-ns

8) 노드 SSH 후 돌아오기 누락 #

System Hardening도메인은 노드에 직접 들어가 푸는 작업이 많습니다. AppArmor로드, seccomp 파일 배치, kernel 파라미터(sysctl) 조정을 노드에서 끝낸 뒤 exit로 빠져나오지 않으면, 다음 작업의 kubectl 명령이 노드 환경에서 실행되어 엉뚱한 곳에 만들어집니다. 노드 작업은 ssh → 작업 → exit를 한 묶음으로 운영합니다.

9) 변경 후 적용,재시작 누락 #

apiserver의 --encryption-provider-config나 admission plugin을 추가하려면 /etc/kubernetes/manifests/kube-apiserver.yaml을 고쳐야 하고, 고친 뒤 kubelet이 static Pod를 다시 띄울 때까지 기다려야 반영됩니다. Falco 규칙을 바꾼 뒤에는 서비스를 재시작해야 새 규칙이 적용됩니다. 설정 변경은 적용,재시작까지 한 동작으로 묶습니다.

# apiserver static Pod가 다시 떴는지 확인
k get pods -n kube-system | grep apiserver
# Falco 규칙 적용
sudo systemctl restart falco

부분 점수와 검산 #

CKS는 작업 단위로 채점되며 일부 작업은 부분 점수가 있습니다. 도구 작업은 “만들었다"가 아니라 “실제로 적용되어 차단,탐지가 동작하는가"까지 확인해야 합니다. 작업을 끝낼 때마다 짧게 검산합니다.

# 만든 정책,리소스가 실제로 떴는지
k get networkpolicy,pod -n <namespace>

# PSA가 위험한 Pod를 실제로 거부하는지 (거부되면 정상)
k run test --image=nginx --privileged -n prod

# AppArmor 프로파일이 노드에 로드됐는지
ssh node01 'sudo aa-status | grep custom-profile'

# apiserver가 새 설정으로 다시 떴는지
k get pods -n kube-system | grep apiserver

검산은 30초 안에 끝나지만, “다 했다고 생각한 작업이 사실 적용 안 되어 있던” 가장 흔한 실점을 막습니다. 특히 apiserver 매니페스트를 고친 뒤에는 kubelet이 새 Pod를 띄우는 데 몇 초가 걸리므로, k get pods -n kube-system을 한 번 더 확인합니다.

헷갈리는 개념 쌍 #

작업 중 순간적으로 헷갈리기 쉬운 보안 개념 쌍을 한 줄 차이로 압축합니다.

AppArmor와 seccomp는 자주 한 작업에 함께 나오지만 막는 대상이 다릅니다. seccomp는 컨테이너가 호출할 수 있는 시스템 콜의 집합을 좁히고, AppArmor는 파일 경로,네트워크,capability 같은 자원 접근을 프로파일로 제한합니다. 둘 다 호스트 커널 위에서 동작하는 반면, gVisor는 별도의 사용자 공간 커널을 두어 컨테이너를 호스트 커널에서 한 겹 더 떼어 냅니다.

도메인별 응시 직전 체크리스트 #

각 도메인에서 손이 바로 나와야 하는 핵심 명령과 절차입니다.

도메인 1: Cluster Setup (10%) #

• NetworkPolicy: default deny 후 필요한 ingress/egress만, podSelector,namespaceSelector
• kube-bench로 CIS benchmark 점검, 지적 항목 수정
• Ingress TLS: tls 블록과 Secret(kubernetes.io/tls) 연결
• 바이너리 검증: 체크섬,서명 확인

도메인 2: Cluster Hardening (15%) #

• RBAC 최소 권한: Role/ClusterRole, 필요한 verb,resource만, k auth can-i
• ServiceAccount 토큰: automountServiceAccountToken: false
• API 액세스 제한: anonymous-auth, NodeRestriction admission
• 클러스터 업그레이드로 알려진 취약점 패치

도메인 3: System Hardening (15%) #

• AppArmor: apparmor_parser로 노드 로드, securityContext.appArmorProfile
• seccomp: /var/lib/kubelet/seccomp 아래 배치, 루트 기준 상대 경로
• capabilities 최소화(drop: ["ALL"]), /proc 보호
• 노드 ssh 작업은 exit로 복귀까지 한 묶음

도메인 4: Minimize Microservice Vulnerabilities (20%) #

• PSA: pod-security.kubernetes.io/enforce label, 레벨,모드 정확히
• Secrets: EncryptionConfiguration, 기존 Secret 재암호화
• gVisor: RuntimeClass로 runsc handler 지정
• Pod 간 mTLS: Cilium 정책으로 암호화,신원 검증

도메인 5: Supply Chain Security (20%) #

• Minimal images: distroless,scratch, 불필요한 패키지 제거
• Trivy 스캔: --severity HIGH,CRITICAL, --exit-code
• cosign으로 서명,검증, SBOM 생성
• admission으로 미서명,취약 이미지 거부

도메인 6: Monitoring, Logging and Runtime Security (20%) #

• OPA/Gatekeeper,Kyverno로 정책 강제, 적용 범위 확인
• Falco 규칙 작성,트리거, 로그 확인, 규칙 변경 후 재시작
• audit policy 작성, apiserver --audit-policy-file,--audit-log-path 연결
• container immutability(readOnlyRootFilesystem), forensics 절차

온라인 감독 응시 직전 점검 #

CKS는 PSI 원격 터미널에 접속해 작업하는 온라인 감독 시험입니다. 시험 시작 전에 다음을 확인합니다.

신분증 #

• 영문 표기가 있는 신분증 (여권 권장), 이름이 등록 정보와 정확히 일치
• 감독관 채팅 안내에 따라 신분증 양면을 카메라에 제시

응시 환경 #

• 책상 위 모든 물건 치움, 벽면 메모,포스터 제거
• 듀얼 모니터는 한 대만 사용, 보조 화면 분리
• 가족,룸메이트 출입 차단, 조용한 단독 공간 확보

시스템 #

• 응시 30분 전 입실해 시스템 점검 통과
• 백그라운드 앱,알림,VPN 종료, 안정적인 유선 네트워크 권장
• 시험 시작 후 가장 먼저 alias k,do,자동완성,.vimrc 셋업, 첫 작업 전 context 확인

정리 #

이 글에서 잡은 것:

• 2시간 운영. 작업당 배점이 우선순위. 손에 익은 도구 작업부터, 처음 보는 도구에서 막히면 flag 후 다음, 과몰입 금지
• 도구별 작업. CKS는 작업마다 도구가 달라 한 작업에서 막히기 쉬움. 손에 익은 것부터 점수를 쌓음
• 셋업. alias k,do,now,자동완성,vim 들여쓰기를 시작 1분 안에
• context 최우선. CKS는 클러스터가 여러 개이고 노드 작업이 잦음. 작업마다 use-context 먼저, 노드 작업 후 exit
• 문서 활용. kubernetes.io와 Falco,Trivy,AppArmor,gVisor 문서 위치를 미리 익힘, 문서 시간도 시험 시간
• 단골 실수. context/namespace, AppArmor 노드 로드, seccomp 경로, PSA label 오타, etcd 재암호화, Trivy 심각도 옵션, 정책 적용 네임스페이스, 노드 복귀, 적용,재시작 누락
• 부분 점수와 검산. 만들 수 있는 데까지 만들고 실제 차단,탐지가 동작하는지 확인
• 헷갈리는 개념 쌍, 6개 도메인별 핵심 절차, 온라인 감독 점검

다음: 풀스케일 실기 모의고사 #

마지막 글입니다.

#20 풀스케일 실기 모의고사 (전 도메인 통합 시나리오 + 해설)에서는 실제 시험과 비슷한 도메인 분포로 통합 시나리오를 풀고 상세 해설을 답니다. 시험 환경처럼 시간을 재며 풀어 보고, 비중 큰 뒤쪽 세 도메인(마이크로서비스,공급망,런타임)을 한 번 더 다지는 마지막 단계입니다.