퀴즈: RKE2 와 CIS 프로필

RKE2 를 기본 설정(profile 없음)으로 세운 클러스터의 Pod Security Admission 기본 enforce 수준은?

• privileged — 제한 없이 받아들인다
• baseline — 알려진 권한 상승만 막는다
• restricted — 모든 네임스페이스를 강하게 막는다
• 설정 파일이 없어 PSA 가 꺼져 있다

기본 프로필로 돌던 RKE2 에 profile: cis 를 넣고 재시작했더니 즉시 fatal 로 끝났다. 가장 먼저 채워야 할 것은?

• kube-system 에 NetworkPolicy 를 먼저 만들어 둔다
• 호스트에 etcd 사용자와 그룹을 만든다
• 모든 네임스페이스에 restricted 라벨을 붙인다
• Canal 을 Cilium 으로 바꾸고 다시 시작한다

기본 프로필 RKE2 를 systemctl stop 으로 멈추고 etcd 사용자·sysctl 을 준비해 cis 로 다시 시작했더니, etcd 가 member/snap/db 를 열지 못해 panic 한다. 가장 알맞은 조치는?

• systemctl restart systemd-sysctl 로 커널 값을 다시 읽힌다
• etcd 사용자에게 로그인 셸을 주고 서비스를 다시 시작한다
• rke2-killall.sh 로 남은 정적 파드까지 내린 뒤 다시 시작한다
• 스냅숏 디렉터리를 먼저 만들어 etcd 초기화를 허용한다

cis 프로필을 켠 뒤에도 legacy 네임스페이스에 전부터 떠 있던 특권 파드가 계속 Running 인 이유는?

• legacy 는 cis 프로필의 PSA 예외 네임스페이스 목록에 들어 있다
• 특권 파드는 kubelet 이 재시작돼도 절대 다시 만들지 않기 때문이다
• PSA 판정 결과가 파드마다 캐시되어 한동안 유지되기 때문이다
• PSA 는 생성·수정 요청을 검사할 뿐 이미 있는 파드를 내쫓지 않는다

cis 준비를 하며 돌고 있는 노드에서 sysctl 파일을 적용하는 방법으로 하드닝 가이드의 경고에 맞는 것은?

• 그 파일 하나만 sysctl -p 로 적용한다
• systemctl restart systemd-sysctl 로 전체를 다시 읽힌다
• 노드를 재부팅해 커널 값을 처음부터 다시 맞춘다
• config.yaml 에 protect-kernel-defaults: false 를 넣는다

RKE2 의 etcd 스냅숏에 대해 문서와 이 실습에서 확인한 사실로 맞는 것은?

• 스냅숏은 API 서버가 만들어 ConfigMap 에 저장한다
• 기본으로 12시간마다 찍고 5개를 남기며, 토큰을 함께 보관해야 한다
• --name 으로 준 이름이 그대로 파일 이름이 된다
• 스냅숏에는 etcd 데이터만 있어 CA 키는 따로 백업한다