本物のアドミッションの確認

mutate가 owner 라벨을 채우고 validate가 owner 존재를 요구한다. 다른 거부 조건이 없다면?

• 변형된 요청을 검증하므로 owner 조건을 충족할 수 있다
• 원본 요청만 검증하므로 owner 조건을 충족할 수 없다
• 저장 뒤에 변형하므로 최초 생성은 반드시 거부된다
• 두 정책의 생성 시각이 같아야 owner 조건을 충족한다

generate 대상 Namespace가 있고 컨트롤러 로그에 ConfigMap 생성 Forbidden이 남았다. 다음 확인은?

• validate 규칙을 Audit에서 Enforce로 바꾸어 재시도한다
• 백그라운드 서비스어카운트의 대상 자원 권한을 확인한다
• mutating 웹훅의 timeoutSeconds를 늘려 검사를 기다린다
• 대상 Namespace 라벨을 지워 모든 규칙을 다시 호출한다

Audit 정책 하나를 위반한 Pod를 제출했다. 다른 정책도 있는 클러스터에서 확실히 말할 수 있는 것은?

• Audit 정책이 하나라도 있으면 다른 검증도 건너뛴다
• Audit 위반이 있으면 Pod가 반드시 Pending에 머문다
• 이 정책은 위반을 허용하지만 다른 정책은 거부할 수 있다
• Audit 위반 응답은 Warn이라는 실패 동작으로 거부한다

라벨 정책에 kube-system exclude를 넣었다. 서버 장애 때도 시스템 요청이 웹훅 호출을 피하는지 무엇을 더 확인할까?

• PolicyReport의 성공 건수로 웹훅 호출 제외를 확인한다
• 정책의 생성 시각으로 API 서버의 필터 적용을 확인한다
• 기존 시스템 Pod의 Running 상태로 새 요청을 확인한다
• 실제 WebhookConfiguration의 rules와 selectors를 확인한다

failurePolicy가 Ignore인 웹훅이 정상 응답으로 allowed:false를 돌려줬다. 이 요청은?

• 명시적 거부가 유효하므로 그 요청은 거부된다
• Ignore 설정이 우선하므로 그 요청은 저장된다
• 검증을 Audit으로 바꾸어 그 요청을 다시 제출한다
• 웹훅 등록을 지운 뒤 그 요청을 자동 재시도한다

등록된 Fail 웹훅이 시간 초과다. 장애 범위를 설명하는 가장 정확한 문장은?

• 모든 기존 Pod가 종료되고 모든 API 읽기가 거부된다
• 실제로 그 웹훅 호출 대상인 요청이 거부될 수 있다
• 정책 객체가 사라져 모든 새 요청의 검증이 생략된다
• 규칙 exclude가 있으면 호출 실패도 항상 무시된다