CKS 모의고사 B

목표

B 회차입니다. A 회차와 겹치는 문제가 하나도 없습니다. 같은 도메인을
같은 비율로 묻지만 확인하는 역량이 모두 다릅니다. A 를 풀어 본 뒤에 이어서
치르면 어느 도메인이 아직 약한지가 드러납니다.

실제 CKS 와 같은 조건에서 과제 17개를 120분 안에 풉니다. 합격선은 67% 이고
부분 점수제이므로, 17개 중 12개를 통과하면 완료로 처리됩니다.

모의고사입니다. 힌트와 정답지를 보지 말고 먼저 끝까지 풀어 보십시오.
막힌 과제는 표시해 두고 넘어갔다가 남은 시간에 돌아오는 편이 낫습니다.
채점은 언제든 눌러도 되고, 여러 번 눌러도 결과가 달라지지 않습니다.

왜 중요한가

CKS 는 CKA 합격이 선수 조건인 유일한 시험입니다. 쿠버네티스를 다루는 손은
이미 갖췄다고 전제하므로, 문제는 "무엇을 만드세요" 보다 "이 설정의 무엇이
위험한지 찾아 고치세요" 쪽에 가깝습니다. 방어와 진단이 시험 대상이고,
공격 기법은 다루지 않습니다.

이 회차는 특히 경계를 좁히는 방법을 묻습니다. 권한을 이름 하나로 좁히고,
토큰에 대상과 수명을 붙이고, 규칙은 한 번만 쓰되 효력은 한 네임스페이스로
자릅니다. 넓게 열어 두고 나중에 좁히는 일은 실무에서 거의 일어나지 않으므로,
처음부터 좁게 여는 손이 곧 실력입니다.

시험 환경 (실제 시험에서 확인된 사실)

볼 수 있는 문서는 kubernetes.io/docs, kubernetes.io/blog,

falco.org/docs, kubernetes-sigs.github.io/bom, etcd.io/docs,
kubernetes.github.io/ingress-nginx, docs.cilium.io,
istio.io/latest/docs 입니다.

문서 사이트 안에서 검색하는 것은 허용되지만, 결과가 허용 목록 밖으로

나가면 안 됩니다.

k 별칭과 bash 자동완성이 이미 설정되어 있습니다. 별칭을 만드는 데

시간을 쓰지 마십시오.

과제마다 지정된 호스트로 ssh 해서 작업하며, 중첩 ssh 는 지원되지

않습니다. 다음 과제로 넘어가기 전에 exit 하십시오.

도구는 SSH 로 접속한 호스트에만 있습니다.
복사는 Ctrl+Shift+C, 붙여넣기는 Ctrl+Shift+V 입니다.

이 모의고사 환경에서 다른 점

이 실습의 클러스터는 파드 안에서 도는 1인용 클러스터입니다. kube-apiserver 는
진짜라서 매니페스트, RBAC, 파드 보안 승인, 승인 정책은 **실제로 동작하고 실제로
거부합니다.** 다만 컨테이너를 실제로 돌리는 런타임이 없으므로 다음 세 가지는
확인할 수 없습니다.

NetworkPolicy 는 적용되지만 실제 차단은 일어나지 않습니다. CNI 가 없기

때문입니다. 1번 과제는 정책 객체가 올바른지만 봅니다.

seccomp 프로파일은 커널에 적재되지 않습니다. 7번 과제는 프로파일 파일의

내용과 파드에 물린 배선을 봅니다.

8번 과제의 sudo 규칙은 이 파드에 적용되지 않습니다. 파일의 내용과

visudo 의 문법 판정만 봅니다.

나머지는 전부 살아 있는 클러스터에서 다시 계산해 채점합니다. 권한은
kubectl auth can-i 로, 승인 정책과 파드 보안 승인은 서버 dry-run 으로 그
순간의 판정을 다시 물어봅니다.

단계

Cluster Setup

1. 네임스페이스 staging 을 만들고, 그 안에서 app=web 이 아니라 app=api
라벨이 붙은 파드에 적용되는 NetworkPolicy api-allow 를 만드십시오.
인그레스는 env=frontend 라벨이 붙은 네임스페이스 안의 role=web 라벨이
붙은 파드에서 오는 TCP 8080 만 허용하고, 나머지 인그레스는 모두 막습니다.
이그레스는 UDP 53 과 TCP 53 만 허용하고 나머지는 모두 막습니다.
2. /usr/local/bin/kubectl 과 /usr/local/bin/helm 의 SHA-256 해시를
sha256sum 출력 형식 그대로 /root/exam/verify/binaries.sha256 에
저장하십시오. 경로는 절대 경로여야 하고, sha256sum -c 로 검증했을 때
두 항목 모두 통과해야 합니다.
3. /root/exam/kubelet/config.yaml 에 kubelet 구성을 작성하십시오.
apiVersion 은 kubelet.config.k8s.io/v1beta1, kind 는
KubeletConfiguration 입니다. 익명 접근을 끄고, 웹훅 인증을 켜고, 인가
방식을 Webhook 으로 하고, 인증 없는 읽기 전용 포트를 닫고, 커널 기본값
보호를 켜십시오.

