퀴즈: 인증, 인가, 어드미션, API 폐기

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

1. TokenRequest API 로 발급되어 파드에 projected 볼륨으로 들어가는 서비스 어카운트 토큰의 성질은?

   1. 만료되지 않으며 파드가 지워져도 계속 유효하다
   2. 네임스페이스 전체에 공유되어 같은 네임스페이스의 어느 파드든 쓸 수 있다
   3. kubelet 이 아니라 애플리케이션이 직접 API 서버에 요청해 받아야 한다
   4. 기본 1시간의 수명을 갖고 그 파드에 바인딩되며 kubelet 이 만료 전에 갱신한다

2. 서비스 어카운트 토큰의 서명과 검증에 쓰이는 키가 있는 곳을 바르게 짝지은 것은?

   1. 각 노드의 kubelet 이 자기 노드 인증서의 키로 서명하고, etcd 가 저장 시점에 서명을 검증한다
   2. kube-controller-manager 의 개인 키(--service-account-private-key-file)로 서명하고, kube-apiserver 의 공개 키(--service-account-key-file)로 검증한다
   3. kube-apiserver 가 클러스터 CA(kubernetes-ca)의 개인 키로 서명하고, 각 노드의 kube-proxy 가 요청마다 검증한다
   4. ServiceAccount 오브젝트의 secrets 필드에 키 쌍이 들어 있어 각 파드가 시작할 때 스스로 토큰을 서명한다

3. RBAC 의 규칙과 바인딩에 대해 문서가 명시한 것은?

   1. 권한은 순수하게 더해지며 거부 규칙이 없고, RoleBinding 은 네임스페이스 안에서 권한을 붙인다
   2. Role 에 deny 규칙을 넣어 ClusterRole 이 준 권한을 네임스페이스에서 뺄 수 있다
   3. ClusterRole 은 네임스페이스에 속한 리소스이므로 RoleBinding 으로만 붙일 수 있다
   4. RoleBinding 하나로 모든 네임스페이스에 같은 권한을 한 번에 붙일 수 있다

4. 어드미션 컨트롤러의 실행 순서와 적용 범위를 바르게 설명한 것은?

   1. validating 단계가 먼저 돌고 통과한 요청만 mutating 단계에서 바뀐다
   2. mutating 과 validating 이 동시에 병렬로 돌고 다수결로 결정한다
   3. mutating 단계가 먼저 돌아 데이터를 바꾸고 그다음 validating 단계가 검사하며, 읽기 요청은 어드미션을 거치지 않는다
   4. 모든 요청이 어드미션을 거치며 get·list·watch 도 정책 위반이면 거부된다

5. API 폐기 정책의 규칙 4a 에 따른 beta API 버전의 수명은?

   1. 예고 없이 어느 릴리스에서든 제거될 수 있다
   2. 폐기 표시는 될 수 있어도 메이저 버전 안에서는 제거되지 않는다
   3. 도입 뒤 정확히 1년이 지나면 자동으로 GA 로 승격된다
   4. 도입 뒤 9개월 또는 3 minor 중 긴 쪽 안에 폐기되고, 폐기 뒤 9개월 또는 3 minor 중 긴 쪽 뒤에 서비스가 중단된다

6. 폐기된 API 버전으로 쓰인 YAML 매니페스트를 새 버전으로 옮길 때 이전 안내 문서가 제시한 도구와 그 성질은?

   1. kubectl convert -f <파일> --output-version <그룹>/<버전> — 기본 설치에 없는 플러그인이며 이상적이지 않은 기본값을 넣을 수 있다
   2. kubectl apply --force — 서버가 자동으로 최신 버전으로 변환해 저장한다
   3. kubectl edit — 편집기를 열면 apiVersion 이 자동으로 최신 값으로 바뀐다
   4. kubeadm upgrade apply — 클러스터 업그레이드 시 모든 매니페스트 파일을 함께 변환한다