测验：执行通道的阻断、证据保全与恢复

새 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으로 바꾸고 오류를 없앤다