퀴즈: 클러스터 컴포넌트 보안

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

1. apiserver 가 요청을 처리하는 단계 순서로 올바른 것은?

   1. 인증 → 인가 → 어드미션(Mutating → Validating) → 저장
   2. 인가 → 인증 → 어드미션(Validating → Mutating) → 저장
   3. 어드미션 → 인증 → 인가 → 저장
   4. 인증 → 어드미션 → 인가 → 저장

2. `system:masters` 그룹이 다른 RBAC 주체와 질적으로 다른 이유는?

   1. 모든 RBAC 검사를 우회하며, 바인딩을 삭제해도 권한을 회수할 수 없기 때문
   2. 이 그룹만 네임스페이스를 넘나들 수 있기 때문
   3. 이 그룹의 요청은 감사 로그에 남지 않기 때문
   4. 이 그룹은 어드미션 웹훅도 무시하기 때문

3. EncryptionConfiguration 의 providers 배열에서 `identity` 를 맨 앞에 두면?

   1. 새로 쓰는 Secret 이 평문으로 저장된다
   2. 설정 오류로 apiserver 가 기동하지 않는다
   3. 기존 암호문을 읽을 수 없게 된다
   4. 암호화 성능이 향상된다

4. 저장 시 암호화를 새로 켠 클러스터에서 기존 Secret 은 어떻게 되는가?

   1. apiserver 가 재시작되면서 자동으로 전부 다시 암호화된다
   2. 다시 쓰이기 전까지 평문으로 남으므로 전체 Secret 을 재작성해야 한다
   3. 읽을 수 없게 되어 모두 다시 만들어야 한다
   4. etcd 컴팩션 시점에 자동으로 암호화된다

5. kubelet 의 `authorization.mode` 를 `AlwaysAllow` 로 두면 생기는 위험은?

   1. kubelet 이 apiserver 에 아예 연결하지 못하게 된다
   2. kubelet API 에 인증만 통과하면 누구나 그 노드의 컨테이너에 대해 exec·로그·파드 실행 등 모든 동작을 할 수 있다
   3. 파드가 항상 privileged 로 실행된다
   4. 노드가 스케줄링 대상에서 제외된다

6. `--service-account-lookup=false` 가 위험한 이유는?

   1. 이미 삭제된 ServiceAccount 의 토큰도 서명만 유효하면 계속 인증에 통과하기 때문
   2. SA 토큰이 평문으로 저장되기 때문
   3. SA 가 자동으로 cluster-admin 권한을 받기 때문
   4. 토큰 발급 요청이 감사 로그에 남지 않기 때문