Cluster Hardening

4. 네임스페이스 staging 에서 사용자 ci-deployer 가 Deployment web 하나만
get, patch, update 할 수 있게 Role web-deployer 와 RoleBinding
ci-deployer-web 을 만드십시오. 같은 네임스페이스의 다른 Deployment 는
건드릴 수 없어야 하고, Deployment 목록을 볼 수도 없어야 합니다.
5. 네임스페이스 staging 에 서비스 계정 agent 를 만들고 파드 collector 를
만드십시오. 파드는 서비스 계정 agent 를 쓰되 기본 토큰 자동 마운트는
끄고, 대신 projected 볼륨 token 으로 대상이 vault 이고 유효 기간이
3600초인 서비스 계정 토큰을 파일 이름 token 으로 발급받아
/var/run/secrets/vault 에 마운트하십시오. 컨테이너 이름은 app 입니다.
6. ClusterRole namespace-reader 를 만들어 코어 그룹의 pods, services,
configmaps 를 get, list, watch 할 수 있게 하십시오. 그리고 사용자
oncall 이 네임스페이스 staging 안에서만 그 권한을 갖도록 RoleBinding
oncall-reader 를 만드십시오. 다른 네임스페이스에서는 아무것도 읽을 수
없어야 하고, staging 안에서도 시크릿은 읽을 수 없어야 합니다.

System Hardening

7. /root/exam/seccomp/net-deny.json 에 seccomp 프로파일을 작성하십시오.
기본 동작은 SCMP_ACT_LOG 이고, socket 과 connect 시스템 콜은
SCMP_ACT_ERRNO 로 막아야 합니다. 그리고 네임스페이스 staging 에 파드
sensor 를 만들되, 파드 수준에는 RuntimeDefault 프로파일을 두고
컨테이너 app 에서만 이 프로파일을 Localhost 방식으로
profiles/net-deny.json 경로에서 쓰게 하십시오.
8. /root/exam/sudoers.d/deploy 에 sudo 규칙을 작성하십시오. 사용자 deploy
가 비밀번호를 묻지 않고 /usr/bin/systemctl restart kubelet 하나만 root 로
실행할 수 있어야 합니다. 명령 자리에 ALL 을 쓴 규칙은 두지 마십시오.
파일은 visudo -cf 의 문법 검사를 통과해야 합니다.

Minimize Microservice Vulnerabilities

9. 네임스페이스 payments 를 만들고 파드 보안 승인을 단계적으로 거십시오.
enforce 는 baseline 이고 버전은 v1.31 로 고정합니다. audit 과
warn 은 restricted 이고 버전은 latest 입니다. 결과적으로 baseline
을 어기는 파드는 실제로 거부되고, restricted 만 어기는 파드는 경고를
받으면서 만들어져야 합니다.
10. 네임스페이스 payments 에 시크릿 db-cred 를 만드십시오. 타입은 기본
(Opaque)이고 키는 username 과 password 입니다. 그리고 파드
reporter 를 만들어 이 시크릿을 볼륨 cred 로 /etc/db 에 읽기 전용으로
마운트하되 파일 권한은 8진수 0400 이어야 합니다. 시크릿 값을 환경
변수로는 넣지 마십시오. 컨테이너 이름은 app 입니다.
11. /root/exam/encryption/config.yaml 에 저장 시 암호화 구성을 작성하십시오.
apiVersion 은 apiserver.config.k8s.io/v1, kind 는
EncryptionConfiguration 입니다. 암호화 대상은 secrets 이고, 제공자는
aescbc 가 첫 번째, identity 가 마지막이어야 합니다. aescbc 의 키는
이름을 갖고 값은 32바이트를 base64 로 적은 것이어야 합니다.

Supply Chain Security

