Quiz: Admission Control

쿠버네티스 API 서버가 요청을 처리하는 순서로 옳은 것은?

• 인가 → 인증 → 스키마 검증 → 뮤테이팅 어드미션 → etcd 저장
• 인증 → 인가 → 뮤테이팅 어드미션 → 스키마 검증 → 밸리데이팅 어드미션 → etcd 저장
• 인증 → 인가 → etcd 저장 → 뮤테이팅 어드미션 → 밸리데이팅 어드미션
• 인증 → 밸리데이팅 어드미션 → 뮤테이팅 어드미션 → 인가 → etcd 저장

뮤테이팅 어드미션이 밸리데이팅 어드미션보다 먼저 실행되는 설계에서 생기는 함정은?

• 변형 규칙이 검증 규칙보다 느려서 요청 지연이 대부분 변형 단계에 몰린다
• 검증 규칙이 보는 오브젝트는 이미 변형된 오브젝트이므로, 주입된 사이드카도 검증 대상이 된다
• 변형 규칙이 하나라도 실패하면 뒤따르는 검증 규칙이 통째로 건너뛰어진다
• 변형 규칙은 이미 다른 규칙이 손댄 결과만 받아 사용자가 보낸 원본을 볼 수 없다

failurePolicy: Fail 로 설정된 웹훅에서 정책 엔진 파드가 전부 내려가면 어떤 일이 벌어지나요?

• 웹훅 대상 범위의 모든 생성·수정 요청이 거부되어 클러스터 쓰기가 멈춘다
• 정책 검사만 건너뛴 채 요청은 그대로 정상 처리되고 경고만 남는다
• API 서버가 응답 없는 웹훅을 감지해 failurePolicy 를 Ignore 로 낮춘다
• 정책이 적용된 뒤 만들어진 리소스들이 이전 상태로 되돌려진다

웹훅 설정에 namespaceSelector 로 kube-system 을 제외하는 가장 중요한 이유는?

• kube-system 은 RBAC 으로만 보호되기 때문
• 네임스페이스 셀렉터가 없으면 정책이 등록되지 않기 때문
• 웹훅 장애 시 클러스터를 되살릴 탈출구를 남겨 두기 위해
• kube-system 리소스는 정책 위반이 없기 때문

와일드카드로 모든 리소스 종류를 매칭하는 정책이 특히 위험한 이유는?

• 와일드카드 매치가 RBAC 의 리소스 지정과 겹쳐 권한 판정이 어긋나기 때문
• 대상이 너무 넓어 PolicyReport 가 생성되지 않고 결과를 볼 수 없기 때문
• 규칙 하나에 예외가 몰려 정책 파일이 길어지고 관리가 어려워지기 때문
• API 서버로 들어오는 모든 요청이 웹훅을 타면서 클러스터 전체에 지연이 붙기 때문

RBAC 과 어드미션 정책의 관계로 옳은 것은?

• 어드미션 정책이 오브젝트 내용까지 검사하므로 RBAC 의 역할을 그대로 대체할 수 있다
• RBAC 은 누가 무엇을 할 수 있는지를, 어드미션 정책은 만들어지는 오브젝트가 어떤 모양이어야 하는지를 다룬다
• 요청은 어드미션 정책을 먼저 통과한 다음 RBAC 인가를 받는 순서로 처리된다
• 어드미션 정책의 허용 규칙으로 특정 사용자에게 없던 권한을 새로 줄 수 있다

이 실습 환경(kwok 클러스터, 정책 엔진 컨트롤러 없음)에서 실제로 확인할 수 있는 것은?

• generate 규칙이 만든 NetworkPolicy 가 클러스터에 실제로 생기는 것
• 잘못된 파드를 kubectl apply 하면 클러스터가 거부하는 것
• 백그라운드 스캔이 기존 리소스를 훑어 리포트를 쌓는 것
• kyverno CLI 로 정책을 로컬에서 돌려 pass/fail 판정과 리포트를 얻는 것