クイズ: クラスタコンポーネントのセキュリティ

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

• 인증 → 인가 → 어드미션(Mutating → Validating) → 저장
• 인가 → 인증 → 어드미션(Validating → Mutating) → 저장
• 어드미션 → 인증 → 인가 → 저장
• 인증 → 어드미션 → 인가 → 저장

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

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

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

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

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

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

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

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

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

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