퀴즈: 인증·인가와 RBAC

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

1. RoleBinding 이 ClusterRole 을 참조하면 어떤 일이 벌어지나?

   1. 그 ClusterRole 의 권한이 클러스터 전역에 부여된다
   2. 허용되지 않는 조합이라 apiserver 가 거부한다
   3. ClusterRole 의 규칙이 그 RoleBinding 이 존재하는 네임스페이스 안에서만 적용된다
   4. 노드 같은 클러스터 스코프 리소스에도 접근할 수 있게 된다

2. kubectl auth can-i --as= 가 실제로 하는 일은?

   1. 해당 사용자로 로그인해 명령을 대신 실행한다
   2. 그 주체의 토큰을 발급받아 로컬에 캐싱한다
   3. SubjectAccessReview 를 만들어 그 주체라면 허용되는지 apiserver 에 물어볼 뿐, 실제 요청은 보내지 않는다
   4. kubeconfig 에 담긴 RBAC 규칙을 로컬에서 그대로 평가한다

3. kubeadm 이 upload-certs 로 올린 Secret 을 2시간 뒤 자동 삭제하는 이유는?

   1. etcd 저장 공간을 아끼기 위해
   2. certificate-key 자체가 2시간마다 회전되기 때문
   3. kubelet 클라이언트 인증서 만료 주기와 맞추기 위해
   4. 암호화돼 있어도 클러스터의 루트 신뢰인 CA 개인키가 담겨 있어 노출 창을 최소화하기 위해

4. Aggregated ClusterRole 의 동작으로 옳은 것은?

   1. aggregationRule 의 라벨 셀렉터가 고른 다른 ClusterRole 들의 규칙을 컨트롤러가 합쳐 rules 를 채워 준다
   2. aggregationRule 이 있는 ClusterRole 의 rules 를 직접 편집해 관리한다
   3. 선택된 역할들에 대한 RoleBinding 을 자동으로 만들어 준다
   4. 네임스페이스 스코프 Role 만 합칠 수 있다

5. 파드 스펙에 automountServiceAccountToken: false 를 주면 어떻게 되나?

   1. 그 파드의 apiserver 접근이 네트워크 수준에서 차단된다
   2. kube-api-access 투영 볼륨이 주입되지 않아 컨테이너 안에 토큰 파일이 존재하지 않는다
   3. 연결된 ServiceAccount 오브젝트가 삭제된다
   4. 그 파드에 대해서만 RBAC 평가가 생략된다

6. 워커 조인은 토큰만으로 되는데 컨트롤 플레인 조인에는 certificate-key 가 추가로 필요한 이유는?

   1. 컨트롤 플레인이 더 많은 포트를 열어야 하기 때문
   2. 새 컨트롤 플레인 노드도 인증서를 발급하는 주체가 되어야 해서 CA 개인키가 필요하고, 그 키 묶음이 암호화된 채 클러스터에 올라가 있기 때문
   3. etcd 가 별도의 비밀번호를 요구하기 때문
   4. 컨트롤 플레인 노드의 kubelet 인증서 형식이 워커 노드와 서로 다르기 때문