クイズ: ポリシーの例外とレポート

Audit 모드의 성격으로 옳은 것은?

• 위반 요청을 거부하되 리포트나 로그에는 아무것도 남기지 않는 상태
• 어드미션 판정은 그대로 두고 백그라운드 스캔만 꺼 두는 설정
• 판정은 그대로 일어나되 위반 요청을 통과시키고 리포트에 기록만 하는 상태
• 정책을 등록만 해 두고 평가 자체를 하지 않는 보류 상태

새 정책을 프로덕션에 도입하는 순서로 가장 적절한 것은?

• Enforce 로 먼저 배포 → 막히는 것이 나올 때마다 그때그때 예외 처리 → 안정화
• Audit 으로 배포하고 리포트 관찰 → 고칠 수 있는 것 수정 → 못 고치는 것만 좁은 예외 → Enforce 전환
• 예상되는 예외를 먼저 전부 만들어 둠 → Enforce 로 배포 → 남은 예외 정리
• 개발 클러스터에서만 Enforce 로 검증 → 프로덕션에는 아예 배포하지 않고 유지

어드미션 단계만으로는 부족해 백그라운드 스캔이 필요한 이유는?

• 어드미션은 앞으로 들어올 요청만 보므로 이미 클러스터에 있는 리소스는 아무도 다시 검사하지 않기 때문
• 백그라운드 스캔만이 정책 YAML 의 문법과 스키마를 대신 검사해 주기 때문
• 어드미션 웹훅이 느려서 무거운 규칙은 백그라운드로 미뤄 두어야 하기 때문
• 어드미션 단계는 Audit 모드를 지원하지 않아 관찰 자체가 불가능하기 때문

PolicyReport 와 ClusterPolicyReport 의 차이는?

• 전자는 네임스페이스 범위 리소스의 결과를, 후자는 클러스터 범위 리소스의 결과를 담는다
• 전자는 Audit 모드의 결과를, 후자는 Enforce 모드의 결과를 담는다
• 전자는 CRD 로 조회되고 후자는 컨트롤러의 로그 파일로만 남는다
• 전자는 통과한 판정만 담고 후자는 실패한 판정만 모아 담는다

PolicyException 에서 ruleNames 를 생략하고 정책 전체를 면제하면 생기는 문제는?

• 그 리소스가 앞으로 그 정책에 추가되는 모든 규칙에서도 빠진다
• 그 리소스에 한해 정책 전체가 Audit 모드로 내려간다
• 그 정책의 판정 결과가 리포트에서 통째로 사라진다
• 규칙 이름이 없으면 예외 자체가 등록되지 않는다

정책 도입 작업의 진척을 가장 잘 나타내는 지표는?

• 리포트의 summary.fail 이 시간이 지나며 줄어들어 남은 예외 건수에 수렴하는 것
• 작성해서 클러스터에 올린 정책과 규칙이 모두 몇 개까지 늘었는지
• 어드미션 웹훅의 평균 응답 시간이 목표치까지 얼마나 짧아졌는지
• PolicyException 을 몇 개나 만들어 예외 처리를 끝냈는지

예외 관리에서 실무적으로 가장 어려운 부분은?

• 예외와 정책을 한 파일에 둘지 나눌지 정하는 것
• 예외의 match 블록 문법을 정확히 적는 것
• 만들어 둔 예외를 다시 지우는 절차를 유지하는 것
• 하나의 예외를 여러 네임스페이스에 걸치게 적는 것