CKS — 쿠버네티스 보안 전문가 · 열린 터미널의 권한과 사고 대응 · 퀴즈
퀴즈: 실행 채널의 차단·보존·복구
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
새 exec가 forbidden인데 기존 연결이 새 난수 입력에 ACK를 보냈다. 입증한 것은?
- 새 요청 인가와 기존 스트림 종료가 다른 통제라는 것
- API 서버가 모든 RBAC 규칙을 무시하고 있다는 것
- 서비스 계정 토큰의 만료 검사가 비활성이라는 것
- 컨테이너가 호스트 root 권한을 획득했다는 것
exec 회수 뒤 pods/get을 남겨 둔 이유는?
- Pod GET이 기존 터미널을 자동으로 종료하기 때문이다
- 실행 거부와 Pod 조회 실패를 구분할 대조군이기 때문이다
- GET이 있어야 서비스 계정의 인증서가 갱신되기 때문이다
- Pod GET이 이미지 변경 권한까지 포함하기 때문이다
--as로 서비스 계정 신원을 사용한 이번 실습의 한계는?
- 실제 API 서버에 도달하지 않으므로 인가를 확인할 수 없다
- 실제 요청이므로 서비스 계정 토큰의 만료도 검증한 셈이다
- 대리 신원의 인가는 보지만 bearer 토큰 폐기 검증은 아니다
- 관리자 인증서가 있으므로 대리 신원의 Role은 무시된다
조사한 target 이름은 그대로인데 UID가 달라졌다. 종료 단계에서 무엇이 맞는가?
- 이름이 같으므로 새 UID로 바꾸어 바로 삭제한다
- namespace 전체를 삭제해 기존 연결까지 정리한다
- 대조 Pod도 함께 삭제해 회수 범위를 일치시킨다
- 조사 대상 변경으로 중단하고 신원과 영향을 다시 확인한다
삭제 API가 성공했다. 대응 완료를 판단하려면?
- Pod 부재·기존 연결 종료·대조군 보존을 추가 확인한다
- 이름으로 삭제했으므로 대상 UID는 기록할 필요가 없다
- 정상 삭제도 이미 강제 종료이므로 연결 상태는 생략한다
- 삭제 성공은 같은 namespace 전체가 안전하다는 뜻이다
새 target이 Ready가 됐다. 복구 후 권한 점검은?
- 이전 exec 권한까지 모두 되돌려 정상 여부를 확인한다
- 새 UID·GET 성공과 exec 거부 유지를 함께 확인한다
- Pod 이름이 같으면 이전 UID 기록을 그대로 사용한다
- RoleBinding을 cluster-admin으로 바꾸고 오류를 없앤다