LabHub
배우기 러닝패스 코스

KCSA — 쿠버네티스 보안 어소시에이트 · 서비스 계정 신원과 토큰의 수명 · 퀴즈

퀴즈: 토큰 폐기와 권한 회수

LabHub 에서 이어서 보기

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

  1. 보고서 audience 토큰의 exp는 미래다. 지정된 API에 보내면 401이고, 보고서 audience를 명시한 TokenReview는 true다. 가장 먼저 확인할 것은?

    1. 토큰의 수신자와 요청한 API가 받아들이는 수신자가 같은지 확인한다
    2. 토큰 발급자의 Role에 모든 네임스페이스의 ConfigMap 읽기를 추가한다
    3. 토큰을 발급한 Pod를 재시작하여 기존 토큰의 만료 시각을 연장한다
    4. 보고서 TokenReview가 성공했으므로 API의 CA 검증을 생략한다
  2. Role의 rules를 비운 뒤 같은 토큰의 TokenReview는 true, ConfigMap GET은 403이다. 이 결과로 말할 수 있는 것은?

    1. 토큰이 무효가 되었지만 TokenReview가 새 토큰을 대신 발급했다
    2. 토큰의 신원은 인증되지만 해당 읽기 요청은 인가되지 않았다
    3. ConfigMap이 삭제되어 API가 같은 이름의 자원 생성을 거절했다
    4. SA UID가 변경되었지만 기존 바인딩이 옛 토큰을 복구했다
  3. SA를 삭제하고 같은 이름으로 재생성했다. 만료 전 옛 토큰은 401, 새 토큰은 기존 RoleBinding을 통해 200이다. 가장 정확한 해석은?

    1. 이름을 재사용하면 옛 토큰도 다시 유효해지지만 첫 요청만 거절된다
    2. RoleBinding이 옛 SA UID를 새 SA UID로 자동 교체했기 때문이다
    3. 옛 UID의 인증은 거절되고 이름 기반 바인딩은 새 신원에도 적용된다
    4. 새 토큰의 발급 권한이 새 토큰에게 관리자 읽기 권한을 함께 부여한다
  4. JWT를 디코딩해 미래의 exp를 확인했고 관리자 --as 요청도 성공했다. 옛 토큰이 지금 API에서 유효하다는 증거로 부족한 이유는?

    1. JWT의 sub를 읽으면 서버가 해당 계정을 자동으로 다시 생성하기 때문이다
    2. 대리 요청은 언제나 익명 요청이므로 실제 RBAC를 전혀 거치지 않기 때문이다
    3. API는 만료 시각 대신 항상 RoleBinding의 생성 시각으로 인증하기 때문이다
    4. 디코딩은 서명 검증이 아니며 대리 요청은 그 토큰 자체를 검사하지 않기 때문이다
  5. 이번 VM에서 Pod와 SA의 automountServiceAccountToken을 false로 두었다. 그런데 관리자가 TokenRequest로 토큰을 발급했다. 무엇이 맞는가?

    1. 자동 마운트 설정과 관리자의 명시적 토큰 발급 권한은 별개의 통제다
    2. 자동 마운트를 끄면 발급은 되지만 모든 audience 검증은 반드시 실패한다
    3. Pod에 마운트가 없으면 발급된 토큰은 어떤 객체에도 결합할 수 없다
    4. 자동 마운트를 끄는 순간 기존 RoleBinding은 모두 삭제된 상태가 된다
  6. 원래 조사한 RoleBinding을 삭제하기 직전 같은 이름의 객체 UID가 달라졌다. 이 실습 도우미가 해야 할 일은?

    1. 이름과 네임스페이스가 같으므로 새 UID를 무시하고 즉시 삭제한다
    2. 삭제를 중단하고 원래 조사 대상과 현재 객체가 다른 이유를 확인한다
    3. 예전 UID의 TokenReview가 성공할 때까지 계정을 반복 재생성한다
    4. 동일 이름 객체의 혼동을 막기 위해 네임스페이스 전체를 삭제한다
  7. 외부 서비스가 JWT 서명·issuer·audience·만료를 오프라인에서 검사한다. 결합된 Pod가 지금도 존재하는지 보장해야 한다면 무엇이 추가로 필요한가?

    1. JWT의 node 이름이 비어 있지 않은지만 확인하면 현재 Pod 존재가 증명된다
    2. 클라이언트가 보낸 TokenReview 성공 문자열을 그대로 믿으면 충분하다
    3. 신뢰할 수 있는 온라인 TokenReview 등으로 현재 결합 상태를 확인해야 한다
    4. JWT의 exp를 서비스에서 더 먼 미래로 바꾸면 객체 삭제와 무관하게 안전하다
  8. 최종 보고서에 옛 토큰 401·새 토큰 403만 적혀 있다. 다른 팀에 영향을 주지 않고 의도한 바인딩만 회수했다는 결론을 보강할 관측은?

    1. 전체 클러스터의 Pod 개수가 줄었다는 사실과 브라우저 화면의 초록 표시
    2. 옛 토큰 문자열의 길이와 새 토큰 문자열의 길이가 달라졌다는 사실
    3. 관리자 계정으로 ConfigMap 전체 목록이 조회된다는 결과 하나
    4. 새 인증 true·정확한 삭제 대상 UID·다른 팀 신원과 자원의 정상 200