クイズ: 認証・認可とRBAC

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

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

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

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

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

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

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

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

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

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

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

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