12. 네임스페이스 supply 를 만들고, 레지스트리 registry.internal 에 사용자
deployer 로 접근하는 자격 증명을 시크릿 regcred 로 만드십시오. 서비스
계정 puller 가 그 시크릿으로 이미지를 내려받게 연결하고, Deployment
catalog 가 그 서비스 계정을 쓰게 하십시오. 컨테이너 이름은 app 이고
이미지는 registry.internal/catalog:1.4.2 입니다.
13. 네임스페이스 supply 에서 움직이는 태그를 막으십시오.
ValidatingAdmissionPolicy no-latest-tag 와
ValidatingAdmissionPolicyBinding no-latest-tag 를 만들고, 파드의
모든 컨테이너와 모든 초기화 컨테이너의 이미지가 :latest 로 끝나지
않을 것을 요구하게 하십시오. 바인딩의 validationActions 는 Deny 이고
적용 범위는 네임스페이스 supply 뿐입니다. 다른 네임스페이스는 영향을
받으면 안 됩니다.
14. /root/exam/imagepolicy/admission-config.yaml 에 승인 구성 파일을
작성하십시오. apiVersion 은 apiserver.config.k8s.io/v1, kind 는
AdmissionConfiguration 이고, 플러그인은 ImagePolicyWebhook 하나입니다.
그 설정의 imagePolicy 에 kubeConfigFile 로
/etc/kubernetes/imagepolicy/kubeconfig.yaml 을 적고, allowTTL 50,
denyTTL 50, retryBackoff 500 을 두며, 웹훅에 닿지 못했을 때 이미지가
허용되지 않도록 defaultAllow 를 거짓으로 두십시오.

Monitoring, Logging and Runtime Security

15. /root/exam/falco/rules.yaml 에 런타임 탐지 규칙을 작성하십시오. 파일은
항목들의 목록이고, 그 안에 trusted_writers 라는 list 항목과
Write below etc 라는 rule 항목이 하나씩 있어야 합니다. 목록에는
항목이 최소 하나 있어야 합니다. 규칙의 priority 는 WARNING 이고,
desc 와 tags 가 비어 있으면 안 되며, condition 에는 open_write,
/etc, trusted_writers 가 모두 나와야 하고, output 에는
%proc.name 과 %fd.name 이 있어야 합니다.
16. /root/exam/audit/quiet-policy.yaml 에 감사 정책을 작성하십시오.
apiVersion 은 audit.k8s.io/v1, kind 는 Policy 이며 규칙은 정확히
네 개이고 순서가 중요합니다. 첫째, 사용자 system:kube-proxy 의 watch
가 코어 그룹의 endpoints 와 services 에 닿는 것을 None 으로
버립니다. 둘째, 그룹 system:authenticated 의 비자원 경로 /api* 와
/version 접근을 None 으로 버립니다. 셋째, 네임스페이스 payments 의
코어 그룹 secrets 를 RequestResponse 로 남깁니다. 넷째, 대상을 적지
않은 Metadata 규칙으로 나머지 전부를 받습니다.
17. 네임스페이스 runtime 을 만들고, 그 안에서 만들어지는 파드의 모든
컨테이너가 readOnlyRootFilesystem: true 를 갖도록 강제하십시오.
ValidatingAdmissionPolicy immutable-root 와
ValidatingAdmissionPolicyBinding immutable-root 를 만들고, 바인딩의
validationActions 는 Deny 이며 적용 범위는 네임스페이스 runtime
뿐입니다. 다른 네임스페이스는 영향을 받으면 안 됩니다.

참고

라벨을 다시 걸 때는 kubectl label ... --overwrite 를 쓰십시오. 없이

쓰면 이미 있는 라벨에서 오류가 납니다.

kubectl auth can-i 는 자원 뒤에 이름을 붙여 물어볼 수 있습니다.

kubectl auth can-i patch deployments/web -n staging --as=ci-deployer
처럼 쓰면 resourceNames 로 좁힌 권한을 그대로 확인할 수 있습니다.

승인 정책이 실제로 막는지 확인할 때는 kubectl apply --dry-run=server 를

쓰십시오. 승인 체인을 그대로 태우면서 클러스터에는 아무것도 남기지
않습니다.

흔한 실수 세 가지입니다. NetworkPolicy 의 from 을 항목 두 개로 나누면

두 조건이 모두 만족될 때가 아니라 둘 중 하나만 만족돼도 열립니다.
resourceNames 로 좁힌 규칙은 이름이 없는 요청인 list 를 허용하지
않습니다. 그리고 CEL 에서 object.spec.initContainers 는 없을 수 있으므로
has() 로 감싸지 않으면 초기화 컨테이너가 그대로 빠져나갑니다.

단계 17개

두 셀렉터를 함께 둔 허용 목록
배포 전 이진 파일 검증
kubelet 구성 강화
이름 하나로 좁힌 권한
대상과 수명이 정해진 토큰
규칙은 한 번, 효력은 한 네임스페이스
컨테이너 수준 seccomp 덮어쓰기
호스트 계정 권한 최소화
단계적으로 올리는 파드 보안 승인
시크릿은 파일로만
저장 시 암호화 구성
사설 레지스트리 자격 증명
움직이는 태그 차단
이미지 정책 웹훅 구성
런타임 탐지 규칙
감사 로그에서 잡음 걷어내기
읽기 전용 루트를 승인 단계에서 강제