권한을 회수했는데 터미널은 살아 있다

목표

신규 exec 권한 차단과 기존 실행 연결의 종료를 각각 검증하고 증거를 보존합니다.

왜 중요한가

새 연결이 열리지 않는 것만 확인하면 남아 있는 실행을 놓칠 수 있습니다. 반대로 무조건 Pod를
지우면 조사 자료와 업무를 잃을 수 있습니다. 전용 VM의 무해한 ACK 프로그램으로 그 차이를
관찰하고, 지정 UID만 종료한 뒤 대조군과 복구된 Pod의 권한 경계를 확인합니다.

65분 실습입니다. 세션은 기본 60분이므로 만료 전에 ＋시간으로 연장하세요. 최대 180분이며
세션이 끝나면 파일과 실행 중 연결은 사라집니다. 필요한 증거는 종료 전에 내려받으세요.

단계

1. inspect로 기준선을 읽고 /root/cks-exec/scope.json에 namespace, target_uid, control_uid, identity_method 네 필드를 기록하세요. namespace는 cks-terminal이며 나머지는 현재 실습의 실제 값입니다. act 1로 조사 범위를 저장하세요.
2. /root/cks-exec/allow-role.json에 apiVersion=rbac.authorization.k8s.io/v1, kind=Role, metadata.name=terminal, metadata.namespace=cks-terminal을 작성하세요. 첫 규칙은 apiGroups=[""], resources=["pods"], resourceNames=["target","control"], verbs=["get"], 둘째는 resources=["pods/exec"], resourceNames=["target"], verbs=["get","create"]이며 apiGroups=[""]입니다. act 2로 적용하고 control의 실제 exec 거부를 확인하세요.
3. act 3으로 target에 실제 exec 연결을 열고 새 입력의 ACK 기준선을 관찰하세요. /root/cks-exec/evidence/03.json의 facts.stream에 nonce·reply·at가 저장됩니다. 이 연결은 뒤 단계까지 유지하며 새 연결로 바꾸지 않습니다.
4. /root/cks-exec/revoke-role.json에 같은 Role을 작성하되 pods/exec 규칙만 제거하고 target·control GET 규칙은 유지하세요. act 4로 권한을 회수하고 evidence/04.json의 new_exec가 정확히 pods/exec 권한 거부인지 확인하세요.
5. act 5로 기존 연결에 새 입력을 보내세요. evidence/05.json의 응답은 3단계와 다른 nonce여야 하고 시각은 4단계 저장 이후여야 합니다. 같은 target UID의 GET 성공과 비교해 전체 API 장애가 아님을 설명하세요.
6. /root/cks-exec/containment.json에 namespace=cks-terminal, target=target, 실제 target_uid, preserve_control_uid, evidence_sha256, action=delete-owned-pod, force=false를 기록하세요. 해시는 evidence/05.json을 키 정렬·공백 없는 UTF-8 JSON(ensure_ascii=False)으로 직렬화한 SHA-256입니다. act 6으로 종료 전 계획과 증거를 보존하세요.
7. act 7로 계획에서 검증한 원래 target UID만 정상 종료하세요. evidence/07.json에서 old_pod_absent=true, stream_rc가 실제 정수 종료 코드, control_ready=true와 원래 control_uid 유지, force=false를 확인하세요. 다른 Pod나 namespace를 삭제하지 마세요.
8. /root/cks-exec/report.json에 new_exec=denied, existing_exec=responded-after-revocation, 실제 old_target_uid·control_uid, containment=owned-pod-terminated, authentication_tested=impersonation-not-token-revocation, evidence_sha256를 기록하세요. 해시는 7단계 증거의 같은 방식 SHA-256입니다. act 8로 새 UID의 target을 복구하고 Ready·GET 성공 및 exec 거부 유지까지 확인하세요.

참고

모든 조작은 VM 내부의 cks-terminal에만 적용합니다. helper 사용법은
python3 /opt/fixtures/cks_exec_lab.py inspect, act 1부터 act 8, grade 1부터 grade 8입니다.
act는 실제 작업과 관측을 수행하고 grade는 파일만 읽습니다. 이미 완료한 act는 답안을
보존하고 다시 실행하지 않습니다. 부분 입력도 자동으로 덮어쓰지 않으니 직접 고치세요.
실행 도중 중단되어 결과가 불확실한 단계는 자료를 보존하고 새 세션에서 재현합니다.

이 실습의 신원은 관리자 인증서의 SA impersonation입니다. 실제 SA 토큰 폐기 실험이 아닙니다.
특권·호스트 네트워크·추가 capability를 사용하지 마세요. 운영 서비스에서 이 종료 절차를
그대로 실행하지 말고, 소유 컨트롤러·노드 상태·증거 보존·업무 영향을 먼저 검토하세요.

단계 8개

1. 대상과 대조군 신원 조사
2. 대상 Pod에만 터미널 권한 부여
3. 실제 양방향 연결의 기준선
4. 새 exec 요청의 권한 회수
5. 남아 있는 연결과 새로운 입력
6. 종료 전 증거와 영향 범위 보존
7. 지정 UID만 종료하고 대조군 확인
8. 새 Pod 복구와 대응 보고서