LabHub
배우기 러닝패스 코스

CKS — 쿠버네티스 보안 전문가 · 열린 터미널의 권한과 사고 대응 · 퀴즈

퀴즈: 실행 채널의 차단·보존·복구

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. 새 exec가 forbidden인데 기존 연결이 새 난수 입력에 ACK를 보냈다. 입증한 것은?

    1. 새 요청 인가와 기존 스트림 종료가 다른 통제라는 것
    2. API 서버가 모든 RBAC 규칙을 무시하고 있다는 것
    3. 서비스 계정 토큰의 만료 검사가 비활성이라는 것
    4. 컨테이너가 호스트 root 권한을 획득했다는 것
  2. exec 회수 뒤 pods/get을 남겨 둔 이유는?

    1. Pod GET이 기존 터미널을 자동으로 종료하기 때문이다
    2. 실행 거부와 Pod 조회 실패를 구분할 대조군이기 때문이다
    3. GET이 있어야 서비스 계정의 인증서가 갱신되기 때문이다
    4. Pod GET이 이미지 변경 권한까지 포함하기 때문이다
  3. --as로 서비스 계정 신원을 사용한 이번 실습의 한계는?

    1. 실제 API 서버에 도달하지 않으므로 인가를 확인할 수 없다
    2. 실제 요청이므로 서비스 계정 토큰의 만료도 검증한 셈이다
    3. 대리 신원의 인가는 보지만 bearer 토큰 폐기 검증은 아니다
    4. 관리자 인증서가 있으므로 대리 신원의 Role은 무시된다
  4. 조사한 target 이름은 그대로인데 UID가 달라졌다. 종료 단계에서 무엇이 맞는가?

    1. 이름이 같으므로 새 UID로 바꾸어 바로 삭제한다
    2. namespace 전체를 삭제해 기존 연결까지 정리한다
    3. 대조 Pod도 함께 삭제해 회수 범위를 일치시킨다
    4. 조사 대상 변경으로 중단하고 신원과 영향을 다시 확인한다
  5. 삭제 API가 성공했다. 대응 완료를 판단하려면?

    1. Pod 부재·기존 연결 종료·대조군 보존을 추가 확인한다
    2. 이름으로 삭제했으므로 대상 UID는 기록할 필요가 없다
    3. 정상 삭제도 이미 강제 종료이므로 연결 상태는 생략한다
    4. 삭제 성공은 같은 namespace 전체가 안전하다는 뜻이다
  6. 새 target이 Ready가 됐다. 복구 후 권한 점검은?

    1. 이전 exec 권한까지 모두 되돌려 정상 여부를 확인한다
    2. 새 UID·GET 성공과 exec 거부 유지를 함께 확인한다
    3. Pod 이름이 같으면 이전 UID 기록을 그대로 사용한다
    4. RoleBinding을 cluster-admin으로 바꾸고 오류를 없앤다